Scelta sistematica di una lingua di programmazione [chiusa]

@FrustratedWithFormsDesigner accennato a quanto sopra, sarò più schietto: ti è stato addebitato un compito costoso ma inutile.

Sospetto che l'amministratore delegato stia cercando prove oggettive e inconfutabili che supporteranno la sua scelta del linguaggio. Il problema è che la preferenza del linguaggio è caricata con troppi fattori soggettivi ed estrinseci perché il white paper sia significativo e tanto meno utile.

In altre parole, se esistesse un linguaggio ideale, tutti lo userebbero invece di quelle lingue "obiettivamente" difettose. Indica anche un grado di microgestione che dovrebbe essere la provincia degli ingegneri che dovranno farlo funzionare. Erlang potrebbe essere il "meglio oggettivamente", ma se nessuno lo sa, aggiungi un costo di avvio di 6 mesi / ingegnere e 6 mesi / ingegnere per acquisire competenze.

Dato che non ho il tuo lavoro, non sono preoccupato di perderlo, sebbene tu possa farlo. Darei all'Amministratore delegato un documento sulla tesi della Chiesa fisica-Turing. Poi mi trovo con gli ingegneri senior e ottengo il loro parere non rigoroso, non oggettivo su cosa dovrebbe essere usato e dico al CEO che è quello che userete. In cambio, prometterai che gli ingegneri manterranno le riunioni del consiglio direttivo, i CFO, i metodi di contabilità, la selezione dei VP e così via. C'è una ragione per cui ci specializziamo e non ha più posto nelle preferenze di ingegneria di te nel suo dominio.

Alcune ampie pennellate da considerare:

Popolarità della lingua

Questo in realtà non dovrebbe importare, perché la popolarità non è necessariamente uguale a produttività, espressività o qualcuna delle altre qualità linguistiche che contano di più, ma questa considerazione spesso supera tutte le altre considerazioni perché:

1. È più facile trovare sviluppatori di software in un linguaggio popolare.
2. È più facile trovare strumenti e librerie in un linguaggio popolare.
3. I decision maker non comprendono i compromessi linguistici, quindi prenderanno la decisione sicura ("molte aziende usano questo linguaggio, quindi deve essere buono").

Applicabilità al dominio problematico

Qualsiasi programma può essere scritto in qualsiasi linguaggio di programmazione completo di Turing, ma alcune lingue sono più adatte per determinati domini problematici di altri. Se stai scrivendo applicazioni web, probabilmente andrai verso linguaggi e strumenti che sono adatti a questo, e molto probabilmente saranno linguaggi orientati agli oggetti.

D'altra parte, se stai per scrivere un software basato principalmente sulla ricerca o sulla matematica, probabilmente ti aggirerai verso linguaggi che abbracciano paradigmi funzionali .

E, naturalmente, c'è tutto nel mezzo. Molte lingue supportano più paradigmi e alcuni modelli software esistono esclusivamente per superare i limiti in quei linguaggi che mancano di determinate funzionalità o paradigmi.

Espressività e produttività

Alcune lingue sono più espressive di altre. Quello che può essere scritto in una lingua usando mille righe di codice può essere scritto in un linguaggio più espressivo usando cento linee di codice. Il compromesso è che le cento righe di codice sono probabilmente scritte in un linguaggio meno popolare, da persone con maggiore esperienza.

Molte delle linee di codice presenti nei linguaggi orientati agli oggetti usati per scrivere applicazioni line-of-business sono cerimonie. Questa cerimonia, pur costando tempo e sforzi per lo sviluppo, fornisce anche una struttura visibile che altrimenti non sarebbe facilmente evidente in un linguaggio più espressivo. Permette alle persone con meno esperienza di quelle che altrimenti avrebbero bisogno di lavorare sul codice con una minore quantità di rischio.

L'era delle lingue multiple

