Agenzia delle Entrate : Non abbiamo il software...

[trallallero]

Originariamente inviato da cdimauro

Letto. Quale sarebbe il problema qui?

siamo OT (ma hai cominciato tu ) comunque il problema è che Microsoft con Intel hanno inventato l'HPET (High Precision Event Timer), però Microsoft non è stata in grado di gestirlo fino a Vista, mentre Linux lo ha gestito subito senza problemi.

I problemi ovviamente ci sono solo sui dual core e Microsoft addirittura consigliava di bloccare uno dei processori per ottenere un timestamp giusto.


http://msdn.microsoft.com/en-us/libr...58(VS.85).aspx
http://softwarecommunity.intel.com/i.../30225022.aspx
http://www.microsoft.com/whdc/system.../mm-timer.mspx

Comunque ripeto, OT, non voglio riaprire una diatriba Linux Vs Microsoft
(anche perchè MS ne esce con la coda tra le gambe )

[cdimauro]

Originariamente inviato da trallallero

siamo OT (ma hai cominciato tu )

L'OT non l'ho cominciato io. La news parlava di una cosa ben precisa, poi qualcuno ha tirato fuori l'open source, e qualcun altro (uno a caso: tu ) c'ha ricamato sopra.

comunque il problema è che Microsoft con Intel hanno inventato l'HPET (High Precision Event Timer), però Microsoft non è stata in grado di gestirlo fino a Vista, mentre Linux lo ha gestito subito senza problemi.

I problemi ovviamente ci sono solo sui dual core e Microsoft addirittura consigliava di bloccare uno dei processori per ottenere un timestamp giusto.

http://msdn.microsoft.com/en-us/libr...58(VS.85).aspx
http://softwarecommunity.intel.com/i.../30225022.aspx
http://www.microsoft.com/whdc/system.../mm-timer.mspx

Benissimo, e le motivazioni dovresti averle lette. Hai presente quando è stato commercializzato XP? E quando sono state rilasciate le specifiche dell'HPET?

Le conclusioni le puoi trarre da solo.

Comunque ripeto, OT, non voglio riaprire una diatriba Linux Vs Microsoft
(anche perchè MS ne esce con la coda tra le gambe )

E' questa non è forse una diatriba?

Inutile tra l'altro. Hai portato un esempio che non è consistente, rispondendo a me su una cosa che, invece, era perfettamente pertinente a ciò che avevi scritto.

[trallallero]

Originariamente inviato da cdimauro

L'OT non l'ho cominciato io. La news parlava di una cosa ben precisa, poi qualcuno ha tirato fuori l'open source, e qualcun altro (uno a caso: tu ) c'ha ricamato sopra.

capisco che se A = B ergo B = A, ma in questo caso non è così:
Linux è open source ma open source non è Linux.

E chi ha tirato in ballo Linux ?

e poi ho ragione io, punto e basta

[cdimauro]

Originariamente inviato da trallallero

capisco che se A = B ergo B = A, ma in questo caso non è così:
Linux è open source ma open source non è Linux.

D'accordo.

E chi ha tirato in ballo Linux ?

Non io.

e poi ho ragione io, punto e basta

Cedo alla violenza.

[drakend]

Originariamente inviato da cdimauro

La parte che ho evidenziato non è affatto vera, e quella che ho sottolineato è la chiave di tutto.

Come non è vera? Scusa se già il codice sorgente di un programma molto ampio è difficile da analizzare allora figuriamoci il compilato!!!

Per il resto, come giustamente affermi, non esiste e non esisterà mai una dimostrazione della tua precedente affermazione.

Beh nella vita mica è tutto dimostrabile in modo matematico. Molte cose si decidono anche tramite delle scelte che derivano a loro volta dalle idee: l'importante è saperle giustificare e io credo che l'abbia fatto.

[trallallero]

Originariamente inviato da drakend

Come non è vera? Scusa se già il codice sorgente di un programma molto ampio è difficile da analizzare allora figuriamoci il compilato!!!

