2009/11/11 Daniele Varrazzo <p...@develer.com>: > Cosa c'è in queste soluzioni che non sia già "tutto quello che un singolo > processo può fare, solo un po' più veloce di quanto l'implementazione > cPython non faccia)? A occhio e croce mi sembra "processo singolo, > multi-thread forse, un misto di un linguaggio di sviluppo rapido con uno di > livello inferiore e prestazioni superiori". >
lua + C == stabilità del linguaggio lua non cambia nel tempo, e neppure C (beh, calma, tutto cambia) Ma ovviamente ti curi platform + threading, ovvero fine tuning della tua application, devi essere disciplinato per grossi progetti e non è vero OO (beh lua è un po' quel che vuoi) Insomma : STABILITA' del linguaggio anche rispetto ai cambiamenti tecnologici CPython -- ok vai con l'acqua santa -- cambia troppo per i miei gusti: "CPython ? QUALE CPython ? " Guardate Plone: Plone4.0 avrà Python 2.6 ma il 3.3 ha il python 2.4 e la mia Ubuntu LTS ha il 2.5 Ora voi mi direte che non cambia nulla da 2.4 a 2.5 a 2.6 -- ed allora perché cambia numero ? Insomma vi capisco... ma non mi piace, mi fa acidità e quindi mi adeguo. Python 3,poi..., > Insomma, questo si fa anche con Python+C (magari Pyrex|Cython, entrambi > fantastici, ma sono solo un aiuto), ma non risolve il problema di fondo: > "il pasto gratis è finito" e Moore, che ci ha concesso decine di anni di > generoso raddoppio di prestazioni ogni 18 mesi, non aiuta più a meno di non > farsi trovare pronti ad andare oltre il singolo core. Groovy + Java Potrebbe essere come CPython + C++ ma meglio. OO, scripting , threading, un buona VM e quindi ti solleva dal problema della fame . Si ,anche Jython -- ma meglio non mischiare le cose Forse, comunque. > Chi mi conosce sa che non ho mai negato che Erlang sia un linguaggio > sintatticamente bruttino e con una stdlib favolosamente incoerente: > penso > che nessun linguaggio come Erlang abbia bisogno di un "progetto 3K", altro > che Python nel quale si considera brutto avere sia dict.items() che > dict.iteritems(). Ma questo non fa che confermarmi che il problema non è > nel linguaggio: Erlang è diverso e buono nel suo modello runtime, e il > motivo per cui sceglierlo non è "il mio linguaggio non è più di moda", ma > "il mio runtime non mi permette di scalare". Erlang è la prima alternativa > abbordabile a una tecnologia che permetta di andare oltre i limiti del > singolo processo Unix. Il tuo approccio mi piace. Aggiungo Smalltalk x completezza, e per il momento, visto che sto già meglio, EOT -- luigi _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
