PROBLEMA Richiesta di pareri : QT o non QT

[RollerSitch]

Ciao a tutti,

sto per accingermi allo sviluppo di un software in collaborazione con un biologo, l'idea è che sia una interfaccia grafica che supporti il suo lavoro nella valutazione di certi parametri.

E' quindi pensato per girare su macchine aziendali o comunque nella Sanità, perciò spesso non troppo aggiornate o performanti.
Vorrei fosse inoltre più cross-platform possibile. Ho una discreta esperienza con Java e le SWT, le quali so bene risolverebbero il mio problema (il software non è pesante dal punto di vista computazionale nè dal punto di vista grafico).
Tuttavia vorrei usare un approccio multithread e quindi non posso usare primitive di li vello troppo basso (pthread sono le uniche che conosco).

Mi sono però lasciato imbambolare dalle meraviglie decantate sulle QT, sulla loro portabilità sia in Windows che in Unix-like e sui fantastici binding in C++ e (ancora più intrigante per me) in Python con PyQT.
Trattandosi di un mio progetto non ho termini di scadenza e ho anche pieno potere di decisione, ne vorrei approfittare per accrescere la conoscenza di Python e delle QT.

Tuttavia ho studiato da Ing.Informatico e mi occupo della gestione di sistemi aziendali, non ho mai fatto "il programmatore" uscendo dalla mia stanza, e vi chiedo se avete esperienza delle QT, di PyQT, e dei pareri sulla loro semplicità di porting e performance.

Grazie a tutti

 

[signore del tempo]

Buonasera Rollerbitch*,

Non conosco direttamente le Qt, pertanto non prendere quello che dirò per verità assoluta. Comunque tale libreria fornice un ottimo livello di portabilità, che sia Windows/Linux e così via. Ma la libreria fa anche di più: ti permette di approcciarti con networking, multithreading, filesystem management ad un livello più alto. Ma servono realmente queste cose in C++? Imho no.

Con il C++11, il C++ si è evoluto in un linguaggio molto più espressivo e potente (i variadic template sono da paura) e lo diventerà ancora di più con gli standard successivi(C++14 e C++17). Col nuovo standard la gestione del multithreading è stata implementata (dai un'occhiata a std::thread, std::async, <mutex>, <atomic>, <future> ecc.). Come ulteriore semplificazione del multithreading c'è OpenMP e Intel TBB (per citarne qualcuna), sebbene ti consiglio la TBB poiché OpenMP è fondamentalmente un set di direttive mentre TBB è più OOP e generico.
Entrambe ti permettono di dividere un task sui vari thread disponibili, automaticamente.

Java lo escluderei (è un linguaggio privo di senso imho) la "portabilità" è quasi una finzione, per non parlare della sua lentezza e richiesta di risorse. Poi chiaramente se hai necessità di interfacciarti con sensori, pin o altre cose a basso livello, C e C++ regnano.

*non so quanto il nome sia congruente al regolamento

 

[RollerSitch]

Grazie signore del tempo,

Innanzitutto ti ringrazio della segnalazione di OpenMP e TBB, ho studiato il threading sulle pthread in C e sebbeno siano molto istruttive è difficile essere produttivi quando devo implementarmi a mano perfino un semplice monitor. Non ho mai affrontato il threading in altri modi e queste tue mi ci hanno indirizzato.

Tornando al problema, capisco il tuo ragionamento, però ho bisogno di concentrarmi sulla logica di programma, la mole di dati è enorme e dovrà essere gestita in un database , ed è necessaria una certa modularità di configurazione perchè i parametri standard sono in corso di revisione e questo renderebbe il mio software obsoleto prima ancora della final release.
Quindi un "framework" che mi gestisce il threading e la GUI at once mi riesce molto comodo.
Hai ragione che il C++ non ne bisogna, allora anche tu andresti verso PyQT nella mia situazione? :)


*fixed Scusatemi è il nick che uso sempre e non ci ho pensato

 

[signore del tempo]

Tornando al problema, capisco il tuo ragionamento, però ho bisogno di concentrarmi sulla logica di programma, la mole di dati è enorme e dovrà essere gestita in un database
Hai ragione che il C++ non ne bisogna, allora anche tu andresti verso PyQT nella mia situazione? :)

La prima frase consiglia e sconsiglia Python come linguaggio. Python ti permette di concentrarti molto vicino all'algoritmo vero e proprio, ma python interpretato direttamente e quindi non compilato in bytecode, è lentuccio.
Tuttavia stiamo sempre parlando in termini generici, la scelta finale sta a te. Poi chiaramente questa è solo la mia opinione, altri potrebbero averne differenti.

 

[RollerSitch]

La prima frase consiglia e sconsiglia Python come linguaggio. Python ti permette di concentrarti molto vicino all'algoritmo vero e proprio, ma python interpretato direttamente e quindi non compilato in bytecode, è lentuccio.

Secondo te sarebbe troppo complesso usare codice python "compilato" (bytecode) e compilare separatamente per Linux e Windows?(fino a poco tempo fa esistevano dei programmi "pyexe" o qualcosa di simile) Credi che le performance migliorerebbero sensibilmente?