e che ci vuole ? apri l'eseguibile con Visual Studio e leggi il codice assembler

[cdimauro]

Originariamente inviato da drakend

Come non è vera? Scusa se già il codice sorgente di un programma molto ampio è difficile da analizzare allora figuriamoci il compilato!!!

Vedi che hai già modificato la tua idea?

La questione è proprio il livello di skill richiesto per fare una determinata cosa.

Beh nella vita mica è tutto dimostrabile in modo matematico. Molte cose si decidono anche tramite delle scelte che derivano a loro volta dalle idee: l'importante è saperle giustificare e io credo che l'abbia fatto.

Stiamo parlando di software, e c'è parecchia teoria dietro. In particolare i teoremi che trovi nella teoria della computabilità non li puoi smontare (per ovvie ragioni: non sarebbero più teoremi altrimenti ) con le "esperienze di vita" o le opinioni personali.

Originariamente inviato da trallallero

e che ci vuole ? apri l'eseguibile con Visual Studio e leggi il codice assembler

Esistono anche i decompilatori.

Ma è anche vero che i "veri hacker" preferiscono i debugger.

[drakend]

Originariamente inviato da cdimauro

Vedi che hai già modificato la tua idea?
La questione è proprio il livello di skill richiesto per fare una determinata cosa.

No veramente tu hai solo precisato meglio la mia idea: è ovvio che per analizzare un programma devi averne le competenze e, se questo è particolarmente vasto, ti serve un team di esperti. Il fatto che un programma sia open source ti dà questa possibilità, poi quanto questa possibilità sia complessa o meno è un altro discorso. Un programma closed source questa possibilità non te la dà nemmeno e ti devi fidare di chi ti fa il programma.

Stiamo parlando di software, e c'è parecchia teoria dietro. In particolare i teoremi che trovi nella teoria della computabilità non li puoi smontare (per ovvie ragioni: non sarebbero più teoremi altrimenti ) con le "esperienze di vita" o le opinioni personali.

Lo so che dietro la stesura di un software c'è molta teoria dietro, però non mi ricordo di nessun teorema che afferma che il codice sorgente fatto da A non sia comprensibile da B. Certo che se non è scritto e/o documentato bene questo diventa oltremodo complesso, ma non impossibile.

Esistono anche i decompilatori.

Lo so. Ma non mi risulta che i decompilatori ti restituiscono l'equivalente del codice sorgente tale e quale... specialmente riguardo alla documentazione...

[cdimauro]

Originariamente inviato da drakend

No veramente tu hai solo precisato meglio la mia idea: è ovvio che per analizzare un programma devi averne le competenze e, se questo è particolarmente vasto, ti serve un team di esperti. Il fatto che un programma sia open source ti dà questa possibilità, poi quanto questa possibilità sia complessa o meno è un altro discorso. Un programma closed source questa possibilità non te la dà nemmeno e ti devi fidare di chi ti fa il programma.

No, proprio perché la differenza fra open e closed source è il diverso mezzo di distribuzione del codice.

Rimane, quindi, un problema di "skillness".

Lo so che dietro la stesura di un software c'è molta teoria dietro, però non mi ricordo di nessun teorema che afferma che il codice sorgente fatto da A non sia comprensibile da B. Certo che se non è scritto e/o documentato bene questo diventa oltremodo complesso, ma non impossibile.

No, tu hai affermato questo:

il fatto che un programma sia open source garantisce la trasparenza delle operazioni che svolge.

E la teoria della computabilità col famigerato "problema dello stop" (che vale sia per il codice closed che per quello open) dimostra che la tua affermazione genera un predicato INDECIDIBILE.

Lo so. Ma non mi risulta che i decompilatori ti restituiscono l'equivalente del codice sorgente tale e quale...

No, ma non cambierebbe di una virgola il problema.

specialmente riguardo alla documentazione...

Anche qui, come sopra.

Fermo restando che un buon codice non dovrebbe assolutamente avere bisogno di documentazione che ne descriva il comportamento.

