☺
Scritto da
Nazi Heidi
Wakkus Horribilis
il 2018-02-28 10:14:54.0 alle 2018-02-28 10:14:54.0
Trollate totali: 4162
Nobody is more inferior than those who insist on being equal. - Nietzsche
MA checcazzo ne so
Ad
http://sallo.it
LO SAI? Allora NON fa per te. NON LO SAI? Allora non ti serve.
☺
Scritto da
Nazi Heidi
Wakkus Horribilis
il 2018-02-25 01:45:03.0 alle 2018-02-25 01:45:03.0
Trollate totali: 4162
Nobody is more inferior than those who insist on being equal. - Nietzsche
☺
Scritto da
il 2013-01-15 03:02:38.0 alle 2013-01-15 03:02:38.0
Trollate totali: 2001
I link segnalati da suoranciata sono questi:
http://jlouisramblings.blogspot.it/2011/10/musings... 
e
http://www.quirksmode.org/blog/archives/2011/10/da...
Partiamo dal primo.
Ammette di aver visto Dart solo dalle specifiche... e di averci dedicato sopra solo un paio d'ore. Tuttavia è abbastanza onesto da dire "queste sono le mie prime impressioni e potrei sbagliarmi".
Bene, per lo meno non è un perlaro.
La prima parte dell'articolo, diciamo una buona fetta, si limita a descrivere Dart in base a quanto ha letto sulle specifiche.
Fa un'analisi interessante sul linguaggio anche se alcune domande rimangono in sospeso perché, come ha detto, basa le sue impressioni su ciò che può vedere dalle specifiche ma non ha scaricato Dart per provarlo. Per esempio chiede "è possibile assegnare a un bool il valore null"? La risposta è si, ho provato a farlo e Dart non si è lamentato. In realtà non so perché sia possibile farlo, dato che non conosco Dart così bene, ma se bool è una classe di oggetti come posso assegnare poi quella variabile ad un'altra classe di oggetti (null)? Qui bisognerebbe sapere come si comporta internamente Dart e sarebbe interessante saperlo. Probabilmente nella documentazione ci sta scritto.
Ad ogni modo. La critica più grossa a Dart è che non introduce niente di non visto in altri linguaggi. Fa un paio di comparazioni con Javascript... e altre con Go, Java, Ocaml e Erlang... nessuno dei quali (Javascript a parte) gira su un browser.
Nella comparazione con Javascript dice solo che Dart supporta l'OO classico mentre Javascript la programmazione OO mediante prototipazione e dice anche che si vede che alcune scelte di Dart sono state fatte per velocizzare i tempi di caricamento e di compilazione al confronto di Javascript. Questa è praticamente tutto ciò che dice circa Dart vs Javascript.
Dice che alcune idee sono interessanti ma che esistono linguaggi più interessanti, come Go, che però non gira sui browser (d'altra parte Go è pensato per rimpiazzare C/C++, non Javascript).
In altre parole l'intero articolo è una mera (anche se interessante) descrizione di Dart con un paio di critiche finali circa il fatto che Dart bene o male non ha inventato nulla che non esista già in altri linguaggi che nulla hanno a che fare con i browser, d'altra parte perché avrebbe dovuto? Il suo scopo mica è inventare una nuova branca di linguaggi... semplicemente migliorare l'approccio usato da Javascript. Inoltre dice che gli isolate potevano essere implementati meglio e su questo non so pronunciarmi quindi facciamo finta che abbia ragione ma anche se fosse non credo possa essere usato come argomentazione per dire che Javascript è migliore di Dart o che non valga la pena impararsi Dart.
Conclusioni sul primo link:
Vabbé... mi chiedo che senso abbia comparare un linguaggio di scripting per browser con linguaggi che con i browser non c'azzeccano nulla... ovviamente la cosa non mi aiuta a capire perché dovrei rimanere con Javascript e lasciar perdere Dart. Insomma, se sono uno che deve decidere quale dei due mettermi a studiare questo articolo non mi dice nulla a parte che Dart, per come è progettato, è probabilmente più veloce a compilarsi di Javascript.
-------------------------
Prendiamo il secondo link.
Questo è proprio misero. Tutta la sua argomentazione gira su "esiste già Javascript, non serve un altro linguaggio, se usi un altro lingaggio sei una merdaccia, non provare ad usare un altro linguaggio o m'incazzo".
Se la gente avesse ragionato così ora saremmo tutti felici utilizzatori di FORTRAN. Per fortuna qualcuno ha pensato "magari Fortran può essere migliorato"...
L'articolo "dimentica" che Dart può tranquillamente essere compilato in Javascript e che grazie a dart.js viene caricata l'una o l'altra versione (javascript o dart) del programma in base a ciò che supporta il browser... e poi di avventura nella frammentazione del mercato dei browser in particolare di quelli mobili... comparando Dart a VBSCRIPT. Peccato che VBSCRIPT era un linguaggio di Microsoft proprietario che richiedeva per forza l'uso di IE per essere utilizzato mentre Dart si adatta al browser fornendo la versione JS del programma o la versione Dart in base al supporto.
L'articolo non fa alcuna comparazione con Javascript a parte prendere in giro quelli a cui il modello ad oggetti di Javascript non piace. Poi comincia a sbattere i piedi e dire "a me piace Javascript, voglio Javascript e non mi piace il 'public static main void'". Infine nelle ultime righe se la prende con quelli che vogliono provare linguaggi alternativi a Javascript.
Conclusioni sul secondo link:
Vabbé... molto istruttivo... circa i capricci... ma non dice nulla di sensato circa tutto il resto a parte "Javascript ce l'hai su tutti i browser e Dart no" che, totlti tutti i capricci e lo sbattere i piedi a terra, è praticamente il suo unico punto.
**Modificato dall'autore il 15.01.2013 03:06**
http://jlouisramblings.blogspot.it/2011/10/musings... e
http://www.quirksmode.org/blog/archives/2011/10/da...
Partiamo dal primo.
Ammette di aver visto Dart solo dalle specifiche... e di averci dedicato sopra solo un paio d'ore. Tuttavia è abbastanza onesto da dire "queste sono le mie prime impressioni e potrei sbagliarmi".
Bene, per lo meno non è un perlaro.
La prima parte dell'articolo, diciamo una buona fetta, si limita a descrivere Dart in base a quanto ha letto sulle specifiche.
Fa un'analisi interessante sul linguaggio anche se alcune domande rimangono in sospeso perché, come ha detto, basa le sue impressioni su ciò che può vedere dalle specifiche ma non ha scaricato Dart per provarlo. Per esempio chiede "è possibile assegnare a un bool il valore null"? La risposta è si, ho provato a farlo e Dart non si è lamentato. In realtà non so perché sia possibile farlo, dato che non conosco Dart così bene, ma se bool è una classe di oggetti come posso assegnare poi quella variabile ad un'altra classe di oggetti (null)? Qui bisognerebbe sapere come si comporta internamente Dart e sarebbe interessante saperlo. Probabilmente nella documentazione ci sta scritto.
Ad ogni modo. La critica più grossa a Dart è che non introduce niente di non visto in altri linguaggi. Fa un paio di comparazioni con Javascript... e altre con Go, Java, Ocaml e Erlang... nessuno dei quali (Javascript a parte) gira su un browser.
Nella comparazione con Javascript dice solo che Dart supporta l'OO classico mentre Javascript la programmazione OO mediante prototipazione e dice anche che si vede che alcune scelte di Dart sono state fatte per velocizzare i tempi di caricamento e di compilazione al confronto di Javascript. Questa è praticamente tutto ciò che dice circa Dart vs Javascript.
Dice che alcune idee sono interessanti ma che esistono linguaggi più interessanti, come Go, che però non gira sui browser (d'altra parte Go è pensato per rimpiazzare C/C++, non Javascript).
In altre parole l'intero articolo è una mera (anche se interessante) descrizione di Dart con un paio di critiche finali circa il fatto che Dart bene o male non ha inventato nulla che non esista già in altri linguaggi che nulla hanno a che fare con i browser, d'altra parte perché avrebbe dovuto? Il suo scopo mica è inventare una nuova branca di linguaggi... semplicemente migliorare l'approccio usato da Javascript. Inoltre dice che gli isolate potevano essere implementati meglio e su questo non so pronunciarmi quindi facciamo finta che abbia ragione ma anche se fosse non credo possa essere usato come argomentazione per dire che Javascript è migliore di Dart o che non valga la pena impararsi Dart.
Conclusioni sul primo link:
Vabbé... mi chiedo che senso abbia comparare un linguaggio di scripting per browser con linguaggi che con i browser non c'azzeccano nulla... ovviamente la cosa non mi aiuta a capire perché dovrei rimanere con Javascript e lasciar perdere Dart. Insomma, se sono uno che deve decidere quale dei due mettermi a studiare questo articolo non mi dice nulla a parte che Dart, per come è progettato, è probabilmente più veloce a compilarsi di Javascript.
-------------------------
Prendiamo il secondo link.
Questo è proprio misero. Tutta la sua argomentazione gira su "esiste già Javascript, non serve un altro linguaggio, se usi un altro lingaggio sei una merdaccia, non provare ad usare un altro linguaggio o m'incazzo".
Se la gente avesse ragionato così ora saremmo tutti felici utilizzatori di FORTRAN. Per fortuna qualcuno ha pensato "magari Fortran può essere migliorato"...
L'articolo "dimentica" che Dart può tranquillamente essere compilato in Javascript e che grazie a dart.js viene caricata l'una o l'altra versione (javascript o dart) del programma in base a ciò che supporta il browser... e poi di avventura nella frammentazione del mercato dei browser in particolare di quelli mobili... comparando Dart a VBSCRIPT. Peccato che VBSCRIPT era un linguaggio di Microsoft proprietario che richiedeva per forza l'uso di IE per essere utilizzato mentre Dart si adatta al browser fornendo la versione JS del programma o la versione Dart in base al supporto.
L'articolo non fa alcuna comparazione con Javascript a parte prendere in giro quelli a cui il modello ad oggetti di Javascript non piace. Poi comincia a sbattere i piedi e dire "a me piace Javascript, voglio Javascript e non mi piace il 'public static main void'". Infine nelle ultime righe se la prende con quelli che vogliono provare linguaggi alternativi a Javascript.
Conclusioni sul secondo link:
Vabbé... molto istruttivo... circa i capricci... ma non dice nulla di sensato circa tutto il resto a parte "Javascript ce l'hai su tutti i browser e Dart no" che, totlti tutti i capricci e lo sbattere i piedi a terra, è praticamente il suo unico punto.
**Modificato dall'autore il 15.01.2013 03:06**
☺
Scritto da
il 2013-01-14 17:03:22.0 alle 2013-01-14 17:03:22.0
Trollate totali: 2001
Dunque, ho scaricato DartEditor per capire se avevo ragione nel considerare l'operatore di somma come un metodo del primo oggetto dell'operazione.
Ho scritto così per testare l'esempio del perlaro:
var x = "2" + 2;
Non mi aspettavo che Dart si lagnasse dato che davo per scontato che l'esempio del perlaro fosse corretto, ma Dart si è lamentato e lamentandosi mi ha fatto capire che 1) avevo ragione su quanto detto qui sopra e 2) Dart non supporta più il metodo "+" per le stringhe... il che conferma che giudicare un linguaggio in base alla specifica 0.01 dello stesso non è quasi mai una buona idea.
Vediamo che errore da.
var x = "2" + 2;
- "String" has no method named "operator +"
- '+' cannot be used for string concatentation, use string interpolation or a StringBuffer instead
Prendiamo il primo messaggio di errore: "String" has no method named "operator +"
Ciò significa che per come è fatto il linguaggio considera l'operatore come metodo dell'oggetto che lo precede ("2" in questo caso che è una stringa).
Quanto affermavo quindi sul perché potesse essere logico che "2" + 2 non generasse warning mentre lo facesse 2 + "2" è corretto. Le considerazioni del perlaro sono quindi dovute alla sua ignoranza (non è un insulto dato che nemmeno io lo sapevo, l'ho tirato ad indovinare) del funzionamento interno di Dart.
Infatti a quanto pare in Dart il "+" è considerato un metodo dell'oggetto che lo precede. Perciò l'operazione si converte in "2".+(2) nel primo caso e 2.+("2") nel secondo caso. Si tratta quindi di _metodi diversi_ su oggetti diversi e quindi, naturalmente, possono avere messaggi di errore diversi (o non averne).
Andando a scavare nella documentazione di Dart infatti dice:
"Dart shares the same operators and precedences that you're familiar with from C, Java, etc. They will do what you expect. Under the hood, though, they are a little special. In Dart, an expression using an operator like 1 + 2 is really just syntactic sugar for calling a method. The previous example looks more like 1.+(2) to the language."
Il fatto invece che il metodo "+" non esista più invece mi ha incuriosito. Perché mai rimuovere il metodo "+" dalle stringhe?
Risulta che la cosa sia stata scelta dopo aver analizzato i problemi che questo provoca anche in altri linguaggi (fra cui java). Si è scelto quindi di supportare la concatenazione di stringhe in modo meno ambiguo.
Le ragioni sono riportate qui con tanto di esempi perciò non sto a dilungarmi: http://news.dartlang.org/2012/06/vm-to-remove-supp...
Perciò non solo le considerazioni del perlaro sono dovute al non sapere quale sia il razionale che ha portato a quel warning (cosa che avrebbe potuto scoprire spendendo 2 minuti della sua vita a fare le dovute verifiche) ma sono anche obsolete perché basate su una specifica (la versione 0.01 del linguaggio) che non rispecchia più l'attuale stato del linguaggio.
Ho scritto così per testare l'esempio del perlaro:
var x = "2" + 2;
Non mi aspettavo che Dart si lagnasse dato che davo per scontato che l'esempio del perlaro fosse corretto, ma Dart si è lamentato e lamentandosi mi ha fatto capire che 1) avevo ragione su quanto detto qui sopra e 2) Dart non supporta più il metodo "+" per le stringhe... il che conferma che giudicare un linguaggio in base alla specifica 0.01 dello stesso non è quasi mai una buona idea.
Vediamo che errore da.
var x = "2" + 2;
- "String" has no method named "operator +"
- '+' cannot be used for string concatentation, use string interpolation or a StringBuffer instead
Prendiamo il primo messaggio di errore: "String" has no method named "operator +"
Ciò significa che per come è fatto il linguaggio considera l'operatore come metodo dell'oggetto che lo precede ("2" in questo caso che è una stringa).
Quanto affermavo quindi sul perché potesse essere logico che "2" + 2 non generasse warning mentre lo facesse 2 + "2" è corretto. Le considerazioni del perlaro sono quindi dovute alla sua ignoranza (non è un insulto dato che nemmeno io lo sapevo, l'ho tirato ad indovinare) del funzionamento interno di Dart.
Infatti a quanto pare in Dart il "+" è considerato un metodo dell'oggetto che lo precede. Perciò l'operazione si converte in "2".+(2) nel primo caso e 2.+("2") nel secondo caso. Si tratta quindi di _metodi diversi_ su oggetti diversi e quindi, naturalmente, possono avere messaggi di errore diversi (o non averne).
Andando a scavare nella documentazione di Dart infatti dice:
"Dart shares the same operators and precedences that you're familiar with from C, Java, etc. They will do what you expect. Under the hood, though, they are a little special. In Dart, an expression using an operator like 1 + 2 is really just syntactic sugar for calling a method. The previous example looks more like 1.+(2) to the language."
Il fatto invece che il metodo "+" non esista più invece mi ha incuriosito. Perché mai rimuovere il metodo "+" dalle stringhe?
Risulta che la cosa sia stata scelta dopo aver analizzato i problemi che questo provoca anche in altri linguaggi (fra cui java). Si è scelto quindi di supportare la concatenazione di stringhe in modo meno ambiguo.
Le ragioni sono riportate qui con tanto di esempi perciò non sto a dilungarmi: http://news.dartlang.org/2012/06/vm-to-remove-supp...
Perciò non solo le considerazioni del perlaro sono dovute al non sapere quale sia il razionale che ha portato a quel warning (cosa che avrebbe potuto scoprire spendendo 2 minuti della sua vita a fare le dovute verifiche) ma sono anche obsolete perché basate su una specifica (la versione 0.01 del linguaggio) che non rispecchia più l'attuale stato del linguaggio.
☺
Scritto da
il 2012-11-12 18:33:32.0 alle 2012-11-12 18:33:32.0
Trollate totali: 2001
Pare essere diventato un oggetto interessante.
In particolare:
- il così detto tree-shaking, ovvero quella fase della compilazione (in javascript per ora, in futuro pare ci saranno tool per DART nativo che permetteranno di fare il tree-shaking dello stesso codice DART) in cui tutte le parti di libreria/funzioni/variabili/ecc non usate vengono semplicemente lasciate fuori dallo script finale (che se non ho capito male diventa un unico file indipendentemente dal numero di librerie richiamate). Questo ovviamente rende più snello lo script finale e non sovraccarica la VM del browser con codice inutile.
- la possibilità di "compilare" il sorgente DART in binario (i così detti snapshot, non si tratta di vera compilazione ma di uno snapshot appunto dello stato della VM che viene poi serializzato in binario) che la VM del browser è in grado di caricare minimizzando i tempi di attesa (non è più necessario interpretare il sorgente). Gli snapshot sono comunque hardware-agnostici quindi funzionano a prescindere dal browser, dalla CPU e dal SO.
- la maggiore chiarezza e migliore struttura del linguaggio rispetto a javascript che dovrebbe aiutare parecchio non solo a capire codice scritto da altri (soprattutto su progetti condivisi fra varie persone) ma anche impedire che si facciano errori difficili da vedere (come usare variabili inesistenti, strani cast automatici, ecc).
- la possibilità di usare lato server lo stesso linguaggio che si usa per gli script lato client (per ora ancora in fase prematura forse ma già esistono moduli per Apache per supportare DART come linguaggio nativo per le applicazioni WEB
https://github.com/sam-mccall/mod_dart ). Sarebbe bello infatti poter usare un linguaggio unico e meglio pensato/progettato di, per esempio, PHP ma non così verboso e rompipalle come Java.
Sarebbe anche bello avere un moduletto apache per esempio che mi permetta di caricare il file DART per gli script lato client e che si occupi da solo di fornire la versione compilata in javascript ai browser che ancora non supportano DART mentre fornire DART nativo (o meglio ancora lo snapshot binario) ai browser che invece supportano DART. (Mi chiedo se non sia il caso di suggerirlo al team di sviluppo o se ci abbiano già pensato ma siano arrivati alla conclusione che non è fattibile). Sarebbe bello infatti poter caricare il file DART e lasciare che il server WEB si arrangi, senza ulteriori complicazioni lato sviluppatore.
Voi che ne pensate?
P.S.: Credo che posterò sta cosa anche sul PIForum anche se dubito che qualcuno lì mi risponderà.
In particolare:
- il così detto tree-shaking, ovvero quella fase della compilazione (in javascript per ora, in futuro pare ci saranno tool per DART nativo che permetteranno di fare il tree-shaking dello stesso codice DART) in cui tutte le parti di libreria/funzioni/variabili/ecc non usate vengono semplicemente lasciate fuori dallo script finale (che se non ho capito male diventa un unico file indipendentemente dal numero di librerie richiamate). Questo ovviamente rende più snello lo script finale e non sovraccarica la VM del browser con codice inutile.
- la possibilità di "compilare" il sorgente DART in binario (i così detti snapshot, non si tratta di vera compilazione ma di uno snapshot appunto dello stato della VM che viene poi serializzato in binario) che la VM del browser è in grado di caricare minimizzando i tempi di attesa (non è più necessario interpretare il sorgente). Gli snapshot sono comunque hardware-agnostici quindi funzionano a prescindere dal browser, dalla CPU e dal SO.
- la maggiore chiarezza e migliore struttura del linguaggio rispetto a javascript che dovrebbe aiutare parecchio non solo a capire codice scritto da altri (soprattutto su progetti condivisi fra varie persone) ma anche impedire che si facciano errori difficili da vedere (come usare variabili inesistenti, strani cast automatici, ecc).
- la possibilità di usare lato server lo stesso linguaggio che si usa per gli script lato client (per ora ancora in fase prematura forse ma già esistono moduli per Apache per supportare DART come linguaggio nativo per le applicazioni WEB
). Sarebbe bello infatti poter usare un linguaggio unico e meglio pensato/progettato di, per esempio, PHP ma non così verboso e rompipalle come Java.Sarebbe anche bello avere un moduletto apache per esempio che mi permetta di caricare il file DART per gli script lato client e che si occupi da solo di fornire la versione compilata in javascript ai browser che ancora non supportano DART mentre fornire DART nativo (o meglio ancora lo snapshot binario) ai browser che invece supportano DART. (Mi chiedo se non sia il caso di suggerirlo al team di sviluppo o se ci abbiano già pensato ma siano arrivati alla conclusione che non è fattibile). Sarebbe bello infatti poter caricare il file DART e lasciare che il server WEB si arrangi, senza ulteriori complicazioni lato sviluppatore.
Voi che ne pensate?
P.S.: Credo che posterò sta cosa anche sul PIForum anche se dubito che qualcuno lì mi risponderà.