[Python] Alcune cose sono interessanti, altre non so se hanno senso

[enrico franchi]

2015-02-27 10:17 GMT+00:00 Carlos Catucci <carlos.catucci a gmail.com>:

>
> 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.
>

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.

Fosse per me, tutti gli assegnamenti dovrebbero essere const "salvo
istruzione contraria".

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.



> Destructuring non e' male forse, ma mi sembra un poco contorto, in fondo
> e' un array no?
>

Destructuring mi sembra abbastanza analogo al pattern matching, che e' una
cosa *comodissima* in vaste classi di linguaggi (Scala, Haskell, ML).
Ovviamente la versione di Javascript e' pesantemente unsafe e non sono
particolarmente convinto che semplifichi la vita.

Il giochetto poi dei valori "skippati" fatto con le virgole mi sembra
veramente un'idea che poteva venire in mente a Lerdorf.

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.
>

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.


> Arrow function mi fa tanto PHP, e non ho capito come funziona. Il tipo fa
> prima un esempio dove scrive
>
> employees.forEach(function(emp) {
>     totalAge += emp.age;
> });
>
> E va bene, ma qui emp la definisce lui come parametro passato alla
> funzione, poi scrive
>
> employees.forEach(emp => {
>     totalAge += emp.age;
> });
>
> che sarebbe la lambda, ma scritto cosi' e' poco chiaro. Questioone di
> leggibilita', tutto qui.
>

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.
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.

Cioe'... capirei un esempio del tipo

employees.sum(emp => emp.age) o qualcosa di simile...

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...

Vabbe'...


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.
>

Ma si... alla fine e' quasi tutto sensato. Diciamo che cosi' Javascript non
sembra essersi perso 20 anni di evoluzione dei linguaggi.

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).

-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150227/801e5941/attachment-0001.html>