[trallallero]

Originariamente inviato da cdimauro

Fermo restando che un buon codice non dovrebbe assolutamente avere bisogno di documentazione che ne descriva il comportamento.

aaaaaaaaah!

ma cosa dici !?!

edit:
hai mai scritto programmi più complessi di questo ?

int main()
{
   puts("hello world!");
}

[drakend]

Originariamente inviato da cdimauro

No, proprio perché la differenza fra open e closed source è il diverso mezzo di distribuzione del codice.

Rimane, quindi, un problema di "skillness".

Analizzare un codice sorgente è certamente più semplice di analizzare un codice assembler, a prescindere dalla "skillness" richiesta per capire il codice sorgente. In questo senso ho detto che il codice sorgente garantisce più trasparenza: rende molto più facile verificare quello che il programma fa o non fa.

No, tu hai affermato questo:

il fatto che un programma sia open source garantisce la trasparenza delle operazioni che svolge.

Sì lo ho affermato e lo ribadisco.
Sapere quello che fa un programma al suo interno lo rende più trasparente rispetto ad un suo omologo closed source, che viene considerato come una scatola nera in cui riporre fiducia. Tu poi hai menzionato la difficoltà di comprensione di codici molto vasti: esiste ma è un problema diverso, comunque risolvibile se esiste la volontà di analizzare il codice. Con il closed source invece tutto questo non può semplicemente avvenire.

E la teoria della computabilità col famigerato "problema dello stop" (che vale sia per il codice closed che per quello open) dimostra che la tua affermazione genera un predicato INDECIDIBILE.

Mah il fatto che non si possa sapere se un programma termini o meno per ogni possibile sequenza di input è certamente un problema che però riguarda il programma ed i dati, mentre qui stavamo parlando solo del codice sorgente. Vedo che ami confondere le carte e tirare l'acqua per il tuo mulino...
A me sembra davvero ovvio che un programma di cui abbia il codice sorgente non possa svolgere funzioni truffaldine come, esempio banale, aggiungere cento euro alla mia dichiarazione dei redditi senza che me ne accorga. Non avrei modo di accorgermene se il programma fosse closed source. In questo senso l'open source è più trasparente e non c'era davvero bisogno di andare a scomodare la teoria della computazione.

No, ma non cambierebbe di una virgola il problema.

Certo come no... d'altronde tutti sanno che analizzare un codice in assembler è semplice come analizzare un codice in c o in basic.

Fermo restando che un buon codice non dovrebbe assolutamente avere bisogno di documentazione che ne descriva il comportamento.

