<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-02-11 10:58 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><a href="http://www.impredicative.com/ur/" target="_blank">http://www.impredicative.com/ur/</a><br><br></div>Pareri graditi</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Poi leggo:</div><div><br></div><div>"""</div><div class="" style="font-family:Arial;border-style:solid;padding:5px;font-size:larger;color:rgb(0,0,0);background-color:rgb(204,255,204)">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.</div><div>"""</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Poi magari e' veramente fichissimo... per ora entra nella categoria: documentazione povera. </div></div><br>Poi leggo:</div><div class="gmail_extra">"""</div><div class="gmail_extra"><p style="color:rgb(0,0,0);font-family:sans-serif;font-size:medium">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 <tt>bash</tt> shell. The compiler also generates JavaScript versions of client-side code, with no need to write those parts of applications in a different language.</p><div>"""</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><div class="gmail_extra"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>