[Python] Che ne pensate?

[enrico franchi]

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

> http://www.impredicative.com/ur/
>
> Pareri graditi
>

Complicato Carlos... non ci ho mai lavorato. Potrei guardarmi il tutorial e
poi dare un parere... ma il punto fondamentale per me e' che quello e' un
giocattolo accademico, per ora.

Spiego meglio... allora, guardo i *due* capitoli sul linguaggio. A prima
botta sembra un affare parecchio ispirato da ML e Haskell, come l'autore
promette. Credo che visto senza ulteriori nozioni lo avrei preso per un
qualche dialetto ML.

Poi leggo:

"""
Then there's parametric polymorphism. Unlike in ML and Haskell, polymorphic
functions in Ur/Web often require full type annotations. That is because
more advanced features (which we'll get to in the next chapter) make Ur
type inference undecidable.
"""

Uhm... aspetta. Una delle cose per cui ML e Haskell mi piacciono e' che
sebbene siano tipizzati staticamente in generale il compilatore capisce
abbastanza bene quello di cui si parla e i tipi non mi vengono fra le palle
ma mi sono di aiuto. Sembra che questa caratteristica carina di ML sia
stata soppiantata in favore di qualcos'altro... che devo capire cosa sia.

Piu' sotto cerco di capire che cosa cavolo fa di nuovo. Apparentemente
sembra volere introdurre qualcosa che mi ricorda il MOP, ma in salsa ML.
Poi fa vedere cose che ha preso da ML e da Haskell, ma sinceramente non ci
ho capito molto. Soprattutto non mi e' chiaro quale sia il punto di forza.

Poi magari e' veramente fichissimo... per ora entra nella categoria:
documentazione povera.

Poi leggo:
"""

The Ur/Web compiler also produces very efficient object code that does not
use garbage collection. These compiled programs will often be even more
efficient than what most programmers would bother to write in C. For
example, the standalone web server generated for the demo uses less RAM
than the bash shell. The compiler also generates JavaScript versions of
client-side code, with no need to write those parts of applications in a
different language.
"""

Ma siamo sicuri di vivere nello stesso pianeta? Cioe', ok, non usi garbage
collection. Cosa che per quanto mi riguarda non e' esattamente un vantaggio
ne uno svantaggio. Cioe', se riesce a staticamente risolvere allocazioni e
deallocazioni, sicuramente meglio. Ma non e' che il mio problema la fuori
sia avere o non avere garbage collection. Cioe', a volte voglio non
averla... ma se sto scrivendo un applicazione web i miei problemi sono
altri.

Anche il fatto che parli di "efficienza del codice" mi fa pensare che non
gli sia in eccesso chiaro il punto. Quando ho problemi di performance su
un'applicazione web di solito i colpevoli sono il database, dipendenze da
servizi lenti e/o con API demenziali e cose stupide fatte nel codice. Il
fatto di avere un server web pre-compilato mi interessa il giusto (anzi,
sinceramente faccio a meno grazie... preferisco scegliermelo io secondo le
esigenze). Ma diciamo cosi', in generale il mio problema e' scalare
orizzontalmente; scalare verticalmente mi interessa raramente.

Il fatto poi che il server prenda 4 MB o 8 MB... come dire. Bravo. Pero' la
macchina piu' piccola su cui metto le mani ha tipo 12 GB di RAM. Il mio
problema e' quanta RAM succhia l'applicazione... il webserver di per se e'
poco influente. Sempre a sboccio... l'ultima volta che ho misurato Apache i
workers stavano sui 4/5 MB l'uno e ne avevo in giro un po'. E i problemi di
memoria che avevo erano altri. Tipo Redis che ogni tanto ipertrofizzava
grazie a celery (grazie! il default dei risultati indelebili e' li apposta
per quelli che dovevano deployare l'altro ieri e non hanno avuto il tempo
di leggersi tutto il maledetto manuale). Oh, ma meglio ancora i worker
django che ingrassavano perche' dovevano macinare molti dati... che
ovviamente si risolve offloadando a celery. Qualche mese fa ho
personalmente terminato con un worker che era ingrassato verso i 3 GB. Mi
e' quasi spiaciuto.

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