Vantaggi della combinazione dei linguaggi di programmazione [chiuso]

Un tipico esempio si presenta nei giochi per computer, in particolare i titoli AAA dove un backend C ++ è la norma. La sezione di interfaccia sarà spesso progettata in un linguaggio di scripting come Python o Lua. Ciò consente una facile modifica da parte degli sviluppatori in modo che possano testare nuove progettazioni dell'interfaccia senza compromettere la complessità dei motori fisici e grafici sottostanti e allo stesso tempo consente facili modifiche da parte dei giocatori che potrebbero non avere le costolette di codifica per gestire un pieno motore di gioco, ma può fare con competenza alcune modifiche all'interfaccia.

Un altro caso di utilizzo diffuso è il web stesso. Javascript, CSS e HTML si combinano per formare un front end con quello che vuoi come back-end sul server. Le app di Windows 8 usano un approccio simile con il dichiarativo XAML che definisce le interfacce e fornisce i contorni di classe mentre C # riempie i dettagli ed esegue la cosa.

Quindi, il tipico divario sarà un linguaggio veloce, tipizzato staticamente, che esegue un codebase ben collaudato che gestisce un lavoro strongmente numerico con un linguaggio di scripting in esecuzione per fornire frontend facilmente modificabili che gestiscono le funzioni visive e di presentazione e input.

Esistono anche altri casi d'uso. I linguaggi di elaborazione dati come R possono essere imbullonati ad altre basi di codice per fornire funzioni analitiche e di presentazione più facilmente di quanto potrebbe essere in grado la base di codice nativa. Per quanto riguarda le combinazioni di paradigmi, una combinazione di Prolog per il lavoro di database e qualche altro linguaggio per gestire le funzioni standard del programma è un caso noto. Un altro caso sarebbe avere routine Fortran o Assembly per il calcolo numerico veloce all'interno di un linguaggio di scripting come Python. Che è esattamente ciò che fanno Numpy e Scipy.

I linguaggi di programmazione sono fondamentalmente astrazioni che ti aiutano ad aiutarti a dire al computer cosa fare. Dal momento che sono astrazioni, ciò significa che nascondono alcuni dettagli e semplificano così il compito generale, permettendoti di comprendere come fare un particolare pezzo di programmazione senza dover comprendere tutto in una volta. Ma nascondendo significa anche che restringono ciò che puoi fare: uscire dall'astrazione è difficile, e così anche dover costruire molte nuove astrazioni oltre il livello base fornito dalla lingua.

L'effetto netto di ciò è che un particolare linguaggio di programmazione ha una gamma di attività di programmazione a cui è adatto, ma non sarà adatto a tutto. Un linguaggio di programmazione di basso livello consente di eseguire lavori di basso livello, che spesso sono critici dal punto di vista delle prestazioni (come l'elaborazione numeric-heavy). Va bene, ma fare un lavoro di alto livello nella stessa lingua non è semplice come usare un linguaggio specializzato in astrazioni di livello superiore. Inoltre, non c'è un insieme perfetto di astrazioni da scegliere: alcuni problemi sono meglio descritti in un gruppo (ad es. Programmazione funzionale), mentre altri richiedono un approccio diverso (ad es. Programmazione logica).

