Hai mai fatto un progetto usando un linguaggio che non è la scelta principale per la nicchia specifica del progetto? Perché? [chiuso]

Sto utilizzando Falcon in un progetto di gioco commerciale, come linguaggio di scripting.

Però non è il mio giorno.

Il motivo principale è che voglio qualcosa che sia facilmente integrabile e controllabile da C ++ come Lua, ma con una sintassi e caratteristiche del linguaggio più simili a Python. Python può essere incorporato, ma trovo che sia APITA da incorporare, anche se può essere fatto.

I falsi hanno una sintassi simile a Python ma forniscono più paradigmi, quindi puoi usare quelli più adatti per lavorare con il tuo progetto specifico. È completamente scritto in C ++ e fatto per essere incorporato (non in un modo Luabind, ma più come manipolare una specifica libreria di motori). È possibile iniettare i moduli nelle lingue, i moduli vengono scritti in C ++ (o completamente in Falcon). Una volta che hai fatto un modulo specifico per l'applicazione, non devi fare nient'altro per consentire a Falcon di lavorare con esso.

Un'altra alternativa che corrisponde ai miei requisiti ma che è ancora troppo giovane è ChaiScript - che è davvero promettente. Sto provando a usarlo in un progetto giocattolo, ma non ho potuto lavorare ancora molto con esso.

