Python - GUI QT e richiamare form

[gpc]

no, certamente
intendevo Apache Spark per l' ultima domanda, utilizzandolo per apprendimento automatico
Mentre per il codice costruire le funzioni in Python, sfruttare le librerie QT per interfaccia grafica
Poi convertire (solo) le funzioni Python in altro linguaggio, diciamo solo la parte algoritmica (il discorso QT ovviamente è a parte)

 

[pabloski]

intendevo Apache Spark per l' ultima domanda, utilizzandolo per apprendimento automatico

Spark offre strumenti per il clustering e il calcolo parallelo. Tanto per dire, OpenMP su C++ opera nello stesso settore. Spark ovviamente ha più funzionalità. Ma comunque stiamo parlando di roba che deve girare da qualche parte.

Per quanto riguarda l'apprendimento automatico, Spark non offre una soluzione preconfezionata per il tuo problema, per cui dovrai implementare i modelli da solo.

Mentre per il codice costruire le funzioni in Python, sfruttare le librerie QT per interfaccia grafica

Certo.

Poi convertire (solo) le funzioni Python in altro linguaggio, diciamo solo la parte algoritmica (il discorso QT ovviamente è a parte)

Si può fare anche questo. Se il software è separato in moduli, si può ovviamente estrarne un pezzo ed usarlo per altri scopi e altre piattaforme.

 

[gpc]

Bene
però se si vogliono sfruttare le stesse funzioni su Python, Swift e Java, il codice da condividere deve essere scritto in C
Ad esempio si crea una funzione che deve essere invocata da tutti e tre, nominata "calcolo"
"calcolo" deve essere scritta in C e essere richiamata dai tre linguaggi tramite Ctypes, JNI e C interoperability
poi, se si deve aggiungere una funzione, da sfruttare dai tre linguaggi, nominata "elaborazione", anch' essa verrà scritta in C e richiamata dai tre linguaggi

 

[pabloski]

però se si vogliono sfruttare le stesse funzioni su Python, Swift e Java, il codice da condividere deve essere scritto in C

No. Condividere può significare tante cose. Condividere il codice? Condividere i binari? Condividere file oggetto?

Le librerie ( .dll per capirci ) esportano in moltissimi casi l'interfaccia C ed è questa che viene sfruttata da JNI e Ctypes. Qualsiasi linguaggio in grado di produrre una libreria che esporti un'interfaccia C, può andare bene.

Poi c'è la possibilità di usare linguaggi che compilano in C, cioè traducono il tuo programma ( in Nim per esempio ) in un programma C. Ma anche in questo caso tu programmi in Nim non in C. E' il compilatore Nim che poi trasforma il codice in C, in maniera completamente automatica. E ovviamente pure in questo caso puoi produrre librerie con interfaccia C da richiamare poi tramite i vari meccanismi di FFI dei più disparati linguaggi.

E ovviamente non ho volutamente introdotto le architetture client/server, che pure si possono usare. Nel web ci sono decine di tutorial su come interfaccia applicazioni Electron con C, C++, Rust, Go, ecc.... Tutte rigorosamente ficcano la logica di business in un'applicazione server, invocabile tramite RPC ( dei webservices insomma ).

 

[gpc]

il discorso client/server non è un pò "eccessivo" in un contesto del genere? Anche se per certi versi favorirebbe in certe cose

 

[pabloski]

il discorso client/server non è un pò "eccessivo" in un contesto del genere? Anche se per certi versi favorirebbe in certe cose

No. Un server non è necessariamente un mostro che consuma tutte le risorse hardware. E' solo un software connesso ad un socket che risponde a delle domande. Pulseaudio usa i socket per le sue comunicazioni ed è installato su tutti i sistemi GNU/Linux ed Android.

 

[gpc]

quali sono i linguaggi che possono produrre librerie da esportare in interfaccia C?

 

[pabloski]

quali sono i linguaggi che possono produrre librerie da esportare in interfaccia C?

Nim, Vala, Genie, Fortran, Matlab, OOC, Python, PHP tramite HipHop, Eiffel, alcuni LISP, Lua. E c'è la possibilità di fare dei giri, cioè trasformare X in Y e da Y andare al C. Si potrebbe compilare in Javascript e da lì in C. Le possibilità sono tante, ovviamente ognuna ha un suo prezzo.

 

[gpc]

quindi partendo ad esempio da Python creare queste librerie sfruttabili poi da Java e Swift

 

[pabloski]

quindi partendo ad esempio da Python creare queste librerie sfruttabili poi da Java e Swift

Entro i limiti imposti da Cython. Ovviamente non puoi prendere un linguaggio dinamico e trasformare il codice in esso scritto in C pari pari. Esistono delle cose che il C non supporta, alcune sono implementate nei runtime dei vari linguaggi traducili in C, altre non si possono fare.

Comunque l'idea è quella. Scrivere il codice in un linguaggio e trasformarlo in un binario che segue lo standard C e quindi linkabile da altri linguaggi che supportano la FFI stile-C.

 

[gpc]

i risultati quindi potrebbero non essere sensazionali
L' idea è sfruttare Cython

 

[pabloski]

i risultati quindi potrebbero non essere sensazionali
L' idea è sfruttare Cython

No semplicemente ci sono delle funzionalità di Python che non si possono usare. Ma c'è scritto nella documentazione di Cython cosa manca. E sono comunque cose che normalmente non si usano.

 

[gpc]

da linguaggio R suppongo neanche a parlarne
qual' è il "miglior" linguaggio per fare una cosa del genere?

 

[pabloski]

qual' è il "miglior" linguaggio per fare una cosa del genere?

Nim.

 

[gpc]

se si dovessero utilizzare librerie matematiche o statistiche è possibile?