Livello di programmazione con vari linguaggi, allocazione dinamica della memoria

[cionci]

Originariamente inviato da 71104

be', non è detto: ci sono ambiti in cui maneggiare puntatori "allegramente" è necessario, mi riferisco specialmente alla programmazione di sistema (device drivers o parti del sistema operativo stesso)

Certo...infatti quello è solitamente l'ambiente principale del C...

[71104]

Originariamente inviato da -fidel-

Se parli di 90 % sono d'accordo, se parli di "definitivamente sì" non lo sono più. Parlando nello specifico di Java, volendo fare un discorso "tecnicamente più preciso" come dici tu, puoi leggere questo articolo. Ovvio che i GC riducono i memory leaks, è uno dei motivi per cui sono stati pensati, ma non li eliminano del tutto (magari!).

be' ciò che è scritto nel link che mi hai dato è vero ma significa che il leak è causato dal fatto che ancora tengo dei references e ancora ho la possibilità di controllo sugli oggetti non deallocati... in altre parole è un problema di design... la differenza tra come la vedi tu e come la vedo io è piuttosto sottile: io sono abituato a pensare al memory leak vero e proprio quando si perde ogni riferimento ma il blocco di memoria dinamica rimane; in tal caso esso non può più essere liberato se non ovviamente quando il processo viene terminato dal sistema operativo perché a quel punto l'unico software che continua ad avere il controllo di quel blocco è appunto il sistema operativo stesso.
tu invece consideri il memory leak fin da quando inizia a presentarsi il problema di design del reference tenuto inutilmente; punti di vista insomma, se vogliamo vederla come la vedi tu allora ti do perfettamente ragione.

Su Java sei più ferrato, su bash molto meno a quanto pare... Ti consiglio di leggere qui per farti un'idea più precisa. Nella prima riga leggerai:
Bash is the GNU shell, or command language interpreter.
che vuol dire che bash è un linguaggio script, alla carlona lo puoi pensare come una estensione (ampia) dei file batch del DOS. Il suo linguaggio può sempbrare quello di un linguaggio di programmazione (come semantica) ma non lo è, quindi non lo puoi assolutamente paragonare al C++ o al Java quanto parli di "livelli" di linguaggio.

so cos'è il bash perché lo sto studiando proprio in questo periodo per un esame; in questo thread naturalmente quando ho parlato di bash non mi sono riferito alla shell (cioè all'interprete del caso) ma al linguaggio da essa interpretato; e non vedo perché non possa essere considerato un linguaggio di programmazione... il JavaScript secondo te è un linguaggio di programmazione? be', è anche un linguaggio di scripting... lo stesso dicasi per il PHP... forse per te Bash non è un linguaggio di programmazione perché è interpretato? anche BASIC in molte sue manifestazioni è interpretato e non penso che gli si possa negare la definizione di linguaggio di programmazione...
che cos'è nel significato dell'espressione "linguaggio di programmazione" che non può essere applicato al linguaggio Bash?

[...] Poi con la JNI puoi fare un po' di tutto, ma questo esula dal Java puro che tu, da quello che ho capito ora, volevi trattare.

e per forza
mettere in ballo JNI invalida tutto il discorso di questo thread perché significa che a quel punto il Garbage Collector può essere tranquillamente superato nella libreria nativa; questo mi pare ovvio, e se tu affermi che usando JNI è possibile commettere dei veri e propri leak da far rabbrividire la pelle (nonché le mie stecche di RAM ) allora sono più che d'accordo.

[71104]

Originariamente inviato da mjordan

No? Leggi il link che ho postato dietro

no cosa?
e quale link? i thread lunghi sono ingestibili, a che pagina stava il link?

No no affatto. In molti cercano di classificare il medio livello, invece, anche se non è mai entrato di fatto come "voce di catalogazione".

se non esiste una definizione ufficialmente accettata prendila come una definizione mia e di molti altri che ho spiegato con gli esempi del post che mi hai quotato.

Quindi Pascal che consente di manipolare i puntatori e di basso livello. . .

no, non esageriamo, non ho mai detto questo; l'Object Pascal di Delphi lo considero di medio livello perché penso che abbia caratteristiche funzionali analoghe a quelle del C++.

Appunto... Delphi è di medio livello....

si

Ok. Ma "il bash" non è un linguaggio. BASH significa Bourne Again SHell ed è una shell. E' semplicemente uno scripting language che è diverso da un linguaggio di programmazione.

