Newsgroup: it.comp.programmare
Titolo: Python: motivazioni tecniche per la non adozione

Quello che segue è un elenco tutt'altro che esaustivo delle motivazioni 
*tecniche* per cui il Python (ed il suo interprete) è un linguaggio 
inadatto allo sviluppo di applicazioni professionali.
1) Errori di sintassi a run-time.
La maggior parte degli errori che si verificano nella scrittura dei 
programmi sono di tipo tipografico, che i linguaggi compilati intercettano 
a livello di compilazione. Questo non accade con Python, dove è necessario 
attendere il momento dell'esecuzione -- e che generano eccezioni del tipo 
NameError o AttributeError, di difficile intercettazione se si usano le 
eccezioni, in quanto interferiscono con la normale logica del programma.
2) Il linguaggio è inefficiente.
Per la sua natura altamente dinamica, il linguaggio è interepretato e 
difficilmente può essere tradotto in codice avente costo computazionale 
accettabile. In particolar modo, è chiaro che il codice sviluppato non sarà 
mai veloce come l'equivalente in C++, ma si hanno anche costi impliciti, 
come il costo di cleanup dell'heap da parte del Garbage Collection, oppure 
il costo di deduzione del tipo di un oggetto a partire da un suo 
riferimento.
3) Sintassi complicata.
I costrutti adottati dal Python sono controintuitivi, e portano a sviluppare 
programmi di difficile comprensibilità (a meno di essere dei guru del 
Python, ovviamente). Al contrario, altri linguaggi sono più chiari e 
concisi.
4) Scoping tramite indentazione.
Una scelta risibile è quella di non utilizzare dei separatori facenti parte 
della sintassi per indicare i limiti di cicli o lo scoping delle variabili, 
bensì di usare l'indentazione. Questo porta all'impossbilità di utilizzare 
questo linguaggio per la trascrizione di algoritmi anche banali tramite i 
comuni mezzi di comunicazione, in quanto un eventuale maneggiamento da 
parte di processi automatici di indentazione porta ad un codice non 
funzionante -- e di difficile ripristino senza avere accesso al testo 
originale.
5) Mancanza di dichiarazioni.
Nei linguaggi con una separazione netta tra implementazione e interfaccia, i 
programmatori hanno la possibilità di prendere visione di ciò che una 
funzione/metodo ha bisogno, senza ispezionare il codice e senza utilizzare 
documentazione ulteriore (e, forse, non aggiornata). Basta ispezionare le 
dichiarazioni per conoscere parametri necessari e valore ritornato. Ciò non 
è possibile con Python.
6) Garbage collector inefficiente.
L'implementazione standard del Python ha un GC inefficiente, in tempo e 
spazio, che impedisce una programmazione con tolleranze sulle latenze 
accettabili.
7) Multithreading inefficiente.
L'implementazione standard del Python ha una gestione dei threading 
inefficiente. Questo lo rende inadatto ad applicazioni server-side. Non 
potendo escluderla, è di fatto un grosso limite per il suo utilizzo.
Ovviamente, sono aperto a considerazioni *tecniche* sulla questione.
Astenersi *pythoniani* perditempo.
Ciao!
---
*************** | Have you ever retired a human by mystake?
*** Azathot *** |
*************** | To contact me, ask me gently. Thanks.

 inadatto allo sviluppo di applicazioni professionali.
Avevo promesso di non risponderti più ma non ci riesco. Alcune delle tue
motivazioni non sono tecniche (sintassi complicata? Magari per te che
consideri solo il C++ un vero linguaggio...).
A tutte le altre obiezioni ti hanno già risposto con motivazioni *tecniche*
altri più bravi di me.
L'unica cosa nuova è quella sui thread, da quel che so il supporyto ai
thread può essere eliminato. Di più non so quindi non provo neanche a
rispondere.
f/up su poster
-- 
Marco Barisione

 thread può essere eliminato. 
Se c'è, si usa. Se fa schifo, si passa ad altro.
-- 


 Astenersi *pythoniani* perditempo.
Volentieri.
- --
"Twenty billion junk e-mail messages sent per day may potentially take
20 billion seconds to delete. A human life is a mere two billion seconds
long. In effect, spammers kill ten people each day."  Anders Andersson
Nicola Larosa - nico...@m-tekNico.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/NjfdXv0hgDImBm4RAuncAJ9Hok8hVlwWkzlIyvP+AqcmxB/DNwCdFmqJ
i31o4aN88VGl14hWryKu/kg=
=Sdk6
-----END PGP SIGNATURE-----

 rispondere.
Per questo esiste stackless python. Ho avuto modo di parlare con Christian
Tismer. Con la sua implementazione di python si puo` switchare tra thread
con una velocita` incredibile in quanto non viene ricreato lo stack ma
ogni thread mantiene il riferimento ad un unico stack sul quale lavora. In
pratica ogni stack ha bisogno di 100bytes aggiuntivi per fare il lavoro.
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Debian Sid Proud User

 pratica ogni stack ha bisogno di 100bytes aggiuntivi per fare il lavoro.
Mi immagino che divertimento se un thread impazzisce e inizia a 
sovrascrivere lo stack degli altri... :^)
-- 


 pratica ogni stack ha bisogno di 100bytes aggiuntivi per fare il lavoro.
