Uso di una lingua diversa nello stesso progetto

Quando non devi, non farlo! Diventerà molto doloroso, specialmente se le lingue superano i confini come suggerito tu (leggi l'architettura pulita sui confini).

Se vuoi davvero farlo, ci sono i cosiddetti livelli di interoperabilità in ogni software (NDK per Java per esempio). Ma devi sempre preoccuparti della rappresentazione di variabili e concetti nella memoria e nella piattaforma sottostante.

Il peggio qui: hai tre tipi di linguaggi di programmazione completamente diversi: C è compilato e molto (molto) vicino all'hardware, Java è un mix tra compilato e interpretato ed è un po 'più lontano dalla piattaforma ( sta filtrando qua e là) e finalmente hai un linguaggio interpretato con python che nasconde l'hardware.

Il tuo argomento per farlo sembra per me un'ottimizzazione prematura: dovresti solo migliorare le prestazioni quando misuri un problema con le prestazioni nella tua attuale applicazione. Secondo me, Java è molto veloce attraverso il JIT (vedi Kafka per esempio - è incredibile)

Nota: quando vuoi veramente usare linguaggi diversi, assicurati che siano tutti sulla JVM come Java con Groovy e Jython per esempio.

[EDIT]: è stato menzionato nei commenti: ci sono casi d'uso in cui lingue diverse hanno un senso. L'esempio migliore è un'applicazione web, in cui sono presenti HTML, codice Java e codice SQL in un progetto (anche con tre diversi paradigmi: solo markup, imperativo, dichiarativo). Ma hai MOLTO confini chiari (HTML ha un'estensione di file diversa). Anche in questo scenario chiaro, è difficile non mescolare le lingue con i confini trasversali. Ad esempio, dovresti spingere tutto il codice SQL awai dalla tua logica aziendale e mantenere separato l'HTML. In breve: cerca di evitarlo, ma quando devi farlo, sii consapevole dei tuoi limiti.

Potresti provare a perfezionare il tuo concetto di "un progetto". Se stai usando le lingue lungo confini chiaramente definiti, sembra che tu abbia più progetti che lavorano insieme. Se questo è il caso, probabilmente è meglio suddividerli in progetti separati. Come distribuzione o distribuzione è possibile aggiungere la combinazione o la distribuzione nel processo di creazione. Questo approccio offre alcuni chiari vantaggi. Ti consente di mantenere una chiara distinzione delle dipendenze, mantiene una separazione delle preoccupazioni e rende il tuo codice più portabile / modulare.

Vedi questo approccio molto nelle applicazioni web e mobile. Ad esempio, un software su cui lavoro ha un backend PHP, un front-end dell'app JS e un'applicazione nodejs per gestire alcune routine pub / sub. Per mantenere le cose organizzate, il nodojs è completamente separato (e anche parti di esso sono nei loro repository). PHP e JS sono insieme al momento, ma stiamo lavorando per separare anche quelli per mantenere una netta separazione. Un altro vantaggio che questo ci offre è la possibilità di distribuire singole parti della nostra app separatamente senza interferire con gli altri.

Un altro esempio che viene in mente sono le app mobili, in particolare iOS. Nello stack puoi usare C, Objective C o Swift nello stesso progetto. Tuttavia nella pratica la maggior parte degli sviluppatori preferisce tenerli separati e invece creare librerie che in altre lingue sono progetti figlio. Sono gestiti dai gestori delle dipendenze della vista e combinati al momento della compilazione.

TLDR: mantienilo organizzato.

• Come lingua principale, interfaccia grafica e tutto, potresti utilizzare java .
• Per l'elaborazione di massa dei dati si potrebbe usare C .
• Per lo scripting si potrebbe usare Python , magari usando l'API java Scripting.

Avrebbe senso, e ha le responsabilità e le aree ben definite. Python su JVM potrebbe ovviamente fare qualcosa in più rispetto allo scripting.

Tuttavia, lo sviluppo diventa tortuoso lento, a causa del passaggio. Considerare se stessi con l'estensione di un'API su due lati della lingua è scomodo. Debugare di più. Meglio fare lo sviluppo basato su test, sviluppando parti in isolamento di un test unitario.

Il migliore (il più fluido) sarebbe quello di adattare uno sviluppo all-java a C e Python, sostituendo le parti.

Come dire java 9 con FX per la GUI richiederebbe già un grosso sforzo, non esserlo troppo entusiasta. Più il progetto è limitato, più uno può essere creativo, concentrandosi sul business a portata di mano, piuttosto che sulle caratteristiche tecniche di programmazione.