Imparare programmazione, lavorare o studiare?

[Vincenzo1968]

http://www.hwupgrade.it/forum/showthread.php?t=2033527


Uh! Scriversi il parser a manina... Passaggio obbligato... E ANTLR?

[shinya]

Originariamente inviato da vendettaaaaa

Dev'essere un odio di categoria tramandato dai professori. Come l'odio per gli Ingegneri Gestionali che viene trasmesso a tutti gli altri Ingegneri dai loro prof, almeno qui a Milano.

No è che l'Italia è fatta di mafie e parrocchie.

[shinya]

Originariamente inviato da cdimauro

E no, non serve digerire interamente il Dragon Book; uno strumento come ANTLR ti consente di arrivarci di gran lunga più rapidamente e comodamente, senza scomodare la teoria che sta alla base delle grammatiche.

Oh, speriamo non muoia l'autore di ANTLR però eh... Cioè, metti che scoppi l'apocalisse zombie...

[cdimauro]

Originariamente inviato da Vincenzo1968

http://www.hwupgrade.it/forum/showthread.php?t=2033527


Uh! Scriversi il parser a manina... Passaggio obbligato... E ANTLR?

Hai dimenticato il contesto: si parlava di piccoli progetti.

Linguaggi più complicati realizzarli senza tool automatici è da sbattersi la testa contro un muro.

Difatti 23 o 24 anni fa (non ricordo bene adesso) realizzai un parser per espressioni in assembly 68000, e mi feci un discreto mazzetto. Dopo quell'esperienza, 3-4 anni dopo realizzai un parser per un linguaggio relazionale (per il progetto di Sistemi 1, che è il mattone equivalente di Algoritmi oggi) un po' più complesso, ma in C.

Gli altri linguaggi che ho sviluppato, decisamente più complessi, li ho realizzati coi tool automatici (TPYacc per Turbo Pascal / Delphi, e infine ANTLR).

Originariamente inviato da shinya

Oh, speriamo non muoia l'autore di ANTLR però eh... Cioè, metti che scoppi l'apocalisse zombie...

E' da un pezzo che non scrivo compilatori, per cui non mi pongo il problema. Poi mi pare fossero disponibili i sorgenti.

Al limite cerco altro, perché non mi posso mettere a reinventare la ruota. Non ho più tempo per cazzeggiare: devo essere produttivo quanto prima.

[shinya]

Originariamente inviato da cdimauro

E' da un pezzo che non scrivo compilatori, per cui non mi pongo il problema. Poi mi pare fossero disponibili i sorgenti.

Al limite cerco altro, perché non mi posso mettere a reinventare la ruota. Non ho più tempo per cazzeggiare: devo essere produttivo quanto prima.

No no ma su questo non ci piove. Volevo dire che a sentimento a me sembra che l'argomento 'compilatori/interpreti' sia piuttosto importante e di base. Cioè, dire che uno si può laureare in informatica senza saperne una mazza... boh... non me la sento di sottoscrivere.

[Vincenzo1968]

In B4: Eh ma GCC fa schifo; farina del sacco di Stallman; Eh ma Linux.

Originariamente inviato da cdimauro

Hai dimenticato il contesto: si parlava di piccoli progetti.

Linguaggi più complicati realizzarli senza tool automatici è da sbattersi la testa contro un muro.

Difatti 23 o 24 anni fa (non ricordo bene adesso) realizzai un parser per espressioni in assembly 68000, e mi feci un discreto mazzetto. Dopo quell'esperienza, 3-4 anni dopo realizzai un parser per un linguaggio relazionale (per il progetto di Sistemi 1, che è il mattone equivalente di Algoritmi oggi) un po' più complesso, ma in C.

Gli altri linguaggi che ho sviluppato, decisamente più complessi, li ho realizzati coi tool automatici (TPYacc per Turbo Pascal / Delphi, e infine ANTLR).

E' da un pezzo che non scrivo compilatori, per cui non mi pongo il problema. Poi mi pare fossero disponibili i sorgenti.