perché non può essere considerato un linguaggio di programmazione? solo per l'estetica della sintassi?

[71104]

Originariamente inviato da cionci

Certo...infatti quello è solitamente l'ambiente principale del C...

si, ma l'esempio del B-albero calza perfettamente anche in un contesto C++

[k0nt3]

hey! me ne vado un pomeriggio e mi scrivete dozzine di pagine?!! ci ho messo un pò a leggere! interessante l'esempio di fidel, ma effettivamente all'inizio non era molto chiaro il problema!

auguri mjordan

ps. IMHO i B-TREE stanno meglio nel C, no ti serve niente del C++.. o sbaglio?

[-fidel-]

Originariamente inviato da MenageZero

cmq l'importante alla fine è intendersi

Quoto

[cionci]

Originariamente inviato da 71104

si, ma l'esempio del B-albero calza perfettamente anche in un contesto C++

Sì, ma di fatto diventa una istruzione su N-mila

[-fidel-]

Originariamente inviato da 71104

so cos'è il bash perché lo sto studiando proprio in questo periodo per un esame; in questo thread naturalmente quando ho parlato di bash non mi sono riferito alla shell (cioè all'interprete del caso) ma al linguaggio da essa interpretato; e non vedo perché non possa essere considerato un linguaggio di programmazione... il JavaScript secondo te è un linguaggio di programmazione? be', è anche un linguaggio di scripting... lo stesso dicasi per il PHP...

Mi avevi parlato di bash senza specificare che ti riferivi alla sua semantica, lasciando sottinteso questo concetto. In questo caso (sulla semantica) ne possiamo discutere: domani però, tra mezz'ora esco

per te Bash non è un linguaggio di programmazione perché è interpretato?

Sì, tecnicamente non è un traduttore, ma un interprete. La differenza tra le due cose è nota, io però di solito chiamo "linguaggi di programmazione" i traduttori. Se tu invece ti riferisci alla semantica (interpretazione alla fine non errata, ma secondo me un po' fuorviante data la comune interpretazione) ne possiamo parlare, come dicevo prima. Del resto, gli script bash stilisticamente sembrano programmi C
Ora puoi capire la mia posizione quando hai asserito "no, e un linguaggio di programmazione, e di alto livello" con molta convinzione, ma il tuo chiarimento non si è fatto attendere

[71104]

Originariamente inviato da k0nt3

ps. IMHO i B-TREE stanno meglio nel C, no ti serve niente del C++.. o sbaglio?

be' secondo me... sbagli!
qualsiasi tipo di grafo secondo me si realizza benissimo in un'ottica OOP: piuttosto che realizzare i nodi con le struct li realizzi con le classi, e quindi li puoi realizzare anche con una migliore eleganza formale; magari ad esempio puoi costruire un tuo set di classi usando come classe base una classe che rappresenti un grafo generico, poi da questa puoi distinguere grafi orientati e non, poi da quelli orientati derivi una serie di classi per rappresentare tutti i vari tipi di alberi, eccetera.

[71104]

Originariamente inviato da -fidel-

Sì, tecnicamente non è un traduttore, ma un interprete.

appunto, ma come ho detto è così anche per molte implementazioni del BASIC, e non diresti mai che il BASIC non è un linguaggio di programmazione!

La differenza tra le due cose è nota, io però di solito chiamo "linguaggi di programmazione" i traduttori. Se tu invece ti riferisci alla semantica (interpretazione alla fine non errata, ma secondo me un po' fuorviante data la comune interpretazione) ne possiamo parlare, come dicevo prima. Del resto, gli script bash stilisticamente sembrano programmi C
Ora puoi capire la mia posizione quando hai asserito "no, e un linguaggio di programmazione, e di alto livello" con molta convinzione, ma il tuo chiarimento non si è fatto attendere

be' ma non capisco tutta questa stranezza e insolitudine nel considerare il linguaggio Bash un linguaggio di programmazione... è talmente potente (per essere una shell) che ci si possono fare una miriade di cose che su Windows devono essere realizzate con necessariamente programmi appositi; gli script in Bash sono veri e propri programmi (interpretati naturalmente) che possono essere anche molto lunghi; per esempio al nostro corso il primo esonero consisteva nel creare esclusivamente in linguaggio Bash un clone del comando rsync... io vabbè non l'ho fatto perché ho fatto l'esame in modalità esame (non esoneri), però ho visto quello di un mio compagno (visto che tanto all'orale il prof mi deve fare un didietro così su Bash ) ed ammontava a un paio di centinaia di righe se ricordo bene. direi che il look and feel del linguaggio di programmazione c'è tutto

[marco.r]

Originariamente inviato da -fidel-

C'è una incomprensione di fondo. Il problema risiede nel fatto che, ad esempio:

1) istanzio 'byteArray' da 10 mega e la uso
2) ho bisogno di un buffer più grosso: reistanzio byteArray da 20 Mb. i 10 mega di prima vengono subito rimossi, e ne vengono riallocati 20.
3) il GC rimuoverà i 20 mega solo quando vado a cancellare la classe!

