Quando una nuova lingua è lo strumento giusto per il lavoro?

StackOverflow https://stackoverflow.com/questions/193941

  •  10-07-2019
  •  | 
  •  

Domanda

Per molto tempo ho provato diverse lingue per trovare il set di funzionalità che desidero e non sono stato in grado di trovarlo. Ho delle lingue che si adattano decentemente a vari miei progetti, ma ho trovato un'intersezione di queste lingue che mi permetterà di realizzare il 99,9% dei miei progetti in una sola lingua. Voglio quanto segue:

  • Costruito su .NET o ha un'implementazione .NET
  • Ha poche dipendenze dal runtime .NET sia in fase di compilazione che in fase di runtime (questo è importante poiché uno dei principali casi d'uso è nello sviluppo incorporato in cui il runtime .NET è completamente personalizzato)
  • Ha un compilatore che è un codice .NET al 100% senza dipendenze non gestite
  • Supporta l'annidamento di espressioni arbitrarie (vedi sotto)
  • Supporta definizioni operatore personalizzate
  • Supporta l'inferenza del tipo
  • Ottimizza le chiamate di coda
  • Ha definizioni esplicite immutabili / mutabili (gentilezza - mi sono innamorato di questo ma posso vivere senza di esso)
  • Supporta macro reali per una metaprogrammazione avanzata (must-have assoluto)

Le due lingue principali con cui ho lavorato sono Boo e Nemerle, ma ho anche giocato con F #.

Principali reclami contro Nemerle: il compilatore ha un orribile report degli errori, l'implementazione è buggy da morire (compilatore e librerie), le macro possono essere applicate solo all'interno di una funzione o come attributi, ed è abbastanza pesante dal punto di vista della dipendenza (anche se non basta che sia un rompicapo).
Principali lamentele nei confronti di Boo: nessuna nidificazione di espressioni arbitrarie (dealbreaker), macro difficili da scrivere, nessuna definizione di operatore personalizzato (potenziale dealbreaker).
Principali lamentele contro F #: brutta sintassi, metaprogrammazione difficile da capire, licenza non gratuita (epic dealbreaker).

Quindi più ci penso, più penso a sviluppare la mia lingua.

Pro:

  • Ottieni l'esatta sintassi che voglio
  • Ottieni un tempo di risposta che sarà molto più veloce; difficile da quantificare, ma non sarei sorpreso di vedere una produttività degli sviluppatori 1,5x, soprattutto a causa delle infrastrutture di test che questo può consentire a determinati progetti
  • Posso facilmente aggiungere funzionalità personalizzate al compilatore per giocare bene con il mio runtime
  • Ottengo qualcosa che è progettato e funziona esattamente nel modo che desidero - per quanto possa sembrare NIH, questo mi renderà la vita più semplice

Contro:

  • A meno che non ottenga popolarità, rimarrò bloccato dall'onere della manutenzione. So che posso almeno convincere le persone di Nemerle, dal momento che penso che tutti vogliano qualcosa di più professionale, ma ci vuole un villaggio.
  • A causa della prima truffa, sono diffidente nell'usarlo in un ambiente professionale. Detto questo, sto già usando Nemerle e sto usando il mio compilatore modificato personalizzato poiché non lo mantengono affatto bene.
  • Se non guadagna popolarità, trovare gli sviluppatori sarà molto più difficile, a un punto che Paul Graham potrebbe anche non perdonare.

Quindi, in base a tutto ciò, qual è il consenso generale - è una buona idea o una cattiva idea? E forse più utile, ho perso qualche grande pro o contro?

Modifica: ho dimenticato di aggiungere l'esempio di nidificazione - ecco un caso in Nemerle: 

def foo = 
    if(bar == 5)
        match(baz) { | "foo" => 1 | _ => 0 }
    else bar;

Modifica n. 2: ho pensato che non sarebbe male dare un esempio del tipo di codice che verrà convertito in questa lingua se deve esistere (la sola risposta di S. Lott potrebbe essere sufficiente a spaventarmi dal farlo) . Il codice fa un uso intensivo della sintassi personalizzata (opcode,: =, quoteblock, ecc.), Annidamento delle espressioni, ecc. Puoi dare un buon esempio qui: qui .

È stato utile?

Soluzione

Purtroppo, non ci sono metriche o storie sulle lingue fallite. Solo lingue di successo. Chiaramente, i fallimenti sono più numerosi dei successi.

Su cosa baso questo? Due esperienze comuni.

  1. Una o due volte all'anno, devo sopportare una proposta per un prodotto / lingua / strumento / quadro che cambierà assolutamente tutto. La mia risposta è stata costante negli ultimi 20 anni circa. Fammi vedere qualcuno che ha bisogno di supporto e la mia azienda li supporterà. E quello è quello. Non avere più notizie da loro. Diciamo che ne ho sentito 25.

  2. Una o due volte all'anno, devo lavorare con un cliente che ha la tecnologia orfana. Ad un certo punto in passato, una programmazione intelligente ha creato uno strumento / framework / libreria / pacchetto che è stato utilizzato internamente per diversi progetti. Quindi quel programmatore è partito. Nessun altro è in grado di capire cosa dannatamente dannoso e vogliono che lo sostituiamo / riscriviamo. Purtroppo, non possiamo neanche capirlo, e la nostra proposta è di riscrivere da zero. E si lamentano del fatto che il loro genio abbia creato il set di app in un periodo di settimane, non ci possono volere mesi per riscriverle in Java / Python / VB / C #. Diciamo che ho scritto circa 25 di questo tipo di proposte.

Sono solo io, un consulente.

In effetti una situazione particolarmente triste era una società che l'intero portafoglio di software IT era stato scritto da un ragazzo intelligente con una lingua e strumenti privati. Non se n'era andato, ma si era reso conto che la sua lingua e il suo set di strumenti erano rimasti indietro rispetto ai tempi: lo stato dell'arte era passato, e non lo era stato.

E la mossa era - ovviamente - in una direzione inaspettata. La sua lingua e gli strumenti erano a posto, ma il mondo aveva iniziato ad adottare database relazionali e non aveva assolutamente modo di aggiornare la sua spazzatura per allontanarsi dai file flat. Era qualcosa che non aveva previsto. Anzi, era qualcosa che non poteva prevedere. [Non cadrai in questa trappola, vero?]

Quindi abbiamo parlato. Ha riscritto molte applicazioni in Plain-Old VAX Fortran (sì, questo è molto tempo fa.) E lo ha riscritto per usare semplicemente roba SQL relazionale semplice (Ingres, al momento.)

Dopo un anno di programmazione, avevano problemi di prestazioni. Mi hanno richiamato per rivedere tutte le fantastiche cose che avevano fatto nel sostituire il linguaggio casalingo. Purtroppo, avevano fatto il peggior progetto possibile di database relazionale. Peggiore possibile. Avevano preso le loro copie di file, unite, ordinate e quant'altro, e implementato ogni operazione di file system di basso livello usando SQL, duplicando le file del database a sinistra, a destra e al centro.

Era così impantanato nella sua visione privata del linguaggio perfetto, che non riusciva ad adattarsi a una nuova tecnologia relativamente comune e pervasiva.

Altri suggerimenti

Dico provaci.

  • Sarebbe una fantastica esperienza indipendentemente dal tempo che arriva alla produzione o meno.
  • Se esegui la compilazione in IL, non devi preoccuparti di non poter riutilizzare gli assembly compilati con C #
  • Se ritieni di avere lamentele valide sulle lingue che hai elencato sopra, è probabile che molti penseranno come te. Ovviamente, per ogni 1000 interessati potrebbero esserci 1 disposti ad aiutarti a mantenerlo, ma questo è sempre il rischio

Ma qui ci sono alcune cose da mettere in guardia:

  • Ottieni le tue specifiche linguistiche IN PIETRA prima dello sviluppo. Assicurati che tutte le funzioni linguistiche siano state individuate prima, anche cose che potresti desiderare solo in futuro. A mio avviso, C # sta lentamente cadendo nell'estensione "oh-just-one-more-language-extension" trappola che porterà al suo destino finale.
  • Assicurati di renderlo ottimizzato. Non so cosa sai già; ma se non lo sai, impara;) Nessuno vorrà una lingua che abbia una buona sintassi ma che funzioni lentamente quanto l'implementazione javascript di IE.