Forse la mia domanda avrebbe dovuto essere "Il codice Python (PyQT, python "compilato" ecc.) ha prestazioni decenti su macchine non di ultima generazione e/o Windows?"

 

[signore del tempo]

Secondo te sarebbe troppo complesso usare codice python "compilato" (bytecode) e compilare separatamente per Linux e Windows?(fino a poco tempo fa esistevano dei programmi "pyexe" o qualcosa di simile) Credi che le performance migliorerebbero sensibilmente?

Suppongo di sì, ma marginalmente: solo la compilazione sulla macchina dell'utente, con i relativi flag, porta vantaggi. Quando compili per Windows e Linux, il compilatore scriverà codice generico perché chiaramente non avrà informazioni sulla macchina dove girerà il programma. Non saprà che famiglia di CPU è, quanti livelli di cache ci sono, quanta ce n'è, se vi è supporto per istruzioni SIMD ecc.

 

[pabloski]

Forse la mia domanda avrebbe dovuto essere "Il codice Python (PyQT, python "compilato" ecc.) ha prestazioni decenti su macchine non di ultima generazione e/o Windows?"

Direi che la domanda trova risposta in questa frase "il software non è pesante dal punto di vista computazionale nè dal punto di vista grafico".

Non pensare che Python sia un bradipo. Certo c'è di meglio ( sul fronte prestazionale ), ma Python va più che bene. E questo è il discorso CPython.

Ma il diavolo si nasconde nei dettagli ( come sempre ). PyPy è un'implementazione di Python che è molto molto più performante di CPython. La fregatura è che si perde la possibilità di creare degli script python freezed ( cioè degli exe ).

Considera inoltre che esiste IronPython, ovvero un'altra implementazione di Python, che però ha come target .NET. Il risultato è che puoi creare degli eseguibili ( eseguibili .NET ovviamente, non i binari nativi, ma non ti cambia in sostanza nulla ). Inoltre è possibile utilizzare gli stessi binari su sistemi Linux/Unix/Mac tramite Mono. Mono e .NET presentano qualche differenza, ma si tratta di mancanze aggirabili abbastanza facilmente. Ovviamente sto sempre considerando di usare QT. Ma usando .NET e Mono, puoi benissimo optare Windows Forms ( oddio, fossi in te le eviterei ).

 

[RollerSitch]

Direi che la domanda trova risposta in questa frase "il software non è pesante dal punto di vista computazionale nè dal punto di vista grafico".

Non pensare che Python sia un bradipo. Certo c'è di meglio ( sul fronte prestazionale ), ma Python va più che bene. E questo è il discorso CPython.

Ma il diavolo si nasconde nei dettagli ( come sempre ). PyPy è un'implementazione di Python che è molto molto più performante di CPython. La fregatura è che si perde la possibilità di creare degli script python freezed ( cioè degli exe ).

Considera inoltre che esiste IronPython, ovvero un'altra implementazione di Python, che però ha come target .NET. Il risultato è che puoi creare degli eseguibili ( eseguibili .NET ovviamente, non i binari nativi, ma non ti cambia in sostanza nulla ). Inoltre è possibile utilizzare gli stessi binari su sistemi Linux/Unix/Mac tramite Mono. Mono e .NET presentano qualche differenza, ma si tratta di mancanze aggirabili abbastanza facilmente. Ovviamente sto sempre considerando di usare QT. Ma usando .NET e Mono, puoi benissimo optare Windows Forms ( oddio, fossi in te le eviterei ).

Grazie per la risposta intanto, :)


No vorrei evitare Mono e .NET perchè ho avuto brutte esperienze, mi stanno antipatiche e comunque ancora la piena compatibilità con le diverse ditro Linux non è perfetta da quello che vedo. (Non parliamo di Windows Forms :D)

Perdona la mia ignoranza,ma le diverse implementazioni comunque eseguono codice Python standard se ho ben chiara la cosa, solo implementano internamente le funzionalità in C, python stesso ecc.
Non mi è chiaro come risolvano (o perlomeno ci tentano) il mio problema, potresti spiegarmelo?

 

[pabloski]

Perdona la mia ignoranza,ma le diverse implementazioni comunque eseguono codice Python standard se ho ben chiara la cosa, solo implementano internamente le funzionalità in C, python stesso ecc.
Non mi è chiaro come risolvano (o perlomeno ci tentano) il mio problema, potresti spiegarmelo?

PyPy è compatibile con CPython, cioè implementa lo stesso identico linguaggio. La differenza sta nel metodo di compilazione degli script usato da PyPy.

Dal punto di vista del programmatore si tratta di scrivere codice python, ma col vantaggio di avere performance molto superiori.

Una differenza che è bene far notare, è che PyPy ha implementato alcune idee del progetto Stackless Python ( microthread, canali, greenlets, ecc... ). Vale la pena citarli perchè offrono un aiuto enorme per lo sviluppo di applicazioni multithreaded.

 

[RollerSitch]

Grazie,

Alla fine credo di aver deciso, userò PySide (come PyQT ma licenza più permissiva)
Poi farò dei test su diverse macchine e in caso considererò la "compilazione" con le diverse implementazioni.
So che è possibile inserire un interprete python nel pacchetto di programma per essere usato su windows o su macOS, dove magari spesso python non è preinstallato.