Non è un memory leak classico, viene chiamato memory leak di tipo "object loitering", quel buffer viene tranquillamente eliminato quando rimuovo l'intera classe, ma nel frattempo sta lì a rubare inutilmente memoria.

Uhm, non lo considererei un leak, in fondo la memoria non viene persa, viene semplicemente messa da parte nella speranza che questo porti qualche vantaggio. Se quel metodo viene chiamata qualche decina di volte al secondo per file di dimensioni costanti, quella memoria è tutt'altro che inutilizzata. Dipende dall'uso che se ne fa.

[marco.r]

Originariamente inviato da -fidel-

Sì, tecnicamente non è un traduttore, ma un interprete. La differenza tra le due cose è nota, io però di solito chiamo "linguaggi di programmazione" i traduttori.

Un linguaggio è un linguaggio. Che poi venga dato in pasto ad un interprete o ad un traduttore è un altro paio di maniche. Tanto che alcuni vengono sia interpretati che tradotti. Oppure prima tradotti (in bytecode) e poi interpretati.
Va da sè che qualche linguaggio più si presta all'interpretazione (bash) che alla traduzione (C).

Originariamente inviato da Fx

un conto sono le opinioni sugli argomenti, un conto sono le opinioni sulle persone

"per me quel che dici non si regge in piedi" è diverso da "per me non capisci un cazzo", concetto che hai espresso in altri termini (non così diversi) parecchie volte nei confronti dei tuoi interlocutori: se con un po' di calma e oggettività ti andrai a rileggere il topic coglierai dei toni aggressivi nei tuoi post

te lo dico in modo sterile, per evitare polemiche

Errato... io non ho mai insultato nessuno (e ti sfido a dimostrare il contrario citando mie parole). Posso essere stato aggressivo (sempre in modo garbato però) ma solo se precedentemente provocato. Quelli che hanno mosso per primi insulti personali sono stati altri... eppure te lo avevo già spiegato nel mio post numero #15.

Discorso concluso.

Originariamente inviato da mjordan

Piccola pausa per festeggiare il mio compleanno ...

Auguri.

Non è retorica, sono dei libri

Non l'elenco dei libri, ma le tue parole ed il tuo modo di porti.

Secondo alcuni ragionamenti che si sono fatti, anche Pascal allora dovrebbe essere di medio/basso livello? Basta contare il numero di parole riservate per dare una stima approssimativa.

Nessuno ha mai parlato di "medio/basso", se mai di "medio/alto".