Al limite cerco altro, perché non mi posso mettere a reinventare la ruota. Non ho più tempo per cazzeggiare: devo essere produttivo quanto prima.

Ma se i programmatori di GCC hanno deciso di scriverselo a mano il loro parser...

Nelle prime versioni utilizzavano Bison, nelle ultime versioni utilizzano un parser a discesa ricorsiva scritto interamente a mano.

Per questa sera sono stanco di cercare il thread. Mi sono smazzato le prime 21 pagine dal mio elenco sottoscrizioni. Domani continuo...

Originariamente inviato da cdimauro

...
E no, non serve digerire interamente il Dragon Book; uno strumento come ANTLR ti consente di arrivarci di gran lunga più rapidamente e comodamente, senza scomodare la teoria che sta alla base delle grammatiche.

A un programmatore interessano principalmente due cose: il concetto di algoritmo, e la capacità di risolvere problemi (rispettandone i requisiti).
...

Non serve digerire interamente il Dragon Book però per un programmatore "è un passaggio obbligato"(cit.) scriversi un parser a manina... Secondo me ti contraddici.

Si, certo, sull'interamente siamo d'accordo; uno può, inizialmente, saltare gli ultimi capitoli sugli aspetti avanzati(ottimizzazione del codice prodotto, etc), ma come fai a "scrivere un parser a manina"(cit) senza il Dragon Book(o testo equivalente ma, l'hai scritto tu, il Dragon Book è la Bibbia sull'argomento).

[WarDuck]

Originariamente inviato da coffe_killer

perfettamente d'accordo, l'unica differenza dal tuo corso di studi al mio è che il corso di compilatori era obbligatorio,e anche io mi sono laureato in informatica come te...e visto che qualcuno lo ha tirato in mezzo, il mio migliore amico si è laureato in ingegneria informatica a milano, una delle più rinomate in italia, e a livello di competenze ne so più io, semplicemente per il fatto che gli ingegneri fanno i gradassi dicendo che loro a lavorare non dovranno mettere mano la codice, ma dovranno darci dei lavori che noi semplici informatici svolgeremo, e loro prenderanno il merito; per questo ce l'ho con gli ingegneri...di riempiono la bocca con il loro titolo (che non è nemmeno vero perchè per essere ingegnere a tutti gli effetti devi fare l'esame di stato ed iscriverti all'albo, altrimenti sono semplici "dottori" come me) e a livello di competenze hanno solo da imparare

Quindi ne deduciamo che presa una persona a e una persona b rispettivamente dagli insiemi A e B (di cardinalità molto elevate), tale per cui competenza(a) > competenza(b), questo è sufficiente per affermare che complessivamente competenza(A) > competenza(B).

Non c'è che dire logica esemplare .

Ti do un suggerimento: le competenze ce le hanno le persone, non i loro titoli. Se pensi che un titolo sia sufficiente per valutare le competenze di una persona, allora stiamo messi male, molto male.

[Mettiu_]

Originariamente inviato da WarDuck

Quindi ne deduciamo che presa una persona a e una persona b rispettivamente dagli insiemi A e B (di cardinalità molto elevate), tale per cui competenza(a) > competenza(b), questo è sufficiente per affermare che complessivamente competenza(A) > competenza(B).

Non c'è che dire logica esemplare .

Ti do un suggerimento: le competenze ce le hanno le persone, non i loro titoli. Se pensi che un titolo sia sufficiente per valutare le competenze di una persona, allora stiamo messi male, molto male.

No ma tra l'altro lui critica i diplomati perchè si sentono troppo forti su compilatori & co, critica gli ingegneri perchè sono "troppo distanti dal codice", dalla programmazione vera (ma come? non era riduttivo l'appellativo "programmatore"?). Lui critica tutti, gli unici bravi sono gli informatici punto. coffe_killer, ti chiedi davvero perchè la gente non ti risponde seriamente?

[cdimauro]

Originariamente inviato da shinya

No no ma su questo non ci piove. Volevo dire che a sentimento a me sembra che l'argomento 'compilatori/interpreti' sia piuttosto importante e di base. Cioè, dire che uno si può laureare in informatica senza saperne una mazza... boh... non me la sento di sottoscrivere.