Buona fortuna: D

Quando ho iniziato la mia carriera nei primi anni '90, sembrava che ci fosse questa mania per tutti quelli che sviluppavano le proprie lingue interne. I miei primi lavori 3 riguardavano aziende che l'avevano fatto. Una società aveva persino sviluppato il proprio sistema operativo!

Per esperienza, direi che questa è una cattiva idea per i seguenti motivi:

1) Trascorrerai del tempo a eseguire il debug della lingua stessa oltre alla base di codice su di essa
2) Qualsiasi sviluppatore che assumerai dovrà seguire la curva di apprendimento della lingua
3) Sarà difficile attrarre e mantenere gli sviluppatori poiché lavorare in un linguaggio proprietario è un vicolo cieco per la carriera di qualcuno

Il motivo principale per cui ho lasciato quei tre lavori era perché avevano lingue proprietarie e noterai che non molte aziende seguono più questa strada :).

Un ulteriore argomento che vorrei sollevare è che la maggior parte delle lingue ha interi team il cui lavoro a tempo pieno è quello di sviluppare la lingua. Forse saresti un'eccezione, ma sarei molto sorpreso se riuscissi a eguagliare quel livello di sviluppo lavorando solo sulla lingua part-time.

  

Principali reclami contro Nemerle: The   il compilatore ha un'orribile segnalazione degli errori,   l'implementazione è buggy da morire   (compilatore e librerie), le macro   può essere applicato solo all'interno di una funzione   o come attributi, ed è abbastanza   pesante dipendenza (anche se non   basta che sia un rompicapo).