Sto usando questo in un altro progetto. Per il momento userò Falcon, ma verrà refactored sul sistema di inclusione per renderlo ancora più facile. Se il refactoring è completo una volta che ho bisogno di completare la parte scripting del mio progetto (non presto), continuerò con esso (anche se gli sceneggiatori dovranno scrivere in un'altra lingua sconosciuta, non mi interessa per questo specifico progetto, ed è facile da imparare per persone familiari a Python o Ruby comunque).

Nel mio lavoro diurno, ho recentemente scritto un piccolo strumento throw-away che mostrava alcune funzionalità tramite una versione leggermente modificata di Picol (un interprete Tcl molto piccolo).

Man mano che queste cose vanno, lo strumento non è stato gettato via ma è cresciuto e ora è uno strumento fondamentale per il progetto :(

Ho usato Picol per il mio fascino con gli interpreti e ho pensato che avrei potuto farcela perché nessuno dei miei colleghi avrebbe dovuto vedere lo strumento.

Ho usato Haskell per programmare un programma middleware critico. Potrei fare questa scelta perché ero l'unico nella squadra a fare questo (che di per sé non è una buona cosa). Altri motivi per sceglierlo erano che il progetto era molto limitato nel tempo e anche che il programma risultante doveva funzionare in un ambiente di risorse relativamente basso.

E alla fine, avevo fame di provare Haskell per qualcosa di reale, dopo averlo studiato per anni.

Il risultato è stato abbastanza buono. Il problema peggiore era una libreria (che era un wrapper attorno a una libreria C) che perdeva la memoria male, ma fortunatamente, ero in grado di sostituirlo con una pura libreria Haskell. Gli strumenti del profiler hanno aiutato a trovare il problema in questo caso. Inoltre, trovare una buona libreria XML è stata una seccatura.

Le parti migliori erano che l'implementazione dell'intero progetto era generalmente veloce e divertente. Inoltre, sono stato in grado di apportare modifiche radicali e ghc mi ha protetto durante il processo.

Rendere le persone interessate a una nuova lingua è difficile. Specialmente quelli più esperti sono abituati ad essere bravi a programmare, e sembra che sia praticamente un killer motivazionale capire che le loro abilità sono piuttosto specifiche.

Ho usato Tcl / Tk per un prototipo multipiattaforma del sistema legacy COBOL in transizione senza una determinazione su uno specifico host / stack di destinazione. Il cliente non aveva deciso se il piano tecnico di 3 anni e 5 anni avrebbe continuato a richiedere i desktop Solaris e, in caso contrario, volevano passare a NT / 2000. E 'stato all'inizio all'insaputa del codice throwaway

Gli obiettivi erano di passare dalle interfacce terminali alla finestra nativa e agli output che erano ricchi di formattazione. Usando Tcl / Tk potrei cambiare rapidamente i layout e usare il suo exec interno per interagire con gli eseguibili Cobol esistenti con un adattamento minimo per essere guidato esclusivamente dalle opzioni della riga di comando.

Non sono sicuro di ciò che conta come lingue mainstream in questi giorni, ma ho fatto (molto tempo fa) un bel po 'di programmazione Auto / Visual LISP per facilitare la generazione automatica di modelli e disegni di Autocad. Alla fine, la maggior parte del codice di generazione era in LISP (è iniziato come un progetto Fortran / C, ma quella parte era così semplice, abbiamo appena trasferito tutto a LISP a un certo punto). Ho lasciato quel posto a un certo punto, ma non sarei sorpreso se il progetto fosse ancora vivo.

Faccio la maggior parte del mio dottorato. codice di ricerca in D . È certamente stato un po 'un PITA perché ho dovuto affrontare l'immaturità della lingua e della toolchain. Questo sta migliorando rapidamente ora che le specifiche del linguaggio sono stabili. Se dovessi farlo di nuovo, lo farei sicuramente, per i seguenti motivi:

1. La maggior parte delle cose che scrivo è piuttosto affamata di memoria e critica dal punto di vista delle prestazioni, ma è anche un codice prototipo in cui la velocità di sviluppo è importante. D è l'unica lingua che conosco che abbia un buon punteggio sia nella convenienza del programmatore che nell'efficienza di runtime. (Forse C # si adatterebbe al conto, ma non ha metaprogrammazione del modello come D, che rende molto più difficile trovare soluzioni riutilizzabili / generiche efficienti, ma ha anche le tracce di OO shoving in stile Java lungo la gola e altri simili bondage -e-disciplina caratteristiche.)

2. Ho scritto diverse librerie per compensare la mancanza di supporto della libreria di D e questa è stata un'esperienza di apprendimento tremenda . Ho scritto la mia libreria di parallelismo SMP, che ora è in revisione per l'inclusione nella libreria standard. Ho scritto la mia statistica / libreria di apprendimento automatico, e ora sento di conoscere questa roba di ordini di grandezza migliore di quando stavo prendendo lezioni in esso. Ho scritto la mia libreria di plottaggio e ho imparato un sacco di informazioni sulla visualizzazione dei dati e sulla programmazione della GUI. Inoltre, questi sono tutti progetti open source che posso mettere su un curriculum. Se mi fossi imbattuto in un linguaggio più mainstream, probabilmente mi sentirei come se tutte le "interessanti" attività di sviluppo della libreria fossero già state fatte.

3. Partecipare alle discussioni sulla progettazione della lingua, ecc. è stata anche un'esperienza formativa eccezionale.

4. Se nessuno avesse mai sopportato alcun dolore a breve termine per fare una pausa netta con le tecnologie legacy crufty, avremmo programmato tutti in Fortran '77. Chiamami un idealista, ma questo non è il futuro che voglio.

Smalltalk da solo, probabilmente, non è tanto una cosa killer rispetto alle attuali tecnologie mainstream. Ma se prendi Mare , è certamente possibile giustificare la scelta.

Inoltre, ci sono lingue non mainstream che sono molto più potenti di qualsiasi tecnologia popolare, che per un progetto complicato che richiede tutta la potenza che si può ottenere è semplicemente una scelta. Uso il Lisp prevalentemente per la maggior parte del mio lavoro di sviluppo e ho un'enorme toolchain di linguaggi specifici di dominio progettati su Lisp - semplicemente non sarebbe possibile farlo in qualsiasi altra lingua. Quindi ora sto usando linguaggi non tradizionali molto più di quelli tradizionali.

Un altro caso per "non mainstream" sono i vecchi sistemi legacy con i loro linguaggi di script strani - ad esempio, CAD.

Ho lavorato su diversi progetti utilizzando linguaggi personalizzati specifici per le società per le quali sono stati sviluppati i sistemi. Ho anche lavorato su diversi progetti utilizzando un nuovo oscuro linguaggio chiamato Java a metà / fine anni '90, un linguaggio che al momento gli esperti prevedevano non sarebbe mai stato ampiamente adottato, ma è successo a fare ciò che ci serviva. E ho lavorato a un progetto molto ampio in un dialetto personalizzato di Cobol, un'altra lingua che la gente ora sostiene sia morta. Poi c'è il progetto in cui sono stato un po 'coinvolto in Fortran, un altro in QuickBasic, Delphi, tutte lingue che sarebbero ormai adatte al tuo "non mainstream" ma all'epoca erano molto più comuni.

Nel mio paese, tutto ciò che non è Microsoft, è considerato "non mainstream", compresi i linguaggi di programmazione che potrebbero essere "mainstream" in altri luoghi (Java o Delphi, chiunque?).

In qualsiasi paese, molte società o enti governativi. hanno paura di non ottenere sviluppatori per un dato (linguaggio di programmazione e programmazione), quindi preferiscono le lingue tradizionali.

Ma, secondo la mia esperienza, le lingue "mainstream" possono ritorcersi contro, perché ciò significa che il tuo sviluppatore potrebbe facilmente ottenere un lavoro migliore e lasciare il progetto.

E gli sviluppatori che lavorano in un linguaggio non mainstream, di solito sono più attenti alla qualità del software.

Avere troppi sviluppatori significa che ci sarà di più con una qualità inferiore. E in alcuni luoghi, le aziende non possono filtrare gli sviluppatori malintenzionati, non sanno come filtrarli o, addirittura, non si preoccupano di filtrare gli sviluppatori malvagi, purché siano economici.

Abbiamo lavorato in un progetto Delphi, dove abbiamo bisogno di più sviluppatori, e il cliente lo sapeva. Assumiamo alcuni sviluppatori C / VB e insegnamo loro sulla lingua e il framework, e persino, controlliamo le loro abilità di algoritmo / design pattern. Insegnare loro un linguaggio non mainstream, puramente, ci ha aiutato, rendici sicuri, che sapevano come risolvere anche i problemi.

Ha realizzato un progetto di ottimizzazione euristica in TI Lisp in cui il resto del progetto era in una lingua diversa ( CMS2 , se devi saperlo).

Utilizzi simili degli script emacs lisp in ambienti C / Java.