Cerchiamo di chiarire: come funziona un parser e un compilatore lo dovrebbe sapere chiunque prenda quel fatidico pezzo di carta.
Adesso non ricordo dov'è stato affrontato l'argomento, ma almeno al corso di Linguaggi di Programmazione, dove abbiamo studiato in lungo e in largo la programmazione funzionale con Scheme e logica con Prolog, ne abbiamo sicuramente parlato, e il professore alla fine del corso ha abbozzato velocemente un interprete Scheme scritto in Scheme.

Tutt'altra cosa è scrivere un parser/interprete/compilatore.

La prima la sottoscrivo. La seconda no, perché è una specializzazione che si può ottenere o con un corso apposito, oppure una volta fuori dall'università.

Il motivo, peraltro, è molto semplice: molto raramente nel lavoro di tutti i giorni ci si scrive un parser, e ancora più raramente un interprete, una virtual machine per farlo girare, o addirittura un compilatore.

Originariamente inviato da Vincenzo1968

In B4: Eh ma GCC fa schifo; farina del sacco di Stallman; Eh ma Linux.

Ma lo vedi che vuoi soltanto polemizzare e provocare? Mah

Ma se i programmatori di GCC hanno deciso di scriverselo a mano il loro parser...

E quindi? Da questo cosa si dovrebbe dedurre? Che dovrebbero fare tutti così? Solo perché l'hanno fatto loro? E perché?

Nelle prime versioni utilizzavano Bison, nelle ultime versioni utilizzano un parser a discesa ricorsiva scritto interamente a mano.

Si vede che vogliono recuperare il gap con altri compilatori. GCC è uno dei compilatori più lenti. E' talmente lento che il team di BSD ha deciso, anni fa, di staccarsene e farsi un proprio compilatore, che dalle prime stime era 10 volte più veloce.

Non credo che prendere a modello un bloatware possa incidere sui termini della questione.

Per questa sera sono stanco di cercare il thread. Mi sono smazzato le prime 21 pagine dal mio elenco sottoscrizioni. Domani continuo...

Fai pure, visto che hai tempo.

Non serve digerire interamente il Dragon Book però per un programmatore "è un passaggio obbligato"(cit.) scriversi un parser a manina... Secondo me ti contraddici.

Secondo me se non riporti interamente la frase e non consideri il contesto non ci fai una bella figura, perché si chiama mistificazione.

Si, certo, sull'interamente siamo d'accordo; uno può, inizialmente, saltare gli ultimi capitoli sugli aspetti avanzati(ottimizzazione del codice prodotto, etc), ma come fai a "scrivere un parser a manina"(cit) senza il Dragon Book(o testo equivalente ma, l'hai scritto tu, il Dragon Book è la Bibbia sull'argomento).

Intanto che sia il testo di riferimento nel campo dei parser e dei compilatori è assodato, ma ciò non toglie che esistano altri testi molto validi che consentono di farne a meno. Ricordo che nel '90 o nel '91 trovai "Crafting a C compiler" (se non ricordo male il nome), che era pure più chiaro per quanto riguarda gli ultimi capitoli sulle ottimizzazioni e la generazione di codice oggetto. Questo tanto per fare un esempio.

Ciò precisato, il parser a manina lo scrissi quando smanettavo con l'Amiga e il Dragon Book non sapevo nemmeno cosa fosse. Da smanettone, appunto, a dimostrazione che si può benissimo fare a meno delle sue nozioni teoriche per scrivere un parser; e ci mancherebbe che non fosse così, visto che prima di questo libro la ricerca in quel campo è stata floridissima.

Qui, inoltre, tu stai mischiando malamente due cose che ho detto in due thread totalmente diversi. Un conto è quando ho scritto del parser scritto "a manina", in QUEL contesto (vedi sotto), e una cosa completamente diversa è la citazione del Dragon Book.

E francamente, a questo punto, vorrei capire dov'è che vorresti arrivare con questo minestrone.

D'altra parte, sei stato tu stesso ad affermare che:

