[Python] Scegliere un linguaggio: un'ottimizzazione prematura?

[Gianluca Esposito]

Il giorno 10 aprile 2017 12:37, Davide Olianas <davide a davideolianas.com>
ha scritto:

> Il 10/04/2017 09:54, Roberto Polli ha scritto:
>
>> Che ne pensate?
>>
>> "Choosing a language for you application simply because its “fast” is
>> the ultimate form of premature optimization."
>>
>>
> Ciao lista,
>
> premetto che essendo uno studente, oltretutto di un settore diverso
> dall'informatica, la mia opinione al riguardo conta ben poco; confutazioni
> delle mie opinioni sono ben accette se argomentate.
>
> Vorrei dire la mia perché sto facendo dei conti con un programma di
> quantochimica che terminano mediamente in qualche giorno, su una macchina
> con due processori Xeon da dieci core ciascuno. Questo programma scritto in
> Fortran (Gaussian se qualcuno è curioso) sfrutta tutti i processori in modo
> efficiente (almeno spero). Già qua python sarebbe fregato dal GIL volendo
> usare un approccio multithreading. Se dovessi aspettare venti volte
> "qualche giorno" - diciamo tre mesi - per un singolo risultato, sarebbe
> troppo (e qua concordo con l'articolo riguardo alla questione dei tempi).
>

Dico anche io la mia sulle performance...
Le performance non sono un prerequisito a prescindere, le performance sono
un requisito specifico di ogni singolo software.
Questo è uno dei motivi per cui non programmiamo tutti in assembler, ma
usiamo generalmente linguaggi di alto livello per sviluppare il 99% dei
nostri algoritmi, proprio perchè il 99% del software che sviluppiamo non
necessita di performance estreme.
Vogliamo parlare di manutenibilità? immagina se domani scopri che
l'algoritmo che stai usando non è il più efficiente per fare l'elaborazione
che vuoi fare, ma esiste un algoritmo più efficiente, quanto tempo ci vuole
a riscrivere tutto il software in assembler o in python?
Poi sei sicuro che siano così distanti le performance dell'algoritmo in
python e quelle in fortran? magari prova a creare una applicazione non in
multithreading, ma in multiprocessing, così sfrutti tutti e 20 i core e
soprattutto MISURA le performance di uno e dell'altro.
Se ancora sei distante, in python esistono molte librerie matematiche che
in realtà sono compilate in c e hanno un binding a python, prova ad usare
una di quelle.
Se ancora non ti sei avvicinato, individua la parte di codice lenta e
riscrivi solo quella parte in c e poi la richiami dal programma python e in
python questa operazione è molto facile.
Come vedi prima di scegliere un linguaggio compilato perchè è più veloce,
ci sono un bel pò di ragionamenti e prove da fare.
Magari ti avvicini molto ai tempi del linguaggio compilato, senza
sacrificare tutti i vantaggi del linguaggio di alto livello.



> Ovviamente direte "ma chissenefrega delle tue necessità di nicchia!" Al
> che posso anche essere d'accordo, però mi sembra che l'autore dell'articolo
> abbia decisamente ristretto la visione al settore del web development.
>
> Non mi piace quando l'autore afferma che basta tirare nuovo hardware ai
> problemi per risolverli. In quanto utilizzatore di tecnologia posso dire
> che sono stufo di app mattone che prosciugano la batteria dello smartphone
> o sono lente. Sono stufo di siti lenti. Sono stufo di vedere KDE dieci
> volte più lento ad avviarsi di gnome o unity.
>
Cambiare il linguaggio di backend non credo aiuti, dipende da quante
informazioni ci sono nella pagina web e quanto è veloce la tua connessione.
Per le app non ha alcun senso, possono essere ottimizzatissime, ma magari
controllano la rete wifi ogni millisecondo e la batteria te la ammazzano lo
stesso.

Ciao,
Gianluca

>
> Oltretutto, finché non si trova un metodo economico su larga scala di
> riciclare i materiali dell'hardware, il cumulo di spazzatura tecnologica
> continua ad aumentare. Qua si esula di molto dal tema programmazione, ma
> vorrei ricordare che il codice non rimane nell'Iperuranio. Codice
> efficiente ha anche un minor impatto ambientale.
>
> Ciao,
> Davide
>
> _______________________________________________
> Python mailing list
> Python a lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20170410/6b377ee7/attachment.html>