[Python] "Go or Unladen Swallow? " Cosa ne pensate ?

[luigi scarso]

2009/11/11 Daniele Varrazzo <piro a 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