Ovviamente parliamo di piccoli progetti, come quello del contest. In caso contrario l'uso di tool automatici diventa quasi obbligatorio.

E qui mi pare che, invece, sia proprio tu a contraddirti, e l'esempio del GCC che hai riportato è diametralmente opposto rispetto a ciò che hai detto, appunto, nell'altro thread.

Adesso non uscirtene nuovamente con un "Adieu e cavoli vostri(cit.)", e cercare di chiarire cos'hai in mente, perché non è affatto chiaro.

@Warduck: concordo che, alla fine, ciò che conta è la competenza della persona. Il titolo serve principalmente per le aziende che senza un pezzo di carta non ti calcolano.

[Vincenzo1968]

Qua l'unica vera contraddizione è:

problem solving qua, problem solving la, A un programmatore interessano principalmente due cose: il concetto di algoritmo, e la capacità di risolvere problemi (rispettandone i requisiti).

Non fai altro che ripeterlo ma quando si tratta di risolvere i problemi, come quello delle grammatiche con produzioni mutuamente ricorsive, non sai che pesci prendere. Altro che problem solving.
Il compilatore no perché ci vuole tempo e risorse. Ma cazzo, nemmeno un piccolo algoritmo...

Quasi obbligatorio. Appunto: quasi. Ho scritto "quasi" perché a conoscenza di notevoli eccezioni come GCC.

In quanto a polemizzare da te posso solo imparare. Non è forse vero che approfitti di ogni occasione per dire che il C fa schifo, gcc farina del sacco di Stallman e bla bla bla...