Io non ho detto che scrivi software banale, ho detto che chiunque partecipi in progetti non banali si rende conto che un bug (anche quelli piu' comuni) non dipendono esclusivamente dall' "attenzione", "cura del codice", "progettazione dell'architettura", tutte cose che tu invece hai elencato come "metodi" per eliminare simili bug. Il livello di attenzione, forte o debole che ognuno di noi ha, rimane "umano". Vista l'impossibilità di scrivere codice complesso senza introdurre bug comuni, è nata l'ingegneria del software. Disciplina che cerca di dare un metodo al processo. E nonostante ciò, non ha eliminato il problema. Da cui i libri che ti ho consigliato di leggere. Ti fanno rendere conto che magari esiste una complessità del software che, da come parli, evidentemente sembri ignorare. Tutto qui.

Ripeto per l'ennesima volta... nessuno mette in dubbio che non vi sia la possibilità di "scrivere codice complesso senza introdurre bug comuni", ma come già spiegato è possibile ridurne drasticamente il numero con i banali accorgimenti che tu hai ricordato. Nessuno dice che dipenda esclusivamente da questo, ma sicuramente gioca un ruolo importante.

E' inutile sfidarmi sul piano personale. Come non ti conosco io non mi conosci tu. Da dove proviene tutta questa certezza di "vincere"?

Dalla bontà dei progetti a cui lavoro

Posso scrivere una funzione completamente "bug free". Tuttavia il ruolo di una funzione va considerato anche sul piano semantico in relazione al codice complessivo. Quella funzione "bug free" potrebbe diventare completamente priva di senso in seguito a una modifica da un'altra parte del codice. Moltiplica il tutto per milioni di righe, strutture dati non banali che interagiscono fra loro, funzioni che si basano sul contenuto di una struttura che al minimo cambiamento diventano inconsistenti e ti rendi conto che il discorso "dell'attenzione" che facevi tu si continua ad applicare solo a software banale.

Dipende da come strutturi il codice. Premesso che non ho capito la tua affermazione "Quella funzione bug free potrebbe diventare completamente priva di senso in seguito a una modifica da un'altra parte del codice", qui risiede l'importanza di sviluppare (in modo miratamente curato) codice modulare ed altamente riutilizzabile. Sono sempre semplici accorgimenti ed ognuno preso singolarmente vale ben poco (nessuno mette in dubbio questo), ma è l'insieme di tutti questi accorgimenti che ci dà la possibilità, se non di eliminare (poichè l'uomo è fallibile per definizione), di ridurre drasticamente la possibilità d'errore nelle varie fasi dello sviluppo.

Il cervello umano riesce a gestire (male) un massimo di 3 cose contemporaneamente. E' la biologia che lo dice, non serve neanche considerare l'informatica.

Mah... qui servirebbe un bel ripasso sul funzionamento del cervello, dei neuroni, delle connessione sinaptiche etc. e la tua affermazione non ha molto a che vedere con questo... comunque non c'entra nulla col nostro discorso

Se li leggi ti accorgi che non sono proprio elementari come li consideri... Come fai a stipulare un verdetto dai soli titoli... Un qualcosa prima di essere giudicato va letto. Il Fowler che ti ho dato non è proprio banale. Ti fa rendere conto che UML non è soltanto un class diagram. Il dragon Book all'unanimità è pure considerato un testo "difficile", non adatto ai principianti e l'ho preso proprio perchè ho visto un esperto come te.
Leggili.

Se trovo un libro dal titolo "Impariamo l'alfabeto" esso mi sembra abbastanza autoesplicativo sul suo contenuto Ho affermato ciò perchè leggendo i titoli mi sono reso conto che sono in gran parte argomenti che già conosco.

L'argomento trattato non è altro che una discussione che si basa su opinioni che invece hanno fondamento in quelle discipline. Da cui i libri che ti ho citato. Prima di discutere di qualcosa ci vuole fondamento.

Questi fondamenti penso siano già abbastanza noti alla maggior parte di noi (spero). Sarebbe stato maggiormente "risolutivo" un testo che trattasse esplicitamente l'argomento in questione, anche perchè a partire dai suddetti "fondamenti" poi ognuno può comunque dedurre una propria intepretazione delle cose e si è sempre al punto di partenza

UML non è soltanto costituito da Class diagram. UML può diventare terrificante. Certo non è difficile da imparare, ma provare a implementare qualcosa che risci a concepire in UML è un'altro "esercizio" per capire dove può arrivare la complessità del software. E che quindi il livello di "attenzione" non c'entra ancora nulla.

La complessità del codice non è necessariamente correlata alla quantità d'errori (certo può essere uno dei fattori... magari uno dei maggiori). Molti programmatori commettono errori ed ingenuità anche in programmi e algoritmi relativamente semplici. Credo che per evitare determinati errori language-related (non so... un buffer overflow in C piuttosto che una sql injection in PHP) sia il caso di lavorare direttamente sui linguaggi in questione più che su UML.

Come volevasi dimostrare
La "sicurezza" che hai proviene da due elementi di giudizio:

1) Sicurezza che in fondo non lo è.
2) Sicurezza certa dovuta a estrema semplicità del codice trattato.

Io credo che la tua sia un mix di entrambi i punti. 2000 righe di codice C/C++ inolte non sono proprio la stessa cosa che 2000 righe di codice PHP, vista "l'indulgenza sintattica" per cui questo linguaggio è famoso. Lo stesso dicasi per SQL.

