<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-02-27 10:17 GMT+00:00 Carlos Catucci <span dir="ltr"><<a href="mailto:carlos.catucci@gmail.com" target="_blank">carlos.catucci@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>La const in se fa comodo ma si vive anche senza (per convenzione io uso una var maiuscola e so che e' una costante per cui non la cambio mai, inoltre uso i namespaces, quindi mi basta uno chiamato CONST seguito da .nomecostante e evito il problema.<br></div></blockquote><div><br></div><div>A me const piace. Personalmente il fatto che in Python tutti i modi per rendere qualcosa immutabile (almeno rispetto a cambiamenti accidentali) siano lunghi dispiace. Di fatto l'unico modo di avere qualcosa di *veramente* immutabile in pure Python e' fare information hiding con delle chiusure lessicali (sempre a meno che qualcuno non si metta a smacchinare con i frame a mano... ma bisogna un po' cercarsela, ecco) e l'altro modo e' usare delle property... Ovviamente dal punto di vista del compilatore non ci sono garanzie a sufficienza per fare le ottimizzazioni che si potrebbero fare altrimenti e dal punto di vista dell'utente va bene (ed e' comodo) solo se appunto si sta lavorando con degli oggetti.</div><div><br></div><div>Fosse per me, tutti gli assegnamenti dovrebbero essere const "salvo istruzione contraria".</div><div><br></div><div>Riguardo al const di Javascript non mi e' chiaro -- dovrei leggere la specifica -- se si riferisce al binding o anche all'oggetto... ma per come funziona Javascript credo la prima.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Destructuring non e' male forse, ma mi sembra un poco contorto, in fondo e' un array no?<br></div></blockquote><div><br></div><div>Destructuring mi sembra abbastanza analogo al pattern matching, che e' una cosa *comodissima* in vaste classi di linguaggi (Scala, Haskell, ML).</div><div>Ovviamente la versione di Javascript e' pesantemente unsafe e non sono particolarmente convinto che semplifichi la vita.</div><div><br></div><div>Il giochetto poi dei valori "skippati" fatto con le virgole mi sembra veramente un'idea che poteva venire in mente a Lerdorf.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Spread e' un passare una lista come parametro ad una funzione che si aspetta una serie di parametri. Avrei preferito una evolusione del tipo *args,**kwargs alla Python.<br></div></blockquote><div><br></div><div>Sintassi. Sono con te sul fatto che quella di Python sia piu' bella, ma alla fine ... viene usato con un significato simile in Java, C++, C e Go (e suppongo anche altri) e penso che abbia senso per JS andare avanti cosi', visto che tanto la cagata di prendere un linguaggio bellino e rovinarlo con features e sintassi che non hanno nulla a che vedere venne fatta fin dall'inizio.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Arrow function mi fa tanto PHP, e non ho capito come funziona. Il tipo fa prima un esempio dove scrive<br><br>employees.forEach(function(emp) {<br>    totalAge += emp.age;<br>});<br><br>E va bene, ma qui emp la definisce lui come parametro passato alla funzione, poi scrive<br><br>employees.forEach(emp => {<br>    totalAge += emp.age;<br>});<br><br>che sarebbe la lambda, ma scritto cosi' e' poco chiaro. Questioone di leggibilita', tutto qui.<br></div></blockquote><div><br></div><div>Non vedo perche' PHP. Ok, forse -> era piu' chiaro (come fanno in C++, Java e Scala; e tanti altri). Non e' che => invece di -> mi cambi la vita.</div><div>Poi il fatto e' che mi fa molto dispiacere come le persone non comprendano la bellezza del paradigma funzionale, ne prendano dei pezzi e proseguono a scrivere codice imperativo, con tutte le eventuali complicazioni di mappare concetti funzionali nel mondo imperativo e tutti gli svantaggi logici ed effettivi del mondo imperativo.</div><div><br></div><div>Cioe'... capirei un esempio del tipo</div><div><br></div><div>employees.sum(emp => emp.age) o qualcosa di simile...</div><div><br></div><div>Ma prendere una variabile e mutarla e' una cosa cosi' brutta... ti spacca un'eventuale auto-parallelizzazione (che vabbe', in Javascript non si potrebbe fare visto la semantica dei numeri). Ti incasina un sacco di cose quando vuoi usare veramente higher order functions... ma voglio dire... </div><div><br></div><div>Vabbe'... </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Non ho ancora visto bene il resto, gli iterators forse sono una cosa buona, idem per i generators, ma devo ancora darci un'occhio bene.</div></blockquote><div><br></div><div>Ma si... alla fine e' quasi tutto sensato. Diciamo che cosi' Javascript non sembra essersi perso 20 anni di evoluzione dei linguaggi.</div><div><br></div><div>La parte che mi fa paura sono le classi. Cioe'... Gia' per fare OOP in Javascript c'erano tipo 3-4 modi diversi, ci mancava proprio il 5o. E poi voglio vedere come mappano il modello di OO tradizionale con quello a prototipi in modo che tutto funzioni senza sorprese (io ho idea che ci sara' un altro manualetto di 200 pagine con tutti i gotcha su come le due cose interagiscono).</div><div> </div></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>