Da questo che cosa si dovrebbe dedurre? Uh! allora da quello che affermi(e dico affermi, senza mai anteporre le due paroline "secondo me", che cosa si dovrebbe dedurre? Che dobbiamo tutti programmare in Python? Che Java se lo conosci bene, ma se non lo conosci campi anche meglio? E per iniziare a programmare? C'è solo Python?

[Vincenzo1968]

La prima cosa che hai scritto da quando sono tornato a frequentare il forum:

"Non ho tempo da perdere col C e con Bison".

Poi sono io che polemizzo

[cdimauro]

Originariamente inviato da Vincenzo1968

Qua l'unica vera contraddizione è:

problem solving qua, problem solving la, A un programmatore interessano principalmente due cose: il concetto di algoritmo, e la capacità di risolvere problemi (rispettandone i requisiti).

Non fai altro che ripeterlo ma quando si tratta di risolvere i problemi, come quello delle grammatiche con produzioni mutuamente ricorsive, non sai che pesci prendere. Altro che problem solving.
Il compilatore no perché ci vuole tempo e risorse. Ma cazzo, nemmeno un piccolo algoritmo...

Facciamo così. Tu mi progetti l'architettura di un processore che:

-(all'incirca a parità di silicio) è più efficiente di x86 e x64 (cioè ha prestazioni mediamente superiori);
- ha una decodifica delle istruzioni (a lunghezza variabile) di gran lunga più semplice di x86 e x64, all'incirca comparabile a quella di Thumb-2 di ARM, e che pertanto richiede pochissimi stadi di pipeline (probabilmente ne basta uno soltanto) per la sola decodifica (leggi: più efficiente) e consumi estremamente ridotti;
- ha una densità di codice leggermente superiore a x86, ma nettamente inferiore a x64;
- ha 32 registri utilizzabili rispetto ai 16 massimo di x64;
- tutte le istruzioni ternarie, binari, e unarie possono essere opzionalmente "promosse" come quaternarie, ternarie e binarie rispettivamente (leggi: si può specificare un ulteriore registro come sorgente, al posto della solita destinazione che funge anche da uno dei due registri sorgente);
- ha nuove modalità d'indirizzamento che consentono di aggiornare i registri base con pre o post incremento/decremento, oppure di aggiungere loro un offset, ed è possibile specificare indifferentemente indirizzi assoluti o relativi (rispetto al PC);
- può gestire valori immediati a 64 bit (x64 consente soltanto di caricarli sui registri e basta);
- permette di accedere alla parte alta (bit 8-15) di ogni registro per qualunque istruzione (in pratica è ortogonale, mentre con x64 i registri "alti" si possono usare soltanto in alcuni casi, mentre in altri è impossibile);
- consente di eseguire salti condizionati rispetto al valore di un registro, o confrontando due registri;
- ha istruzioni e altre caratteristiche per consentire di emulare più facilmente altre architetture, x86 e x64 in primis;
- ha parecchio spazio per aggiungere altre istruzioni;
- ha un'unità SIMD che consente di manipolare valori a 128, 256, 512 o 1024 bit (cosa che avverrà in futuro; al momento siamo a 512 bit con Larrabee/Knights Corner) in maniera ortogonale e trasparente;
- ha un'unità SIMD con 128 registri (x64 ne ha 16; Larrabee 32) e 16 registri di masking (come Larrabee, ma che ne ha 8);
- l'unità SIMD supporta da centinaia a migliaia di istruzioni quaternarie, ternarie, e binarie;
- l'unità SIMD consente di specificare nuove modalità d'indirizzamento o di utilizzo dei registri vettoriali di gran lunga più flessibili rispetto a SSE/AVX/AVX2 e a Larrabee;
- unisce il meglio di AVX/AVX2 e Larrabee, senza perdere nulla rispetto a ogni unità SIMD;
- è compatibile a livello di sorgente con x86, x64 e Larrabee;
- emula x86 o x64 all'incirca alla stessa velocità.
In buona sostanza, unisce il meglio di x86/x64/Larrabee e ARM/Thumb-2 (a livello di decodifica e relativi consumi), offrendo molto di più.

e io, a questo punto, il mio tempo lo potrò perdere con le sciocchezze a cui stai lavorando tu.

Con ciò, se non fosse chiaro, voglio dire che ognuno ha i propri interessi, ed è a quello che vi dedica il proprio tempo.
Ti sei interessato ai parser, mentre io alla progettazione dell'architettura di nuovi processori, per cui la tua richiesta nei miei confronti lascia il tempo che trova (non è il mio né il mio interesse né ho voglia di mettermi a studiarmi per una cosa che, tra l'altro, nemmeno mi serve), e idem la mia nei tuoi.

Quasi obbligatorio. Appunto: quasi. Ho scritto "quasi" perché a conoscenza di notevoli eccezioni come GCC.

E hai detto niente...

In quanto a polemizzare da te posso solo imparare. Non è forse vero che approfitti di ogni occasione per dire che il C fa schifo, gcc farina del sacco di Stallman e bla bla bla...

Quelle sono battute. Acide, ma sempre battute. Tu, invece, ti prendi e le prendi troppo sul serio, tant'è che poi le spiattelli alla prima occasione.

Da questo che cosa si dovrebbe dedurre? Uh! allora da quello che affermi(e dico affermi, senza mai anteporre le due paroline "secondo me", che cosa si dovrebbe dedurre? Che dobbiamo tutti programmare in Python? Che Java se lo conosci bene, ma se non lo conosci campi anche meglio? E per iniziare a programmare? C'è solo Python?

Stai divagando. Ho esposto chiaramente il mio pensiero, e tanto basta.

Originariamente inviato da Vincenzo1968

La prima cosa che hai scritto da quando sono tornato a frequentare il forum:

"Non ho tempo da perdere col C e con Bison".

Poi sono io che polemizzo

Ma di quale polemica parli? Quella che ho scritto è la pura verità, e non c'è nulla di offensivo, se non per te che ti senti perseguitato da affermazioni come le mie.

Lo dimostra anche il tuo ossessivo cercare nei vecchi thread, nella speranza di trovare qualche appiglio per portare acqua al tuo mulino. Ne stai facendo una malattia. Infatti avevi scritto di abbondare il thread, e invece continui a tornare qui a intervenire: è, appunto, un'ossessione la tua.

Comunque è evidente che hai un sacco di tempo da perdere. Io no, e quella frase che hai riportato è l'esatto specchio del mio modus operandi: il poco tempo che ho preferisco impiegarlo al meglio, appunto.

[Vincenzo1968]

Minchiate. Tutte scuse. Non hai voglia, non hai tempo... Non lo sai fare! Problem not solving.

Che tempo e tempo! C'ho perso mezz'oretta per trovare la soluzione.
Uh! non ha tempo! Millemila messaggi contro i miei 1500 e non ha tempo.

Quando si tratta di codificare non ha mai tempo.

[cdimauro]

Il tempo lo impiego come lo voglio io e alle cose che m'interessano. Soprattutto a cose che ritengo utili.

Al mio progetto è da un anno e mezzo che lavoro concretamente, dopo parecchio tempo impiegato a rifletterci, e mi sto muovendo per cercare di realizzarlo.

Tu il tuo giocattolo presentalo a Stallman.

Poi, visto che di tempo ne hai parecchio, realizzala tu, se ci riesci, un'architettura con tutte le caratteristiche ho elencato sopra. Magari in mezz'ora troverai la soluzione...

[Tommo]

A sto giro sono d'accordo con Vincenzo per un motivo: scrivere un parser di un certo livello significa sbattere la faccia contro una buona parte dei problemi fondamentali dei modelli informatici, e anche se poi uno non deve stare a scrivere parser tutti i giorni sono conoscenze che ti guidano anche quando devi scrivere una cagata in javascript, che magari ti fanno balenare in mente che fare un new dentro ogni iterazione di un ciclo for potrebbe essere male.
Così come sapere com'è fatto un processore, saper abbozzare un programma in asm, etc.

Perchè non è tanto vero che a usare frameworks sono buoni tutti... se non sai risolvere il problema nella tua testa non ci sta tool che tenga, specie se punti all'efficienza massima.

@cdimauro a occhio non mi sembra una cosa fattibile quella che dici

[cdimauro]

Originariamente inviato da Tommo

A sto giro sono d'accordo con Vincenzo per un motivo: scrivere un parser di un certo livello significa sbattere la faccia contro una buona parte dei problemi fondamentali dei modelli informatici, e anche se poi uno non deve stare a scrivere parser tutti i giorni sono conoscenze che ti guidano anche quando devi scrivere una cagata in javascript, che magari ti fanno balenare in mente che fare un new dentro ogni iterazione di un ciclo for potrebbe essere male.
Così come sapere com'è fatto un processore, saper abbozzare un programma in asm, etc.

Perchè non è tanto vero che a usare frameworks sono buoni tutti... se non sai risolvere il problema nella tua testa non ci sta tool che tenga, specie se punti all'efficienza massima.

Per far questo sono di gran lunga più importanti le conoscenze di basso livello, e un buon profiler. Scrivere un parser o compilatore non aiuta allo stesso modo, ed è sufficiente una conoscenza di base, come quella di cui parlavo prima, sull'argomento.

@cdimauro a occhio non mi sembra una cosa fattibile quella che dici

Dalla beta pubblica di Photoshop CS6 a 32 bit:

Instructions: 1746569    Size: 5634556    NEW ISA Size: 5982402    Diff: 347846 (+6.2%)
Average x86     length: 3.2
Average NEW ISA length: 3.4

Dalla beta pubblica di Photoshop CS6 a 64 bit:

Instructions: 1737331    Size: 7556180    NEW ISA Size: 6239790    Diff: -1316390 (-17.4%)
Average x64     length: 4.3
Average NEW ISA length: 3.6

Una breve spiegazione: sono state disassemblate circa 1,7 milioni di istruzioni degli eseguibili della beta pubblica di Photoshop CS6, rispettivamente a 32 e 64 bit, e riassemblate nelle esatte equivalenti istruzioni della mia nuova architettura.

Il risultato è che rispetto a x86 in media le istruzioni sono più lunghe di circa 0,2 byte, mentre rispetto a x64 sono più corte di 0,7 byte.

Stiamo parlando di una traduzione molto rozza, quindi utile magari per un emulatore x86 o x64. Non vengono usate caratteristiche specifiche della nuova ISA, che possono portare tranquillamente a una densità migliore, come pure a prestazioni migliori.
Ad esempio, nella traduzione di codice x86 vengono usati i soliti 8 registri, mentre per x64 i soliti 16, quando a disposizione ce ne sono ben 32; ovviamente niente istruzioni ternarie (es: A = B + C) che consentirebbero di risparmiare almeno un'istruzione, niente modalità d'indirizzamento con post incremento che consentirebbero di risparmiare l'incremento del registro indice, niente istruzioni di confronto fra registri e salto, che consentirebbero di risparmiare ancora un'altra istruzione, ecc. Margini per migliorare il codice sia come densità che come prestazioni ce ne sono ancora parecchi, come puoi immaginare.

L'architettura soddisfa tutti i requisiti esposti, e... qualche altra cosa.

Ovviamente non posso divulgare altre informazioni oltre ai risultati delle mie simulazioni, anche perché su alcuni dettagli è possibile che si possano richiedere e ottenere dei brevetti.

[misterx]

Originariamente inviato da Tommo

A sto giro sono d'accordo con Vincenzo per un motivo: scrivere un parser di un certo livello significa sbattere la faccia contro una buona parte dei problemi fondamentali dei modelli informatici, e anche se poi uno non deve stare a scrivere parser tutti i giorni sono conoscenze che ti guidano anche quando devi scrivere una cagata in javascript, che magari ti fanno balenare in mente che fare un new dentro ogni iterazione di un ciclo for potrebbe essere male.
Così come sapere com'è fatto un processore, saper abbozzare un programma in asm, etc.

Perchè non è tanto vero che a usare frameworks sono buoni tutti... se non sai risolvere il problema nella tua testa non ci sta tool che tenga, specie se punti all'efficienza massima.

@cdimauro a occhio non mi sembra una cosa fattibile quella che dici

ne ho scritte tantissime di quelle cose come le chiami tu in javascript e le conoscenze di parser nemmeno l'ombra.
Vi siete dimenticati lo scopo principale dell'informatico: creare strumenti usabili da tutti non solo da pochi. Javascript è un linguaggio alla portata di tutti e non servono conoscenze particolari per scrivere qualcosa di decente.

I parser sono stati inventati almeno 30'anni fa e a meno che non si faccia ricerca la loro conoscenza ha valore puramente accademico, nel mondo del lavoro non vi serve a nulla saper implementare un linguaggio esistono già e non ti semplificano la vita nel risolvere problemi. Spendete meglio il vostro tempo a meno che non siate ancora studenti.

[cdimauro]

Assolutamente d'accordo. E aggiungo che per realizzare parser non serve nemmeno tutta la teoria dei linguaggi formali. Oggi, fortunatamente, ci sono strumenti che consentono di tirare fuori velocemente un parser, e ti controllano pure se la grammatica è ambigua o genera produzioni infinite che non si possono gestire.

La teoria è importante per chi decide di fare ricerca in questo campo. Nella vita di tutti i giorni di un normale programmatore sono sufficienti le nozioni che si apprendono all'università.

[Vincenzo1968]

Originariamente inviato da Tommo

A sto giro sono d'accordo con Vincenzo per un motivo: scrivere un parser di un certo livello significa sbattere la faccia contro una buona parte dei problemi fondamentali dei modelli informatici, e anche se poi uno non deve stare a scrivere parser tutti i giorni sono conoscenze che ti guidano anche quando devi scrivere una cagata in javascript, che magari ti fanno balenare in mente che fare un new dentro ogni iterazione di un ciclo for potrebbe essere male.
Così come sapere com'è fatto un processore, saper abbozzare un programma in asm, etc.

Perchè non è tanto vero che a usare frameworks sono buoni tutti... se non sai risolvere il problema nella tua testa non ci sta tool che tenga, specie se punti all'efficienza massima.

@cdimauro a occhio non mi sembra una cosa fattibile quella che dici

This.

[cdimauro]

I problemi "fondamentali" di cui parla li si affronta nel corso di Algoritmi, dal quale attingono praticamente tutti: compilatori (hash table), database (red & black tree), mappe (grafi con percorsi), ecc. ecc.