Credo tu stia parlando senza conoscere bene PHP (senza offesa chiaramente... non voglio che si scateni un altro flame). Innanzitutto non ho ben capito cosa vorresti dire con i punti 1 e 2, ma in ogni caso le questioni sulla sicurezza del codice PHP che ho sollevato (a semplice titolo esemplificativo) non hanno *nulla* a che fare con la presunta "indulgenza sintattica" ma sono errori concettuali dovuti alla scarsa attenzione (nuovamente) dello sviluppatore. Come in C devo eseguire controlli relativi alla capienza del buffer (ad esempio) in PHP devo eseguire controlli relativi ai vari dati in input (inviati attraverso i metodi GET, POST o attraverso i COOKIES) per accertare che non possiedano "contenuti ostili". Tra l'altro questo non ha molto a che vedere con SQL... forse ti ha tratto in inganno la parola "sql injection", dato che questo tipo di vulnerabilità si evidenzia per una non corretta gestione di dati ricevuti in input dall'utente e poi passati al database sempre dal linguaggio di scripting (PHP) e non riguarda in maniera diretta il linguaggio SQL stesso.

[k0nt3]

Originariamente inviato da 71104

be' secondo me... sbagli!
qualsiasi tipo di grafo secondo me si realizza benissimo in un'ottica OOP: piuttosto che realizzare i nodi con le struct li realizzi con le classi, e quindi li puoi realizzare anche con una migliore eleganza formale; magari ad esempio puoi costruire un tuo set di classi usando come classe base una classe che rappresenti un grafo generico, poi da questa puoi distinguere grafi orientati e non, poi da quelli orientati derivi una serie di classi per rappresentare tutti i vari tipi di alberi, eccetera.

si effettivamente è comoda la rappresentazione del grafo OO! non so se ci sono differenze prestazionali in grafi particolarmente grossi (come gli alberi dei FS), però senza dubbio è più elegante!

comunque non ho capito ancora la definizione esatta che vuoi dare al medio livello... anche perchè se consideri solo il fatto dei puntatori nel medio livello ci devi mettere anche il C# oltre al delphi come diceva cionci... non mi convince ancora sta cosa.. io personalmente non mi sono mai sbilanciato più di tanto, ma se proprio ci metterei C, COBOL, FORTRAN & CO! non tanto per il fatto di gestire in un certo tipo la memoria, ma per il fatto che non contemplano la programmazione OO, che di per sè stravolge l'approccio che il programmatore ha con il linguaggio! in questo senso l'OOP permette di astrarre ad un livello più alto i concetti.. in maniera più vicina a quello che fa l'uomo in un certo senso! se però adesso arriva uno e mi chiede dove mettere lisp o prolog... non saprei cosa rispondere! quindi credo che una definizione di medio livello sia un tantino più complessa di quello che sembra.. poi ho sentito parlare addirittura di medio/basso medio/alto livello sarebbe già troppo definire il medio livello!

Originariamente inviato da k0nt3

poi ho sentito parlare addirittura di medio/basso medio/alto livello sarebbe già troppo definire il medio livello!