/s/stack/thread
PS: ovviamente il resto delle fregnacce di cui ci ha fatto dono il sempre
informato azathot non merita il benche` minimo commento... Tra l'altro ho
scoperto in questi giorni che emacs ha una funzione che reindenta il
codice in modo automatico, mai usata ovviamente.


 codice in modo automatico, mai usata ovviamente.
Ma ovviamente non può funzionare correttamente se il codice è poco poco più 
complesso di quelli ai quali sei abituato.
-- 


 sovrascrivere lo stack degli altri... :^)
Eh gia` e poi ci troveremo come le star a bere del wishkey al roxy bar.
Ma tu pretendi anche delle risposte serie magari...


 Ma tu pretendi anche delle risposte serie magari...
... da te? Non ho di queste pretese... :^)


Azathot wrote:
 >
 > [ tutte stronzate ]
 >
IDIOTA.

 IDIOTA.
Gentilmente, ricambio.
-- 


 a livello di compilazione.
se il tuo post parte con questa frase, come puoi pretendere che i tuoi
lettori ti credano?
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra

 lettori ti credano?
Proseguendo nella lettura. Tu che ne dici?
-- 


 sovrascrivere lo stack degli altri... :^)
primo: può accadere in qualsiasi ambiente. Gli stack stanno tutti nello 
stesso spazio di indirizzamento anche se gestiti dal sistema operativo. 
Secondo: Python è managed, quindi non può succedere
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.2. C, C++ and ASM developers
                               and beta testers are welcome!

 Secondo: Python è managed, quindi non può succedere
Seeeee...


 Astenersi *pythoniani* perditempo.
non sono un pythonista perditempo percio' posso dire la mia :))
Tutto questo che hai scritto pur essendo vero in molte sue parti non sono
motivazioni valide epr la non adozione.Python č considerato da tanti molto
valido anche da persone piů competenti di me e di te :)).
Secondo me dovresti ristringere il campo per la *non adozione* questo tuo
generalizzare č sbagliato,anche se capisco che su questo newsgroup non sono
per niente obiettivi e qualcuno anche maleducato(ad esempio Stanislao che di
certo non č un esempio di netiquette da tenere su un newsgroup ,vedi sopra)
ciao..

 Secondo me dovresti ristringere il campo per la *non adozione* 
Il problema che ponevo io era in ambito di sviluppo con modalità 
"industriali". In tali modalità, la scelta dello strumento non si pone in 
funzione dell'ambito, bensì dei vantaggi/svantaggi complessivi. L'unico 
vantaggio che vedo con il Python è l'iniziale curva di apprendimento. Tutto 
il resto è svantaggioso. È un po' come decidere se comprare un autoveicolo 
solo in funzione di quanto è facile guidarlo, trascurando altri dettagli 
decisamente più importanti. ;-)
Per il resto, massima disponibilità al dialogo, purché l'interlocutore 
manifesti un minimo di intelligenza e non tratti l'interlocutore come uno 
"sprovveduto" (qualsiasi riferimento ad Alex Martelli è del tutto voluto).
Ciao.
-- 


 "sprovveduto" (qualsiasi riferimento ad Alex Martelli è del tutto voluto).
Che tradotto dall'Azathotese all'Italiano, significa grossomodo:
"Per il resto, massima disponibilità al dialogo, purchè l'interlocutore
lodi entusiasticamente il c/c++ e spali merda sul python e gli altri
linguaggi senza conoscerne neppure la terza parte"
Bye
Raffaele
-- 
Raffaele Castagno
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Che tradotto dall'Azathotese all'Italiano, significa grossomodo:
Che non si scrivano sorgenti da pessimo programmatore C++ e da "esperto" 
programmatore Python per dimostrare che uno ce l'ha più lungo dell'altro. 
:^)
-- 
P.S. Quando poi non è neanche vero. :)


 decisamente più importanti. ;-)
A parte che il tuo messaggio era solo provocatorio e non diretto a nessun
tipo di utente particolare,non è vero che python non dia la necessaria
affidabilità e velocità anche in un contesto industriale,ma dipende appunto
"in che contesto".
Ma smettiamola di dire è meglio quello o l'altro,generalizzare è sempre
sbagliato..
ciao :)

 sbagliato..
Ma stai generalizzando!!! :))


 :^)
Aveva espressamente detto che quel pezzo di c++ poteva essere scritto
meglio, ed ha invitato a scriverne uno migliore. Ma tu hai criticato,
senza dimostrare nulla. uno 0 bucato.


 senza dimostrare nulla. 
Vedi sopra.
Cmq, una cosa l'ho dimostrata: che le sue dimostrazioni non valgon nulla.
-- 


inadatto allo sviluppo di applicazioni professionali.
questo è generalizzare in quanto non puoi dire che non è un linguaggio
valido in applicazioni professionali.Sappiamo entrambi che ne parlano bene
fior di professionisti.
Se proprio ne vuoi parlare male fallo con un contesto non così generico in
quanto assurdo.
ciao :)

 io ?
"generalizzare è sempre sbagliato" è una generalizzazione. :)
Ciao.


> "generalizzare è sempre sbagliato" è una generalizzazione. :)
assolutamente no,son stato molto mirato nel dire di "non generalizzare" in
quanto diretto a chi generalizza le situazioni:P
ihihihi
ciao :)

Antonio wrote:

La tua affermazione non lascia adito a dubbi: è un assioma. :P
