Crockford mantiene le specifiche di JSON. Crockford da parte del comitato ECMA per la standardizzazione di Javascript. Crockford ha scritto una serie di post su javascript che mi sento di condividere e che sono stati tradotti in diverse lingue tra cui il cinese ed il turco (con buona pace dei leghisti) ma non in italiano. Google non mi ha indirizzato ad altre traduzioni del pezzo che troverete di seguito. Non mi resta che ringraziare Douglas Crockford per la pronta e positiva risposta alla mia proposta di traduzione.
Javascript: Il linguaggio di programmazione più incompreso del mondo
Titolo originale: JavaScript: The World’s Most Misunderstood Programming Language
Douglas Crockford (www.crockford.com)
JavaScript, alias Mocha, alias LiveScript, alias JScript, alias ECMAScript, è uno dei linguaggi di programmazione più popolari. Teoricamente ogni personal computer al mondo ha installato almeno un interprete Javascript e lo usa correntemente. La popolarità di Javascript è dovuta interamente al suo ruolo di linguaggio di scripting per il WWW.
A dispetto della sua popolarità, pochi sanno che Javascript è un bellissimo linguaggio di programmazione dinamico, orientato agli oggetti e adatto a tutti gli ambiti di sviluppo. Come mai questa cosa è potuta restare un segreto? Perché questo linguaggio è così incompreso?
Il Nome
Il prefisso Java- suggerisce che in qualche modo Javascript sia legato a Java, che ne sia un sottinsieme o una versione ridotta. Sembra che il nome sia stato scelto proprio per creare confusione, e la confusione genera malintesi. Javascript non è un Java interpretato. Java è Java interpretato. Javascript è un altro linguaggio.composta
JavaScript è più simile sintatticamente a Java di quanto quest’ultimo non lo sia nei confronti del C. Ma non è un sottoinsieme di Java più di quanto Java non sia un sottoinsieme di C. Javascript è migliore di Java in quelle applicazioni per cui Java (già OAK) era stato pensato originariamente.
Javascript non è stato sviluppato da Sun Microsystem, il creatore di Java, ma da Netscape. Originariamente il suo nome era LiveScript, ma quel nome non era abbastanza ambiguo.
Il suffisso -Script suggerisce che non si tratti di un vero linguaggio di programmazione, che un linguaggio di scripting sia qualcosa di meno di un linguaggio di programmazione. In realtà è tutta una questione di specializzazione. Comparato al C, Javascript sacrifica le performance per guadagnare in forza espressiva e dinamismo.
Lisp travestito da C
La sintassi di Javascript, simile a quella del C, incluse le parentesi graffe e quello sgraziato costrutto for, lo fa sembrare un normale linguaggio procedurale. Si tratta di una falsa impressione perché Javascript ha più tratti in comune con i linguaggi funzionali come Lisp or Scheme che con C o Java. Ha array invece che liste e oggetti al posto delle property list. Le funzioni sono di prima classe. Ha le chiusure. Supporta le funzioni lambda senza dover bilanciare tutte quelle parentesi.
Casting dei tipi
JavaScript è stato progettato per funzionare in Netscape Navigator. Il suo successo ne ha fatto un componente standard di praticamente tutti i browser web. Questo ha portato al casting dei tipi. Javascript è il George Reeves dei linguaggi di programmazione. JavaScript è adatto ad una grossa fetta di applicazioni non web.
Bersaglio Mobile
La prima versione di Javascript era abbastanza debole. Mancavano la gestione delle eccezioni, le funzioni annidate e l’ereditarietà. Nella sua forma attuale è un completo linguaggio orientato agli oggetti. Purtroppo, molte opinioni sul linguaggio sono basate sulla sua forma immatura. Il comitato ECMA che ha preso in carico il linguaggio sta sviluppando estensioni che, anche se bene intenzionate, aggraveranno uno dei suoi maggiori problemi: ne esistono già troppe versioni. Questo crea confusione.
Errori di progettazione
Nessun linguaggio di programmazione è perfetto. Javascript ha la sua parte di errori di progettazione come l’overloading dell’operatore + ad indicare sia la somma che il concatenamento con coercizione di tipo, l’istruzione with che può generare errori ed andrebbe evitata. La politica di gestione delle parole riservate è troppo rigida. L’inserimento automatico dei punti e virgola è stato un grosso errore, così come la notazione usata per le espressioni regolari. Questi errori hanno portato ad errori di programmazione, e fatto discutere della progettazione dell’intero linguaggio. Fortunatamente, molti di questi problemi possono essere ridotti con un buon programma di lint.
Il design del linguaggio, nel suo insieme è buono. Sorprendentemente il comitato per l’ECMAScript non sembra interessato a risolvere questi problemi. Forse saranno interessati ad introdurne di nuovi.
Pessime Implementazioni
Alcune delle prime implementazioni di Javascript erano piene di bug. Questo ha avuto un cattivo impatto sulla reputazione del linguaggio. Oltretutto, quelle implementazioni erano associate a browser assolutamente malfunzionanti.
Brutti Libri
Quasi tutti i libri su Javascript sono atroci. Contengono errori, esempi poco calzanti, e incoraggiano cattive pratiche. Caratteristiche importanti del linguaggio sono appena accennate, spiegate male o tralasciate interamente. Ho recensito dozzine di libri su Javascript, e mi sento di raccomandarne soltanto uno:JavaScript: The Definitive Guide (5th Edition) by David Flanagan. (versione italiana).
(Attenzione autori: se avete scritto un buon libro, fatemene avere una copia da recensire.)
Standard al di sotto degli standard
Le specifiche ufficiali del linguaggio sono pubblicate dall’ECMA. Le specifiche sono scritte particolarmente male. Sono difficili da leggere e da capire. Questo ha avuto la sua parte nella stesura di una cattiva bibliografia perché gli autori non sono in grado di utilizzare questi documenti per migliorare la propria comprensione del linguaggio. ECMA e il comitato TC39 dovrebbero esserne profondamente imbarazzati.
Dilettanti
La maggior parte delle persone che programmano in Javascript non è costituita da programmatori professionisti. Mancano della disciplina e della formazione necessaria alla stesura di buoni programmi. Javascript ha una tale potenza espressiva da metterli comunque in grado di fare cose utili. Questo ha dato a Javascript la fama di linguaggio per dilettanti, non adatto allo sviluppo professionale. Semplicemente, non è così.
Orientamento agli oggetti
JavaScript è object-oriented? Ha oggetti che possono contenere dati e metodi che agiscono su questi dati. Gli oggetti possono contenere altri oggetti. Non ha classi, ma ha il concetto di costruttore che fa quello che ci si aspetta da una classe, anche funzionare da contenitore per variabili di classe e metodi. Non ha una ereditarietà basata sulle classi ma ne propone una basata su prototipi. Le due strategie più usate per costruire sistemi ad oggetti sono l’ereditarietà (is-a [è-un]) e l’aggregazione (has-a [ha-un]). Javascript permette entrambe, la sua natura di linguaggio dinamico, però, lo fa eccellere con l’aggregazione.
Qualcuno potrebbe ribattere che Javascript non è veramente orientato agli oggetti perché non supporta l’incapsulamento. Cioè un oggetto non può avere variabili e metodi privati: tutti i membri sono pubblici.
In realtà gli oggetti JavaScript possono avere variabili e metodi privati (click qui per scoprire come). Naturalmente, pochi ne sono a conoscenza perché Javascript è il linguaggio più incompreso del mondo.
C’è chi ribatte che Javascript non è un vero linguaggio ad oggetti perché non supporta l’ereditarietà. In realtà Javascript non si limita a supportare l’ereditarietà classica, ma permette anche altre forme di riutilizzo del codice.
Copyright 2001 Douglas Crockford.
All Rights Reserved Wrrrldwide.
Experimentalia 
Innanzitutto grazie per la traduzione.
Io avrei tradotto il titolo con: “JavaScript: il linguaggio di programmazione più frainteso al mondo”
Beh, ci ho pensato un pò prima di scegliere frainteso piuttosto che incompreso ed ho scelto quest’ultimo perché penso che vada meglio al nocciolo della questione:
A causa di un cattivo supporto e peggiori implementazioni iniziali, Javascript è stato sempre snobbato come linguaggio professionale. Io stesso, fin dai primi esperimenti con quel trabiccolo di netscape l’ho odiato a morte. Da qualche tempo non solo l’ho rivalutato, ne sono rimasto affascinato.
Volendo riassumere il tutto con una immagine: io sulla copertina della bibbia di Javascript, invece che un rinoceronte ci avrei messo Calimero.
ma esiste un SANO Linguaggio NON orientato agli oggetti? Insomma un VERO linguaggio di programmazione?
Saluti
Non credo che esistano linguaggi VERI o linguaggi FARLOCCHI. Penso che esistono centinaia di linguaggi ed ognuno di questi è più o meno adatto a risolvere particolari problemi piuttosto che altri. E penso che non ci sia nulla di male in tutto ciò.
Penso, poi, che ogni programmatore si senta a casa usando una certa classe di linguaggi piuttosto che altri, e sarebbe sciocco pretendere il contrario.
Se vuoi esplorare un vero linguaggio che non sia orientato agli oggetti puoi sempre provare erlang o haskell. Se poi per VERO linguaggio intendevi l’assembly allora non hai da fare altro che scaricare le specifiche del tuo processore di riferimento 😉
Traduzione vergognosamente piena di errori di ortografia: mi offro volontario per una versione corretta. Disponibile anche per un miglioramento sintattico, dato che molte virgole sono fuori posto e non viene fatto uso di punto e virgola e due punti!
E per quanto riguarda il linguaggio mi permetto di citare i linguaggi Xbase che derivano dal Clipper, compilabili per esempio con (X)Harbour: il quale è, tra le altre cose, free.
(X)Harbour permette di scrivere usando la sintassi OO, oppure a scelta di scrivere programmi strutturati in modo ‘procedurale’ come il BASIC di una volta; genera pseudocodice C che viene poi compilato con un compilatore C a scelta (p. es il Borland C, gratuito…) e permette di realizzare applicazioni ‘legacy’ o GUI, per Windows o Linux. Io ci scrivo anche delle CGI che utilizzo su server Linux in rete con PC Windows per fornire una interfaccia navigabile con un browser agli utenti di una intranet accessibile anche dal Web tramite un router e una connessione ADSL. Ma il problema vero a cui vorrei tornare è la mia incompleta conoscenza di Javascript, che mi serve come il pane per gestire le mie intranet, e che oltre agli inconvenienti già descritti da Crockford ha attraversato una rapida evoluzione e impone un costante aggiornamento, oltre ad essere poco e mal documentato, avere un differente parere praticamente per ogni commentatore su quali siano le buone pratiche e quelle cattive, diversi framework ognuno dei quali parla malissimo degli altri, differenti implementazioni sui diversi browser, bachi compresi, ecc. ecc.
Comunque ringraziamo il buon Crockford che è autore di un libro la cui importanza è innegabile, e il traduttore per il suo impegno.
Caro Daniele, innanzitutto ti ringrazio per la segnalazione dei refusi, qui da noi gli errori di ortografia li chiamiamo così ( 🙂 ) senza nasconderti che un più misurato utilizzo degli avverbi mi avrebbe permesso di farlo più calorosamente 😉
Purtroppo non conosco Xharbour, mi sono sempre tenuto il più lontano possibile da clipper, come dal Basic (specie quelli con le finestre), per questioni “filosofiche” probabilmente sbagliate.
Con queste premesse, ho cercato di dare una scorsa veloce all’homepage di Xharbour. Mi sembra si tratti di un linguaggio da utilizzare lato server e che non ha molto a che fare con Javascript che viene prevalentemente utilizzato, perdonami la semplificazione, lato client. Correggimi se per caso ne sono stato troppo precipitoso.
Per quanto riguarda Javascript mi permetto di consigliarti due libri: quello di Flanagan (trovi il link nell’articolo) è corposo ed esaustivo, e quello di Crockford (Javascript: the good parts) che al contrario è particolarmente snello e conciso ma che ha bisogno di una base teorica che un neofita (rispetto a Javascript o altri linguaggi evoluti) potrebbe non avere.
Ne ho parlato sul blog e, più tardi, provvederò a modificare l’articolo aggiungendo qualche link per chi non ha voglia o tempo di cercarli per proprio conto.
Un’ultima cosa: se ti senti particolarmente offeso dalle scelte stilistiche o da refusi presenti in questo posto o in altri post su questo blog, sentiti libero di comunicarmi le modifiche, se daccordo provvederò ad aggiornare i pezzi. Per questo pezzo in particolare, come per altri di Crockford, ho cercato di mantenere, per quanto mi è stato possibile, il ritmo sincopato che ha l’originale (credo si tratti di trascrizioni di presentazioni tenute dall’autore).
Gli strafalcioni, invece, sono tutti miei e me ne prendo piena responsabilità (oltre che l’onere di correggerli)
Devo ammettere che la frase ‘vergonosamente piena di errori’ non trasmette in alcun modo il mio spirito giocoso, quindi mi scuso e chiarisco che va presa come una voluta esagerazione, come dovrebbe suggerire il seguito della frase, che è amichevole.
😉
Xharbour deriva da Harbour, si tratta di compilatori ‘intermedi’ che si appoggiano ad un compilatore C (sono supportati Pelles C, Borland C, Microsoft C e MinGW se non ricordo male) open source.
Avendo iniziato con Clipper nel lontano … meglio non pensarci… ho seguito l’evoluzione di questo linguaggio, che non assomiglia a javascript, e la cui scarsa efficienza in termini di pura velocità lo rende adatto soprattutto per le applicazioni gestionali. E’ uno strumento alquanto potente e versatile in quanto, come richiedeva il messaggio al quale volevo rispondere, consente di programmare alla vecchia maniera procedurale, e in più ha una sintassi ad oggetti per chi preferisce questo stile di programmazione. Più versatile di così…
Si possono creare eseguibili legacy, dotati di GUI oppure CGI da eseguire tramite un Web server… Io ci scrivo praticamente qualsiasi cosa, se mi serve qualche comando in ambiente Linux faccio prima a scrivermelo su misura piuttosto di imparare la sintassi di cose come sed, procmail eccetera…
🙂 lo so che è scorretto ma è più pratico per me, ormai conosco xbase come le mie tasche e imparare cose nuove diventa sempre più seccante…
Per quanto riguarda la traduzione, ti posso dire solo che non ho sentito il bisogno di leggere l’originale in inglese, quindi credo che sia un buon lavoro!
Grazie per i consigli sui libri.
ed ecco gli errori, oops i refusi:
Definitivi:
mailntesiMinori:
La maggior parte delle persone che programmano in Javascript non sono programmatori.Il soggetto grammaticale (la maggior parte) è SINGOLARE, il verbo (sono) è plurale. Costrutto con soggetto logico (la maggior parte=soggetto collettivo) anziché grammaticale. Accettabile e usato spesso. Solo alcuni puristi avrebbero scritto la maggior parte… non è costituita da programmatori…Discutibili:
le performance = la velocità di esecuzione
Semplicemente, non è questo il caso= Semplicemente, non è così (suona meglio in italiano).Non riesco più a trovare gli altri refusi. Non è che me li hai scippati da sotto il naso correggendo il testo in real time tra un post e l’altro? 🙂
Cancella pure questo messaggio, è in effetti totalmente irrilevante (ma correggi MALINTESI)!
Eineki edit
Apportate le correzioni che condivido (e depennate dalla lista). Ho tralasciato solo performance, che mi piace di più che velocità di esecuzione in un blog tecnico come il mio finge di essere.
Non penso che il post sia irrilevante. Penso sia giusto che resti a testimoniare l’impegno che hai profuso nella lettura che non è poco.
Ovviamente ho corretto i refusi che mi sono saltati all’occhio in base alla tua prima segnalazione, ma l’ho fatto prima di rispondere al tuo commento. Quando qualcuno segnala qualcosa, il minimo che mi sembra doveroso fare è controllare le critiche e correggere quello che non va. Ti ho ringraziato perché mi hai dato una mano ad avere un blog migliore. Certamente non per le critiche, che sono permaloso come un serpente andino 🙂
Ciao eineki,
grazie per la splendida traduzione, solitamente leggo in inglese, ma per pigrizia alle volte, si può fare uno strappo, specialmente se il lavoro è ben fatto (anche con i refusi, non dar retta alle male lingue ;=) )
Sono ormai alcuni anni che scrivo in JavaScript e più passa il tempo e più mi innamoro del linguaggio. Purtroppo però solo ultimamente ho ottenuto l’opportunità di poter scrivere una parte importante di codice client side, su browser.
Volevo sapere da te se conosci un tutorial ben fatto che mi possa dare le linee guida, best-practice e strumenti da utilizzare, per poter mantenere il codice ben ingegnerizzato.
Vorrei evitare di scrivere porcherie che poi devo buttare via.
Grazie mille,
Davide.
Personalmente vedo le tecnologie di sviluppo agili molto adatte allo sviluppo con javascript anche se fatico a trovare dei buoni strumenti per il test drive development che si applichino a javascript. Mi sento di consigliarti qualche speech interessante (in inglese, ovviamente)
Un’altra area a cui mi dedicherei sono i design pattern, anche se non ho ancora trovato un buon libro che non sia anche noioso come un mattone. Quelli disponibili, inoltre, sono scritti pensando a linguaggi ad oggetti orientati alle classi piuttosto che ad oggetti e quindi sono da leggere cum grano salis. Mi sento di consigliarti Pro javascript design patterns costa un po’ ma mi sembra ben fatto.
Mi fermo qui, non conosco il tuo livello di conoscenza in materia e potrei continuare a segnalarti ovvietà o materiale troppo (non credo) avanzato per i tuoi scopi.
Per un dilettante allo sbaraglio come me il post è stato molto interessante soprattutto per il suggerimento per il libro da leggere. Credo valga la pena di approfondire la cosa… Grazie per le info 😉
Sai che non ho mai pensato al JS come un linguaggio di programmazione? Sara’ per l’uso limitatissimo che ne faccio, ma mi sembra piu’ uno pseudo-linguaggio per programmare azioni puramente web (clicca bottone, ommouseon, menu’ dinamici…)
E’ passato un po’ di tempo dal mio ultimo post e in questo intervallo non ho programmato per niente in javascript. Dato che è un linguaggio in evoluzione costante e che probabilmente non sono molto aggiornato, vorrei riportare qui alcune delle difficoltà e frustrazioni che me l’hanno fatto cordialmente odiare. Magari qualcuno si prenderà la briga di rispondere. Questo è anche un commento agli entusiasti che affermano che j. sia un linguaggio bellissimo, affascinante… ecc. ecc. Ovviamente io non sono d’accordo. Quelle che seguono sono opinioni personali.
1) Differenti implementazioni.
Il problema della compatibilità cross-browsers è secondo me particolarmente seccante e da solo basta a mettere fuori gioco javascript come linguaggio professionale. E’ semplicemente ridicolo ed estremamente dispersivo non doversi solo preoccupare di sintassi ed errori logici di programmazione, aggiungendo l’atroce compito di verificare attentamente se il programma che si è scritto gira allo stesso modo sugli infiniti browser disponibili. Questo comporta:
– Non esiste un modo certo di conoscere l’ambiente in cui lo script verrà eseguito e quindi i guru suggeriscono di usare il feature testing, ma questa è una tecnica complicata, fuori portata per chi inizia a programmare, anche per via del fatto che la distinzione tra host objects e native objects non viene subito colta e le due categorie vanno trattate diversamente.
– A causa dei diversi modelli implementati per varie cose (per esempio gli eventi), in effetti occorre scrivere le funzioni due volte, in buona sostanza per il modello Netscape e per quello Explorer.
2) Alcune mancanze del linguaggio:
a) Non c’è un sistema certo per capire quando gli oggetti sono tutti caricati nella pagina (quindi, per esempio, chiamare uno script in una frame o iframe può causare un errore perché al momento in cui lo script chiamante viene eseguito non c’è certezza che lo script chiamato sia effettivamente disponibile).
Chi ci ha provato, sa di quale incubo io stia parlando. Sono stati proposti diversi metodi, che vengono usati nelle varie librerie (o framework) ma non sembra che sia stata detta una parola definitiva. Io mi ero risolto a usare la tecnica detta di “script injection” ovvero l’ultimo script della pagina principale mediante document.write() scrive lo script da invocare nella frame o iframe child, il che però presentava problemi di compatibilità, in particolare con Opera che non scriveva nelle Iframes, ecc. ecc. Alla fine mi sono ridotto a caricare nelle frames/iframes quello che mi occorre sempre corredato da un piccolo script che setta una variabile (top.frame1ready…), al che lo script principale può sapere quando il contenuto è stato caricato. Ma vi pare possibile???
b) la sintassi è complicata (per esempio nella definizione di funzioni anonime), e ci sono concetti abbastanza oscuri (delegation, event bubbling, namespace, closure…).
Potrei andare avanti ma ho già scritto un romanzo. A chi mi vorrà rispondere: com’è la situazione oggi? che ne è delle varie mootools, jquery, dojo, cappuccino ecc.? E’ migliorata la situazione della compatibililtà cross-browsers?
Forse se Javascript è il linguaggio più incompreso al mondo qualche motivo c’è…
E’ qualche giorno che mi lambicco il cervello su come rispondere al tuo commento fiume, Daniele.
E’ carico di spunti di discussione e mi dispiace lasciarlo andare, penso che rispolvererò la tastiera per un post ad hoc. Anzi comincio subito, anche se non so dirti tra quanto finirò.
Grazie Eineki per l’attenzione. Non c’è fretta per la risposta, non scappo. Dato che inviare un post su un forum tecnico solo per dire grazie è un’eresia, vorrei anche segnalare che spesso siti istituzionali, per esempio Bnl e Intesa, ma anche Citigroup, semplicemente ignorano i problemi di compatibilità cross-browsers e realizzano i loro sistemi di e-banking per uno-due browsers (IE e Firefox, per lo più.) Il mio povero Opera, che a me piace tantissimo, di solito non se lo fila nessuno e non è in grado di eseguire alcuni script. Il sistema di gestione del recupero crediti di Citifin (outside collector) funziona SOLO con internet explorer, e nemmeno tutte le versioni. Ragazzi, stiamo parlando di Citibank, la banca n. 1 al mondo. Questo solo per dire che non sono qui a fare polemiche da visionario o da pignolo. Non riesco a capire come mai la situazione sia così assurda, soprattutto se consideriamo la standardizzazione dell’hardware, per cui si prende una mainboard costruita in Corea, si sbatte dentro una scheda video contenente 16 milioni di transistor fatta nella Silicon Valley e tutto magicamente funziona. Insomma ormai uso javascript solo per cose minimali, ho rinunciato completamente all’idea di fare animazioni o cose complesse. Anche così riesco a incasinarmi. L’ultima scoperta? window.location di, poniamo, httpqualcosa/index.html restituisce httpqualcosa/index.html in Firefox e Opera, ma in IE httpqualcosa/ (senza index.html). Frustrante.