2011/12/28 Gian Mario Tagliaretti <span dir="ltr"><<a href="mailto:g.tagliaretti@gmail.com" target="_blank">g.tagliaretti@gmail.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><br>
</div>Carlos ma che due balle con sta storia che Python è meglio a<br>
prescindere e tutto il resto è merda, </blockquote><div><br></div><div>Questo effettivamente e' poco motivato.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



Valutare la complessità di un software certo è difficile, per progetti<br>
"complessi" Python diventa ingestibile, la IDE qualunque sia ad un<br>
certo punto non riesce più a venirti incontro per le caratteristiche<br>
del liguaggio, per altri linguaggi su cui costantemente si sputa sopra<br>
(vedi .NET) la IDE in vece ti da una grossa mano ed il progetto<br>
diventa più gestibile. Sono state fatte analisi sulla velocità dello<br>
sviluppo vs la complessità di mantenimento e Python sopra una certa<br>
complessità non è più così "comodo" (termine orribile) come per<br>
progetti più piccoli.<br></blockquote><div><br></div><div>1. questi studi sarebbero da vedere e da valutare, secondo me. anche senza volerlo si possono prendere conclusioni parecchio sbagliate. personalmente credo che uno studio di questo tipo sia essenzialmente privo di senso. il problema e' che puoi valutare una tecnologia solo sulla base di un prodotto che e' pero' fatto da uomini: quindi devi trovare il modo di rendere indipendente lo studio da chi lo ha fatto. tenendo conto che e' noto che le differenze individuali fra due sviluppatori possono essere immense, che possono essere immense le differenze dello stesso sviluppatore con tecnologie diverse, che possono essere diverse le interazioni di gruppo, etc etc etc.</div>


<div><br></div><div>Ecco, diciamo che vedo molto complesso fare uno studio di questo tipo in modo scientifico e le cui conclusioni possano essere facilmente condivise perche' considerabili oggettive.</div><div><br></div>


<div>2. Io ho sempre considerato le IDE come una cosa che piu' che altro tappa i buchi di linguaggi con caratteristiche abbastanza peculiari. Linguaggi molto verbosi, con informazione ripetuta (pensa a Java e al fatto che un file deve riportare all'interno del file il path e che deve anche essere esattamente in quella posizione relativa.. e' il tipo di cose che un umano deve fare "due volte" per fare quasi la stessa cosa).</div>


<div><br></div><div>Oppure trovo gli IDE molto sensati anche quando lavorano bene con il framework in questione (e.g., Python + Django e' molto comodo con un IDE). </div><div><br></div><div>In particolare, non sono minimamente convinto che linguaggio scemotto + IDE venga piu' produttivo di "linguaggio fatto bene" + IDE. Il punto e' che molte delle cose che permettono ad un IDE di fare cose "avanzate" (sono quelle che fanno risparmiare tempo) sono le stesse che fanno perdere tempo ai programmatori umani, quindi bisognerebbe vedere il bilancio complessivo.</div>


<div><br></div><div>Come sai non conosco .Net. Conosco abbastanza bene Java, pero'. E posso dirti che molte cose *banali* in Python per *non* scrivere codice, in Java richiedono cura e attenzione. Per me il modo migliore di tagliare i costi di manutenzione e' *non* scrivere il codice. Perche' il codice non scritto non va mantenuto.</div>


<div><br></div><div>Poi come sempre bisogna considerare la realta' del team con cui si lavora. Se alla fine bisogna scrivere Python "quasi come fosse Java" allora gli unici vantaggi sono davvero a basso livello, perche' Python e' un po' piu' comodo nello smazzare i dati (stringhe, dizionari, etc). Tutto quello che gli sta sopra sara' piu' o meno Java cammuffato da Python e allora tanto vale Java, IDE e compagnia.</div>


<div><br></div><div>3. Nonostante tutto sono d'accordo, ma in un senso diverso. Ovvero oltre un certo livello di complessità la complessità inerente del linguaggio probabilmente diventa trascurabile rispetto quella del progetto. Linguaggi maturi come Java hanno una serie di librerie che aiutano, ma spesso sono abbastanza complicate e la loro complessità finirebbe per dominare la complessita' di un progetto medio. Viceversa su un progetto molto complesso si ripagano.</div>


<div><br></div><div>In questo senso la parte di codice in cui Python vince, su un progetto molto complesso probabilmente e' piccola. </div><div><br></div><div>Credo poi che il tutto dipenda da cosa intendiamo con "complesso". Io credo che tu parli di complessità orizzontale e ho applicato questa idea al mio precedente discorso.</div>


<div> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Questo non vuol dire che non sia un bel linguaggio ma quando si esce<br>
dall'ottica hobbistica e si entra in quella aziendale, le scelte non<br>
possono essere solo per quello che è più bello o quello che mi piace<br>
di più, ci sono aziende che per il software che producono trovano<br>
Python ideale, e questo è buone e giusto, altre aziende che fanno<br>
software diversi, il che non vuol dire migliori, non lo possono usare.<br></blockquote><div><br></div><div>Assolutamente. Ognuno fa le sue scelte. Pero' non necessariamente sono scelte ottime. </div><div>Pero' non metterei la cosa in hobby vs. azienda (sotto-intendendo che la logica aziendale sia migliore [0]).</div>


<div>Semplicemente uno si fa le sue scelte sulla base di motivazioni tecniche.</div><div><br></div><div>Forse io ho letto un po' troppo Graham, ma alla fine credo che le scelte coraggiose vadano fatte.</div><div><br>

</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Parlo per esperienza diretta e non per sentito dire, in azienda da noi<br>
sono state fatte delle scelte che a volte sono risultate sbagliate<br>
altre volte azzeccate, si cerca di imparare dai propri errori, abbiamo<br>
un software scritto in Python che è nato come prototipo, poi visto che<br>
era ben fatto e che i clienti lo apprezzavano è stato portato avanti<br>
come software in produzione, ora dopo qualche decina di migliaia di<br>
righe di codice funziona benissimo per carità, metterci le mani però<br>
non è più così "divertente", tanto che si sta pensando di riscriverlo<br>
in .NET<br></blockquote><div><br></div><div>IMHO questo esempio non calza troppo. Cioe' se prendi un software (scritto in qualunque linguaggio) e lo evolvi o molto a lungo o molto in fretta o semplicemente male (che sicuramente non e' il vostro caso) tipicamente hai un carrozzone che diventa sempre meno mantenibile. Non mi risulta che questo tipo di cose non possano succedere con .NET. </div>


<div><br></div><div>Credo anzi, sentendo tanti colleghi che lavorano con .NET, che siano cose che succedono anche con .NET, esattamente come con qualunque altra tecnologia. </div></div><div><br></div><div><br></div><div>

-----</div><div>[0] generalmente quando si parla di ottica aziendale sembra si voglia parlare di cose "serie" in contrapposizione all'hobbismo. Pero' invito anche a riflettere sull'altro lato della medaglia: ovvero di quanto la cosiddetta ottica aziendale sia lontana dall'ottica hacker. Ovviamente va benissimo per le aziende (guarda caso... :) ) o per lo meno per molte di esse. Pero' di per se a me non sembra una cosa positiva in assoluto.</div>

<div><br></div>-- <br> .<br>..: -enrico-<br>