Che bestemmia...
Proprio tu che citi tanto la teoria mi vieni a dire queste cose?!?
Il codice va sempre scritto in modo chiaro (un'istruzione per linea ed identare bene), e poi va documentato in modo estensivo tramite commenti nel codice e anche nel manuale.

[trallallero]

Originariamente inviato da drakend

Che bestemmia...
Proprio tu che citi tanto la teoria mi vieni a dire queste cose?!?
Il codice va sempre scritto in modo chiaro (un'istruzione per linea ed identare bene), e poi va documentato in modo estensivo tramite commenti nel codice e anche nel manuale.

possibilmente utilizzando l'ottimo doxygen

toh! è open source



PS: ho dato in pasto il mio codice (+ di 11k righe di C++) ben commentato con doxygen e guarda che mi ha prodotto automaticamente:

[Kewell]

Originariamente inviato da Jabberwock

E perche' mai hanno creato una simile limitazione/complicazione?

Perché, a quanto si dice, capitava assai spesso che le dichiarazioni consegnate in posta o banche venissero inserite male nel sistema, con conseguenti segnalazioni di possibili irregolarità nella compilazione della dichiarazione, senza che effettivamente fosse così.

BTW, se mi indichi anche solo un link dove trovare la lista, cerco di capirci qualcosa da solo!

Forse nelle stesse istruzioni alla dichiarazione dei redditi

[Ziosilvio]

Originariamente inviato da trallallero

capisco che se A = B ergo B = A, ma in questo caso non è così:

in questo caso è A --> B, e non A = B.

[trallallero]

Originariamente inviato da Ziosilvio

in questo caso è A --> B, e non A = B.

pignolo

[cdimauro]

Originariamente inviato da trallallero

aaaaaaaaah!

ma cosa dici !?!

edit:
hai mai scritto programmi più complessi di questo ?

int main()
{
   puts("hello world!");
}

Tu che dici?

Originariamente inviato da drakend

Analizzare un codice sorgente è certamente più semplice di analizzare un codice assembler, a prescindere dalla "skillness" richiesta per capire il codice sorgente. In questo senso ho detto che il codice sorgente garantisce più trasparenza: rende molto più facile verificare quello che il programma fa o non fa.

Questo è già diverso da quello che affermavi prima.

Comunque rimane un problema di skillness: se ci sono tanti crack in giro, vuol dire che gente capace di smazzarsi codice assembly et similia ce n'è, anche se ovviamente in misura minore.

Sì lo ho affermato e lo ribadisco.
Sapere quello che fa un programma al suo interno lo rende più trasparente rispetto ad un suo omologo closed source, che viene considerato come una scatola nera in cui riporre fiducia.

Viene considerato tale, appunto, da chi non ha idea di cosa sia il codice di un'applicazione.

Tu poi hai menzionato la difficoltà di comprensione di codici molto vasti: esiste ma è un problema diverso, comunque risolvibile se esiste la volontà di analizzare il codice. Con il closed source invece tutto questo non può semplicemente avvenire.

Torni nuovamente a negare ogni possibilità, quando prima avevi "ammorbidito" e fatto rientrare il concetto.

Se esiste la volontà e la capacità, si può fare anche con quello closed, come ti ho dimostrato.

Mah il fatto che non si possa sapere se un programma termini o meno per ogni possibile sequenza di input è certamente un problema che però riguarda il programma ed i dati, mentre qui stavamo parlando solo del codice sorgente. Vedo che ami confondere le carte e tirare l'acqua per il tuo mulino...

Vedo che, purtroppo, ti mancano persino le basi della teoria della computabilità.

Chi l'ha studiata (con profitto) dovrebbe sapere che:
- i programmi elaborabili da un computer sono tutte e sole funzioni da N a N;
- a ogni programma è possibile associare un ben preciso numero naturale che lo rappresenta.

A queste condizioni il concetto di programma e di dato è alquanto labile, visto che il primo... è un dato!

"Casualmente" è questa la base del problema dello stop. E scusa se è poco!

Come vedi io non confondo proprio niente: ho ben presente cosa sia un programma, un dato e le implicazioni pratiche e teoriche che stanno dietro allo sviluppo del software.

A me sembra davvero ovvio che un programma di cui abbia il codice sorgente non possa svolgere funzioni truffaldine come, esempio banale, aggiungere cento euro alla mia dichiarazione dei redditi senza che me ne accorga.

Falso: questo si verifica se e solo se qualcuno, leggendo il codice, si accorgerà di eventuali funzioni truffaldine.

Non avrei modo di accorgermene se il programma fosse closed source.

Falso anche questo per lo stesso motivo che ho esposto qui sopra. L'unica differenza è la forma con cui è veicolato il codice.

In questo senso l'open source è più trasparente e non c'era davvero bisogno di andare a scomodare la teoria della computazione.

E' un senso che vuoi dare tu, perché la teoria della computaBILITA' (a te ignota, visto che ne sbagli anche il nome, oltre a non conoscerne le basi) assicura tutt'altro.

E se permetti io preferisco affidarmi a dei TEOREMI (peraltro elaborati da gente del calibro di Church, Turing, Godel, Kleene, ecc. che ha posto le basi dell'informatica), piuttosto che alle personalissime, soggettivissime nonché opinabilissime (anzi: smontabilissime ) impressioni di uno qualunque.

Certo come no... d'altronde tutti sanno che analizzare un codice in assembler è semplice come analizzare un codice in c o in basic.

Vedi sopra: dipende sempre dal livello di skillness.

Quanto al C, ecco qui:

                                  #include\
                                  <stdio.h>
                     #include                <stdlib.h>
                     #include                <string.h>

                    #define w "Hk~HdA=Jk|Jk~LSyL[{M[wMcxNksNss:"
                   #define r"Ht@H|@=HdJHtJHdYHtY:HtFHtF=JDBIl"\
                  "DJTEJDFIlMIlM:HdMHdM=I|KIlMJTOJDOIlWITY:8Y"
                 #define S"IT@I\\@=HdHHtGH|KILJJDIJDH:H|KID"\
                "K=HdQHtPH|TIDRJDRJDQ:JC?JK?=JDRJLRI|UItU:8T"
               #define _(i,j)L[i=2*T[j,O[i=O[j-R[j,T[i=2*\
              R[j-5*T[j+4*O[j-L[j,R[i=3*T[j-R[j-3*O[j+L[j,
             #define t"IS?I\\@=HdGHtGIDJILIJDIItHJTFJDF:8J"

    #define y                  yy(4),yy(5),                yy(6),yy(7)
  #define yy(              i)R[i]=T[i],T[i ]            =O[i],O[i]=L [i]
#define Y _(0          ], 4] )_ (1 ], 5] )_ (2      ], 6] )_ (3 ], 7] )_=1
#define v(i)(      (( R[ i ] * _ + T [ i ]) * _ + O [ i ]) * _ + L [ i ]) *2
double b = 32  ,l ,k ,o ,B ,_ ; int Q , s , V , R [8 ], T[ 8] ,O [8 ], L[ 8] ;
#define q( Q,R ) R= *X ++ % 64 *8 ,R |= *X /8 &7 ,Q=*X++%8,Q=Q*64+*X++%64-256,
# define  p      "G\\QG\\P=GLPGTPGdMGdNGtOGlOG"   "dSGdRGDPGLPG\\LG\\LHtGHtH:"
#  define W         "Hs?H{?=HdGH|FI\\II\\GJlHJ"    "lFL\\DLTCMlAM\\@Ns}Nk|:8G"
# define   U           "EDGEDH=EtCElDH{~H|AJk}"       "Jk?LSzL[|M[wMcxNksNst:"
#  define u                  "Hs?H|@=HdFHtEI"             "\\HI\\FJLHJTD:8H"
char  *   x                   ,*X , ( * i )[               640],z[3]="4_",
*Z = "4,8O4.8O4G" r U "4M"u S"4R"u t"4S8CHdDH|E=HtAIDAIt@IlAJTCJDCIlKI\\K:8K"U
 "4TDdWDdW=D\\UD\\VF\\FFdHGtCGtEIDBIDDIlBIdDJT@JLC:8D"t"4UGDNG\\L=GDJGLKHL\
FHLGHtEHtE:"p"4ZFDTFLT=G|EGlHITBH|DIlDIdE:HtMH|M=JDBJLDKLAKDALDFKtFKdMK\
\\LJTOJ\\NJTMJTM:8M4aGtFGlG=G|HG|H:G\\IG\\J=G|IG|I:GdKGlL=G|JG|J:4b"W
S"4d"W t t"4g"r w"4iGlIGlK=G|JG|J:4kHl@Ht@=HdDHtCHdPH|P:HdDHdD=It\
BIlDJTEJDFIdNI\\N:8N"w"4lID@IL@=HlIH|FHlPH|NHt^H|^:H|MH|N=J\\D\
J\\GK\\OKTOKDXJtXItZI|YIlWI|V:8^4mHLGH\\G=HLVH\\V:4n" u t t
"4p"W"IT@I\\@=HdHHtGIDKILIJLGJLG:JK?JK?=JDGJLGI|MJDL:8M4\
rHt@H|@=HtDH|BJdLJTH:ITEI\\E=ILPILNNtCNlB:8N4t"W t"4u"
p"4zI[?Il@=HlHH|HIDLILIJDII|HKDAJ|A:JtCJtC=JdLJtJL\
THLdFNk|Nc|\
:8K"; main (
int C,char**        A) {for(x=A[1],i=calloc(strlen(x)+2,163840);
C-1;C<3?Q=_=       0,(z[1]=*x++)?((*x++==104?z[1]^=32:--x), X =
strstr(Z,z))      &&(X+=C++):(printf("P2 %d 320 4 ",V=b/2+32),
V*=2,s=Q=0,C     =4):C<4?Q-->0?i[(int)((l+=o)+b)][(int)(k+=B)
]=1:_?_-=.5/    256,o=(v(2)-(l=v(0)))/(Q=16),B=(v(3)-(k=v(1)
))/Q:*X>60?y   ,q(L[4],L[5])q(L[6],L[7])*X-61||(++X,y,y,y),
Y:*X>57?++X,  y,Y:*X >54?++X,b+=*X++%64*4:--C:printf("%d "
,i[Q][s]+i[Q ][s+1]+i[Q+1][s]+i[Q+1][s+1])&&(Q+=2)<V||(Q=
0,s+=2)<640
||(C=1));}

Sul basic:

10 dim i
 20 i = 0
 30 i = i + 1
 40 if i <> 10 then goto 70
 50 print "Programma terminato."
 60 end
 70 print i & " al quadrato = " & i * i
 80 goto 30

Leggibilissimi, vero?

Dipende sempre da chi e da come si scrive il codice.

Che bestemmia...
Proprio tu che citi tanto la teoria mi vieni a dire queste cose?!?

Sì sì: non vedo perché non dovrei farlo.

Il codice va sempre scritto in modo chiaro (un'istruzione per linea ed identare bene), e poi va documentato in modo estensivo tramite commenti nel codice e anche nel manuale.

Ah, tutte queste belle cose in quale teoria sono spiegate? Link please. Così mi faccio altre 4 risate.

P.S. Comunque se volete continuare su questa linea possiamo evitare di inquinare ancora questo thread e aprirne uno nella sezione Programmazione.

[Hal2001]

Originariamente inviato da mpattera

Io ho più volte fatto l'unico per via telematica ed è java: unica cosa vuole esattamente jre 1.3

Non ho mai capito perché!

Ci sono un sacco di falle, e non si può nemmeno mettere l'ultima build del ramo 1.3 perché non funziona.

Che schifo.

[Hal2001]

Originariamente inviato da cdimauro

A parte ciò che ha detto evelon, dovresti dimostrami (perché sei tu che hai tirato in ballo la questione) quali garanzie di trasparenza in più dà un programma open source.

Appena vengo dalle tue parti te lo dimostro. Mi dai il tuo portafogli senza controllarlo prima, ed io ti dico che ho preso 30€. Poi sta a te credermi o meno.
Oppure possiamo aprirlo davanti e prelevare i 30€.

L'esempio è alla berlinona per ridere, ma è proprio così, se il codice è visionabile da tutti (ed ha rilevanza) una backdoors non riesciresti mai a metterla. Così come un bug, o un buffer underflow (o relativo) sarebbero facilmente risolvibili.

L'Opensource non è il diavolo Cesare, anzi. Forse un giorno te ne renderai conto

[cdimauro]

Originariamente inviato da Hal2001

Appena vengo dalle tue parti te lo dimostro. Mi dai il tuo portafogli senza controllarlo prima, ed io ti dico che ho preso 30€. Poi sta a te credermi o meno.
Oppure possiamo aprirlo davanti e prelevare i 30€.

L'esempio è alla berlinona per ridere, ma è proprio così, se il codice è visionabile da tutti (ed ha rilevanza) una backdoors non riesciresti mai a metterla. Così come un bug, o un buffer underflow (o relativo) sarebbero facilmente risolvibili.

Ho già spiegato che è questione soltanto di skillness.

Tra l'altro il fatto che il codice sia visionabile (perché hai i sorgenti o un disassemblato; è indifferente) NON implica che si troveranno backdoor, falle, et similia. Nella vita ci vuole anche tanto culo.

L'Opensource non è il diavolo Cesare, anzi. Forse un giorno te ne renderai conto

Il closed source non è il diavolo Hal, anzi. Forse un giorno te ne renderai conto

Per me non esiste software open o closed: esiste il software. Quello che riesce a soddisfare le mie esigenze.

[drakend]

Originariamente inviato da cdimauro

Se esiste la volontà e la capacità, si può fare anche con quello closed, come ti ho dimostrato.

Certo disassemblando il compilato si può fare, che è ovviamente sullo stesso livello di fattibilità dell'analisi di un codice sorgente vero?
Ti contraddici da solo: prima dici che analizzare il codice sorgente di programmi vasti è complesso e poco fattibile, ora dici che comunque lo si può fare anche con il codice assembler di tali programmi se lo si vuole?
Certo si può fare, mettendoci però MOLTO più impegno e tempo, il che vuol dire denaro.

Vedo che, purtroppo, ti mancano persino le basi della teoria della computabilità.

Non mi sembra che siamo qui per discutere delle mie competenze in tale teoria.

Chi l'ha studiata (con profitto) dovrebbe sapere che:
- i programmi elaborabili da un computer sono tutte e sole funzioni da N a N;
- a ogni programma è possibile associare un ben preciso numero naturale che lo rappresenta.

A queste condizioni il concetto di programma e di dato è alquanto labile, visto che il primo... è un dato!

Sarà anche un dato in astratto, ma sta di fatto che l'analisi del suo codice sorgente è INFINITAMENTE più semplice dell'analisi del suo compilato. Questa è un'ovvietà sotto gli occhi di tutti che tu, per qualche motivo, ti ostini a negare confondendo le acque con nozioni teoriche che c'entrano poco o nulla con il discorso.

Come vedi io non confondo proprio niente: ho ben presente cosa sia un programma, un dato e le implicazioni pratiche e teoriche che stanno dietro allo sviluppo del software.

Sarà ma intanto vedo che metti sullo stesso piano l'analisi di un codice sorgente con quella di un compilato... non mi sembra che questo abbia molto senso...

Falso: questo si verifica se e solo se qualcuno, leggendo il codice, si accorgerà di eventuali funzioni truffaldine.

Il fatto che qualcuno legga o meno il codice è un altro discorso ed è certamente più semplice leggere un codice di alto livello che di basso livello come l'assembler. Questo senza considerare il fatto che esistono diverse tecniche per rendere un programma non dissassemblabile, cosa che tu bellamente ignori in quella che sembra essere una difesa del closed source senza se e senza ma!

E' un senso che vuoi dare tu, perché la teoria della computaBILITA' (a te ignota, visto che ne sbagli anche il nome, oltre a non conoscerne le basi) assicura tutt'altro.

Vedo che non hai molti altri argomenti a tuo favore dato che ti appigli all'ortografia ora.

E se permetti io preferisco affidarmi a dei TEOREMI (peraltro elaborati da gente del calibro di Church, Turing, Godel, Kleene, ecc. che ha posto le basi dell'informatica), piuttosto che alle personalissime, soggettivissime nonché opinabilissime (anzi: smontabilissime ) impressioni di uno qualunque.

Le mie saranno anche opinioni personalissime ecc, peccato che sono quelle sostenute da centinaia di migliaia di programmatori in tutto il mondo... saranno tutti ignoranti dato che non conoscono la magica teoria della computaBILITà evidentemente.

Dipende sempre da chi e da come si scrive il codice.

Si va bene la documentazione e i commenti nel codice non servono a niente...

P.S. Comunque se volete continuare su questa linea possiamo evitare di inquinare ancora questo thread e aprirne uno nella sezione Programmazione.

No non è necessario aprire nessun altro thread perché per me la nostra discussione finisce qui dato che non ho alcun interesse a proseguire il confronto con te.