Il modo migliore per uscire da questa situazione in cui un linguaggio di programmazione in grado di svolgere un'attività non va bene per gli altri è utilizzare più linguaggi di programmazione. Lascia che ogni lingua si concentri su come eseguire le attività a cui è utile, quindi trasferisci il controllo sul codice scritto in un'altra lingua per altre parti. È specializzazione (e anche componentizzazione) ed è davvero una buona cosa. Naturalmente, ci sono linguaggi che funzionano particolarmente bene insieme poiché hanno ABI strongmente compatibili (ad es., Java e Scala, C # e VB, C ++ e Lua) ma non sono certamente gli unici livelli che puoi collegare insieme a. In effetti, quando accedi a un servizio web probabilmente stai usando le stesse idee: le lingue in cui i client sono scritti non sono probabilmente quelle in cui i server sono scritti, anche se non c'è un motivo teorico per cui una lingua non possa fai entrambe le parti, alcune lingue hanno migliori astrazioni per un lato o l'altro.

Un altro esempio non menzionato è l'uso di un nuovo paradigma di programmazione con codice e / o librerie esistenti.

Ad esempio, Java ha tonnellate di librerie e framework esistenti che possono essere utilizzati direttamente da nuovi linguaggi come Scala e Clojure. In questo modo, si ha il vantaggio di utilizzare un'implementazione pulita di un paradigma di programmazione diverso che non è supportato da Java, pur mantenendo la compatibilità con il codice legacy e le librerie esistenti. (Ho scelto Java, Scala e Clojure ma probabilmente ci sono altri esempi che non conosco).

Non esiste un linguaggio di programmazione "generico". Ogni lingua è strong in una zona e inutile negli altri. Pertanto, in un progetto complesso che copre molti domini diversi è più efficiente utilizzare più lingue. Per quanto ne so, non ci sono benefici nell'utilizzo di una singola lingua per un progetto in cui è possibile utilizzare più lingue.

Naturalmente, la lingua più efficiente per qualsiasi dominio problematico è un linguaggio su misura per questo dominio ristretto. Questo approccio è noto come Programmazione orientata alla lingua , e tali linguaggi sono chiamati Lingue specifiche del dominio . Ma anche se, per qualche strana ragione, non vuoi implementare le tue lingue, ci sono più lingue pronte per l'uso, e sceglierne una più adatta per un compito sarà comunque molto più efficiente che usare un linguaggio che non adattarsi bene ai vincoli del dominio del problema.

Uno dei modi più efficienti e convenienti per combinare lingue diverse è l'utilizzo di DSL incorporati ospitati all'interno di un singolo meta-linguaggio. In questo modo non avrai bisogno di alcuna FFI, puoi riutilizzare le funzionalità della tua libreria di lingue host dai tuoi DSL, puoi riutilizzare il tuo compilatore ottimizzando la lingua dell'host.

Un altro approccio comune è quello di ospitare lingue diverse all'interno di un runtime di una singola VM comune, come Java + Clojure + Scala o C # + VB.NET + F #.

Direi che il vantaggio è ottenere la soluzione più espressiva e più efficace al problema. Inoltre, l'incorporamento di una lingua in un'altra spesso ti consente di passare a un livello più alto di astrazione per parti del tuo lavoro.

Sto facendo lo sviluppo IOS, quindi naturalmente sto scrivendo in Objective-C ++, che fornisce l'incredibile potenza e complessità del C ++ e l'associazione e l'introspezione run-time di Objective-C. Penserei che questo sia forse il linguaggio / paradigma "ibrido" più popolare al momento. Spesso scriverò file .mm (oggettivo c ++) con principalmente C ++ e STL e solo un piccolo Objective-C. Ad esempio, la scorsa settimana ho scritto una macchina a stati in C ++ che ha richiamato in un oggetto Objective-C per eseguire le sue azioni. Scrivere la macchina in C ++ era più facile, più espressivo e riutilizzabile.

In questo particolare progetto, ho anche scritto un interprete di schemi che è incorporato nel programma ed è usato per controllare un canale di comunicazione scrivendo uno schema in fase di esecuzione in base alle condizioni ambientali. Scheme è una buona scelta per questo perché è così piccolo, semplice e "codice è dati". Aumenta anche il livello di astrazione e un approccio funzionale funziona bene in questa situazione.

Non trovo di includere piccoli linguaggi per astrarre problemi complessi inusuali. Che si tratti di un insieme di token in una stringa che controlla un interprete per guidare un albero decisionale complesso o un linguaggio specialistico completo del mio progetto o un problema unico, o una soluzione più standard come LUA.

Tkinter è una libreria grafica per Python costruita su Tcl / Tk. In realtà è un interprete Tcl incorporato che viene chiamato da python. Normalmente questo passa in gran parte inosservato, ma è possibile inserire il codice tcl in una stringa ed eseguirlo direttamente nell'interprete. Questo ti permette di fare cose che il tcl / tk nativo può fare a meno di Tkinter a causa di un'implementazione incompleta.

Due esempi:

1. Ha scritto un sistema che ha importato fogli di calcolo CSV e XLS in un database utilizzando documenti di mappatura personalizzati. Ha scritto quel sistema in Java e ha funzionato bene. Poi è arrivato il requisito di leggere quei documenti da un server FTP che avrebbe dovuto essere interrogato a intervalli regolari. Ruby è perfetto per quello, potrebbe scrivere quel codice molto più efficientemente in Ruby che Java. Quindi ha scritto uno script Ruby per eseguire il polling e recuperare i documenti, che li hanno alimentati all'applicazione Java originale che potrebbe ancora essere definita autonoma per inserimenti o test aggiuntivi
2. Lavorare su un sistema scritto in una lingua vecchia che probabilmente sta andando presto a fare il dodo (perdendo il supporto di toolvendors, provider di formazione, ecc.). Portare l'intero sistema in un nuovo ambiente in una volta sola sarebbe troppo rischioso per il business, richiedere troppo tempo per favorire il marketing e negare nuove funzionalità ai clienti che hanno richiesto. Quindi creiamo per diverse versioni un sistema ibrido, con parte creata in quella vecchia tecnologia e parte nel nuovo, gradualmente passando da uno all'altro fino a quando in un anno o due forse il vecchio sarà stato ritirato.
3. Ogni sistema che utilizza servizi Web (o altra EDI) per comunicare è intrinsecamente ibrido, almeno in potenza. Non importa per il tuo cliente se il fornitore di servizi web è scritto in Java, C #, Cobol o qualsiasi altra cosa purché i documenti scambiati siano in un formato comprensibile da entrambe le parti. Rende la massima flessibilità nel caso in cui diversi team lavorino fianco a fianco con competenze diverse. Ciascuno può impiegare la tecnologia che conosce meglio, il risultato finale sarà migliore di conseguenza.

Se in realtà è un vantaggio nel mescolare due lingue, presto una delle due lingue prende elementi o concetti del secondo, oppure emerge un nuovo linguaggio "tra" entrambe le lingue (si potrebbe argomentare che questo è successo con Scala, che praticamente si trova nel "mezzo" tra Java e Haskell).