Concluderò affermando che il desiderio di decidere su una singola lingua può essere un falso dilemma. Le applicazioni oggi sono spesso scritte, non in una, ma in molte lingue. Ogni lingua ha i suoi punti di forza e (in teoria) è specificamente progettata per il compito che viene utilizzato. Alcuni domini problematici (come la logica del browser Web o l'accesso al database) richiedono lingue specifiche.

Ci sono ragioni di business per scegliere una lingua, e ci sono ragioni di ingegneria per scegliere una lingua, e le due cose non sempre si incontrano. Il lancio di ragioni accademiche potrebbe peggiorare le cose. Dubito che un professore sarà in grado di aiutarti nel modo in cui ti serve.

I fatti relativi alla discendenza e alle caratteristiche di una lingua sono piuttosto facili da trovare. Probabilmente potresti passare un giorno su wikipedia per riempire la maggior parte di questo. Le dimensioni e lo stipendio del pool di talenti sono più difficili, perché la maggior parte delle persone non si considera un programmatore a lingua singola. Le aziende che utilizzano linguaggi meno conosciuti come Scala si aspettano di assumere dei buoni programmatori generali che non hanno esperienza specifica per la lingua. A giudicare da alcune presentazioni che ho visto, questa strategia sembra aver funzionato bene.

Anche conoscere i fatti ti lascia ancora una scelta piuttosto soggettiva. Il tuo CEO vorrebbe che si riducesse a una metrica approssimativa, qualcosa come i dollari per caratteristica. Per ottenere un'immagine accurata, dovrai fare alcuni prototipi, poi parlare di quanto è stato facile imparare, quanto è stato veloce scrivere un prototipo una volta apprese le nozioni di base, quanto sarebbe stato facile mantenerlo e quanto ampiamente applicabile pensi che sarebbe il tipo di lavoro che fai tipicamente.

Piuttosto che cercare di coprire tutte le lingue, cercherò di ottenere rappresentanti dai diversi paradigmi di programmazione e tipi di framework e implementerò un prototipo in ciascuno di essi.

Ecco un elenco approssimativo delle categorie di back-end:

• Microsoft. (Potrebbe avere sottocategorie. Non ne so nulla.)
• OOP pesante, come Drupal.
• OOP leggero, come il flacone di pitone.
• Riproduci / solleva / scalatra usando Scala.
• Riproduci / solleva utilizzando Java.
• primaverile.
• Struts-like.
• Rails-like.
• Haskell-based.
• Node.js

Sul front-end:

• JavaScript in stile OOP
• JavaScript in stile funzionale, come con Underscore
• JavaScript in stile reattivo, come con bacon
• Google Web Toolkit
• Elm

Trascorrere un giorno o due su ogni categoria, implementando un semplice prototipo, ti richiederebbe un paio di mesi, dopo di che avresti un'idea molto migliore dei punti di forza e di debolezza di ciascuno. Forse potresti escludere un po 'più rapidamente in base alla cultura o all'esperienza della tua azienda.

Poiché si tratta di un rapporto di lavoro, vorrei anche prendere un po 'di tempo su googling come "Che lingua fa < azienda > usa", sostituendo varie società che ammiri. Molti di loro hanno scritto dei white paper sul perché hanno fatto scelte linguistiche specifiche, il che renderebbe eccellenti riferimenti da includere.

Identifica e costa le carenze inerenti al processo di sviluppo esistente come $ A. Identificare il costo del passaggio a qualsiasi altro processo di sviluppo come $ B.

Se $ A è inferiore a $ B, fermati.

Se le tue carenze conosciute superano il costo del cambiamento (e questo è un grande se!) poi analizza le carenze in dettaglio e inizia a cercare un cambio lingua / ambiente di sviluppo / processo di sviluppo che li indirizzi, uno che non introdurrà altro problemi costosi.

Per essere onesti, a meno che tu non stia attualmente cercando di sviluppare applicazioni web in Fortran, l'unico impatto che avrà la lingua che usi avrà il costo degli appaltatori che usi per colmare le lacune. Il flusso principale e i languges / strumenti / processi di sviluppo maturi hanno già risolto la maggior parte dei problemi che probabilmente affronteranno dove gli strumenti più caldi, nuovi e più sexy vengono forniti con i trainer e gli appaltatori più costosi, ma le soluzioni meno mature. E se hai delle carenze che giustificano un tale cambiamento, è improbabile che la tua scelta della lingua sia completamente indirizzata a loro.

Tuttavia, se la redditività non è l'obiettivo principale qui, allora devi considerare lo stigma di essere considerato vecchio stile contro i complimenti di essere all'avanguardia. Chiedi al tuo capo i valori in dollari da utilizzare per questa parte dell'equazione.