Questo perchè ogni linguaggio possiede proprie sfumature... non penso vi siano linguaggi perfettamente equivalenti ad altri (e se ci fossero non penso abbiano molto senso d'esistere)

[k0nt3]

Originariamente inviato da ekerazha

Questo perchè ogni linguaggio possiede proprie sfumature... non penso vi siano linguaggi perfettamente equivalenti ad altri (e se ci fossero non penso abbiano molto senso d'esistere)

si ma dalle sfumature stabilire se uno è a un livello superiore di un altro è un altro conto! ti ho detto.. già non è ancora chiaro il passaggio da alto livello a medio... vuoi che sia chiaro quello da medio a medio/basso? ho già detto che il GC non basta a rendere un linguaggio di più alto livello rispetto al C++ ad esempio.. o almeno la cosa non mi convince!

Originariamente inviato da k0nt3

si ma dalle sfumature stabilire se uno è a un livello superiore di un altro è un altro conto! ti ho detto.. già non è ancora chiaro il passaggio da alto livello a medio... vuoi che sia chiaro quello da medio a medio/basso? ho già detto che il GC non basta a rendere un linguaggio di più alto livello rispetto al C++ ad esempio.. o almeno la cosa non mi convince!

Io non ho mai parlato di medio/basso :-P Io considero di basso livello l'Assembly (se vogliamo scendere ancora più in basso possiamo trovare il codice binario ). Chiaramente la cosa si presta a svariate interpretazioni (come sta dimostrando questo thread) ed anche volessimo riunire alcuni linguaggi in una determinata fascia, anche tra linguaggi appartenenti ad una stessa fascia vi sarebbero comunque alcune differenze o sfumature

[Fx]

Originariamente inviato da ekerazha

Errato... io non ho mai insultato nessuno (e ti sfido a dimostrare il contrario citando mie parole).

giusto per esser preciso:

Originariamente inviato da ekerazha

Come vedi è possibile rispondere a tono senza insultare l'interlocutore sul piano personale... ed è davvero singolare che debba spiegartelo uno più giovane (dato che sei già laureando) e teoricamente più immaturo di te.

Originariamente inviato da ekerazha

Per cortesia risparmiami questi patetici esercizi di retorica.

Originariamente inviato da ekerazha

Se le argomentazioni sono le stesse che hai portato tu, credo sia meglio non buttare i soldi

Originariamente inviato da ekerazha

quei libri (dai titoli) sembrerebbero abbastanza "basilari" (tranne "Ingegneria del software", materia tra l'altro trattata nel corso di Ingegneria Informatica) e mi sembrerebbero più adatti ad un pubblico come te

Originariamente inviato da ekerazha

Io spero davvero stiate scherzando, altrimenti siete messi male... ma davvero malissimo...

Originariamente inviato da ekerazha

... mi sembra davvero di essere capitato fra un manipolo di pazzi...

Originariamente inviato da ekerazha

volevo dire la stessa cosa su di te ma non l'ho detto perchè a differenza tua ho un briciolo di educazione e maturità e cerco di non alimentare flame inutilmente.

Originariamente inviato da ekerazha

Cresci.

Originariamente inviato da ekerazha

Bravo. Dopo aver dimostrato scarsa competenza con i tuoi errori grossolani mentre tentavi di addentrarti in argomenti che esulano dalla tua conoscenza ed il tentativo di "invenzione" della lingua italiana, l'unico modo che hai per dare una parvenza di intelligenza è proprio quella di non parlare

Originariamente inviato da ekerazha

Sei solo un poveraccio

Originariamente inviato da ekerazha

Tutte castronerie a cui non hai saputo contrapporre la minima argomentazione convincente se non fraintendendo le cose che venivano dette e commettendo errori come già detto grossolani

Originariamente inviato da ekerazha

Occasione che non è stata altro che la punta di un enorme iceberg: il tuo scarso ed imbarazzante livello di competenza.

Originariamente inviato da ekerazha

Per il resto c'è ben poco da trolleggiare.

Originariamente inviato da ekerazha

Le ultime parole famose di un uomo coerente

Originariamente inviato da ekerazha

ma se continui a rimuginare è segno che evidentemente hai la "coscienza sporca" (ed in effetti è probabile che sia così)

Originariamente inviato da ekerazha

Mi pare evidente come il tuo concetto di "dimostrare" sia assolutamente ridicolo e risibile, non avendo argomentato davvero nulla che sia anche lontanamente riconducibile alla pallida controfigura di una dimostrazione.

Originariamente inviato da ekerazha

Io dico semplicemente quello che penso e cioè che tu sia un programmatore pessimo e di scarsissima competenza... e come già detto non lo dico per offenderti ma è quello che penso in realtà e i motivi che mi hanno condotto a questo pensiero te li ho fatti notare più e più volte

Originariamente inviato da ekerazha

Ma tu continui a non capire fraintendendo di proposito le mie parole (e denotando anche una scarsa conoscenza dell'italiano) poichè le tue sciocche argomentazioni non potrebbero scalfire minimamente ciò che affermo effettivamente e sei quindi costretto a ricorrere a questi "giochetti" di tenore davvero basso.

Originariamente inviato da ekerazha

E' incredibile come nella mia "giovane vita", fra tutti i programmatori che ho conosciuto (alcuni dei quali lavorano come già detto in grandi multinazionali), i peggiori li possa incontrare insieme e nello stesso forum. E' una coincidenza stranissima.

se vuoi vado avanti

se consideri l'insulto in senso stretto, tipo "sei un cretino", beh, c'è pure questo, da "sei solo un poverccio" in poi

se invece, come ritengo più corretto, si considera l'insulto in senso lato, metà delle parole che hai scritte le hai spese così, per dire - estrapolandone il succo - che gli altri sono cretini

comunque, chiuso il discorso, sarei curioso di vedere un po' di codice php scritto da te

[mjordan]

Dopo questo incredibile riassunto di FX, mi sa che mi disiscrivo dalla discussione... Dovessi passare qualche settimana a farmi rigirare continuamente i post.