Vedo che il tuo post è stato scritto più di due anni fa. Ti consiglio di provare la lingua Nemerle oggi. Il compilatore è stabile. Non ci sono bug bloccanti per oggi. L'integrazione VS ha molti miglioramenti, inoltre c'è l'integrazione SharpDevelop.

Se gli dai una possibilità, non rimarrai deluso.

MAI MAI sviluppato la tua lingua.

Sviluppare la tua lingua è una trappola folle e, peggio ancora, ti limiterà a ciò che la tua immaginazione può fornire, oltre a richiedere che tu risolva il tuo ambiente di sviluppo e il vero programma che stai scrivendo.

I casi in cui ciò non si applica sono praticamente se sei Larry Wall, i ragazzi di AWK o parte di un consistente gruppo di persone dedicate a testare i confini della programmazione. Se ti trovi in ??una di queste categorie, non hai bisogno del mio consiglio, ma dubito fortemente che tu stia prendendo di mira una nicchia in cui non esiste un linguaggio di programmazione adatto per l'attività E le caratteristiche delle persone che svolgono l'attività.

Se sei intelligente come sembri (una probabile possibilità), il mio consiglio è di andare avanti e fare prima il design del linguaggio, iterarlo un paio di volte su di esso, chiedere ad alcuni compagni intelligenti di cui ti fidi in modo intelligente programmando comunità relative al linguaggio riguardo al progetto concreto che hai ideato e poi prendi la decisione.

Nel processo di creazione del progetto potresti capire che solo un rapido hack su Nemerle ti darebbe tutto ciò di cui hai bisogno, ad esempio. Molte cose possono accadere proprio quando si pensa seriamente a un problema, e la soluzione finale potrebbe non essere ciò che avevi in ??mente all'inizio del progetto.

Caso peggiore, sei bloccato con l'implementazione effettiva del progetto, ma a quel punto avrai la lettura e la maturità della prova e saprai con un alto grado di certezza che è stato un buon percorso da prendere.

Un consiglio correlato, inizia in piccolo, definisci le funzionalità di cui hai assolutamente bisogno e poi costruisci su di esse per ottenere il resto.

Scrivere la tua lingua non è un progetto facile ... Soprattutto uno da utilizzare in qualsiasi tipo di "impostazione professionale"

È una enorme quantità di lavoro, e dubiterei che tu possa scrivere la tua lingua e comunque scrivere tutti i grandi progetti che la usano - passerai così tanto tempo ad aggiungere funzionalità di cui hai bisogno, correzione di bug e roba generale per la progettazione del linguaggio.

Consiglierei fortemente di scegliere una lingua più vicina a ciò che si desidera e di estenderla per fare ciò di cui si ha bisogno. Non sarà mai esattamente quello che vuoi, ma rispetto al tempo che passerai a scrivere la tua lingua, direi che è un piccolo compromesso ..

Scala ha un compilatore .NET. Non conosco lo stato di questo però. È una specie di cittadino di seconda classe nel mondo della Scala (che è più focalizzato sulla JVM). Ma potrebbe essere un buon compromesso adottare il compilatore .NET invece di creare un nuovo linguaggio da zero.

Scala è un po 'debole nel reparto di meta-programmazione ATM. È possibile che la necessità di metaprogrammazione sia in qualche modo ridotta dalle altre funzionalità linguistiche. In ogni caso, non credo che nessuno sarebbe triste se si implementassero funzioni di metaprogrammazione per questo. Inoltre, è in arrivo un'infrastruttura plug-in del compilatore.

Penso che la maggior parte delle lingue non sarà mai adatta a tutti i conti.

Potresti voler combinare le tue 2 lingue preferite (nel mio caso C # e Scheme ) e usarle insieme .

Da un punto di vista professionale, questa probabilmente non è una buona idea.

Sarebbe interessante ascoltare alcune delle cose che ritieni di non poter fare nelle lingue esistenti. A quale tipo di progetti stai lavorando che non può essere realizzato in C #?

Sono solo curiosità!

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top