Scelta sistematica di un linguaggio di programmazione [chiuso]

Sto cercando una metodologia per scegliere una lingua. Non sto chiedendo opinioni sulle lingue. Mi è stato affidato il compito di confrontare la lingua corrente del nostro negozio con quella disponibile. Siamo un negozio di sviluppo web tra l'altro.

Il nostro CEO vorrebbe un white paper completo su tutte le lingue basate sul web disponibili, di quale lingua madre sono derivati ​​(ad es. Jsp proviene da Java che proviene da c / c ++). Ho bisogno di creare una matrice con tutti i fattori chiave di una determinata lingua e le carenze di quella determinata lingua. Il linguaggio è limitato dalla piattaforma, è progettato per la programmazione funzionale, procedurale o OO o può essere utilizzato con qualsiasi paradigma di programmazione?

Devo anche avere informazioni meno tecniche, come la dimensione del pool di talenti per una determinata lingua e lo stipendio mediano in quel pool. In che modo il mercato vedrà la nostra scelta?

Abbiamo iniziato a cercare un consulente per aiutarci a comprendere tutte queste cose, ma quello che abbiamo scoperto è che la maggior parte dei consulenti proviene da un background di sviluppo e spesso sembra che la risposta sia " xxx è la lingua migliore perché è quella che io ho usato di più negli ultimi n anni e non mi ha mai deluso. Potresti integrarlo con yyy per il front-end e utilizzare la libreria zzz "

Mi sento sopraffatto da questo compito e mi sento come il miglior modo di agire, dato quello che il nostro CEO sta cercando, è guardare nel mondo accademico e assumere un professore senza esperienza di sviluppo reale per entrare e "insegnarci" su tutte le lingue possibili.

Qualcun altro ha dovuto affrontare questo esercizio? Se hai, puoi condividere i passaggi e / o la metodologia che hai usato per completare il processo?

@FrustratedWithFormsDesigner ha accennato a questo sopra, sarò più schietto: sei stato accusato di un compito costoso ma inutile.

Ho il sospetto che il CEO sia alla ricerca di prove inconfutabili e obiettive a supporto della sua scelta della lingua. 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 ci fosse un linguaggio ideale, tutti lo userebbero al posto di quei linguaggi "oggettivamente" difettosi. Inoltre rivela un grado di microgestione che dovrebbe essere la provincia degli ingegneri che dovranno farlo funzionare. Erlang potrebbe essere il "oggettivamente il migliore" ma se nessuno lo sa, aggiungere un costo di avviamento di 6 mesi / ingegnere e altri 6 mesi / ingegnere per acquisire competenza.

Dal momento che non ho il tuo lavoro, non sono preoccupato di perderlo, anche se puoi. Darei al CEO un documento sulla tesi di Church-Turing. Vorrei quindi riunirmi con gli ingegneri senior e ottenere la loro opinione non rigorosa e non obiettiva su cosa dovrebbe essere usato e dire al CEO che è quello che dovresti usare. In cambio prometti che gli ingegneri terranno fuori le riunioni del consiglio di amministrazione, i CFO, i metodi di contabilità, la selezione dei vicepresidenti e così via. C'è un motivo per cui siamo specializzati e non ha più posto nelle preferenze ingegneristiche di te nel suo dominio.

Alcune ampie pennellate da considerare:

Popolarità linguistica

Questo in realtà non dovrebbe importare, perché la popolarità non equivale necessariamente alla produttività, all'espressività o ad 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 una lingua popolare.
2. È più facile trovare strumenti e librerie in una lingua popolare.
3. I decisori non comprendono i compromessi linguistici, quindi prenderanno le decisioni sicure ("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 alcuni linguaggi sono più adatti per determinati domini problematici rispetto ad altri. Se stai scrivendo applicazioni web, probabilmente graviterai su linguaggi e strumenti 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 graviterai verso linguaggi che abbracciano paradigmi funzionali .

E, naturalmente, c'è tutto in mezzo. Molte lingue supportano più paradigmi e alcuni modelli software esistono solo per superare i limiti in quelle lingue che mancano di determinate caratteristiche o paradigmi.

Espressività e produttività

Alcune lingue sono più espressive di altre. Ciò che può essere scritto in una lingua usando mille righe di codice può essere scritto in una lingua più espressiva usando cento righe 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 utilizzati per scrivere applicazioni line-of-business sono cerimonie. Questa cerimonia, pur costando tempo e sforzi per svilupparsi, fornisce anche una struttura visibile che altrimenti non sarebbe facilmente evidente in un linguaggio più espressivo. Permette alle persone con meno esperienza di quante non avrebbero altrimenti bisogno di lavorare sul codice con una quantità ridotta di rischio.

L'era di più lingue

Concluderò affermando che il desiderio di decidere su una sola 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 l'attività che viene utilizzata. Alcuni domini problematici (come la logica del browser Web o l'accesso al database) richiedono lingue specifiche.

Ci sono ragioni commerciali per scegliere una lingua e ragioni ingegneristiche per scegliere una lingua, e le due cose non sempre si incontrano. Lanciare per motivi accademici probabilmente peggiorerà le cose. Dubito che un professore sarà in grado di aiutarti nel modo che ti serve.

I fatti sulle origini e le caratteristiche di una lingua sono piuttosto facili da trovare. Probabilmente potresti passare una giornata su Wikipedia per riempire la maggior parte di questo. La dimensione del pool di talenti e lo stipendio sono più difficili, perché la maggior parte delle persone non si considera programmatori di una sola lingua. Le aziende che usano lingue meno popolari come Scala si aspettano praticamente di assumere buoni programmatori generali che non hanno esperienza specifica della lingua. A giudicare da alcune presentazioni che ho visto, quella strategia sembra aver funzionato bene.

Anche conoscere i fatti ti lascia ancora con una scelta piuttosto soggettiva. Il tuo CEO lo vorrà ridotto a una metrica approssimativa qualcosa come dollari per funzione. Per ottenere un'immagine precisa, dovrai fare alcuni prototipi, quindi parlare di quanto sia stato facile imparare, quanto è stato veloce scrivere un prototipo dopo aver appreso le basi, quanto pensi che sarebbe facile da mantenere e in che misura ritieni applicabile al tipo di lavoro che svolgi in genere.

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

Ecco un elenco approssimativo di categorie di back-end:

• Microsoft. (Può avere delle sottocategorie. Non ne so nulla.)
• OOP dei pesi massimi, come Drupal.
• OOP leggero, come una bottiglia di pitone.
• Gioca / solleva / scalatra usando Scala.
• Gioca / solleva usando Java.
• Primaverile.
• Struts-like.
• Rails-like.
• Haskell-based.
• Node.js

Sulla parte frontale:

• JavaScript in stile OOP
• JavaScript in stile funzionale, come con Underscore
• JavaScript in stile reattivo, come con Bacon
• Google Web Toolkit
• Olmo

Trascorrere un giorno o due in ciascuna 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 escluderne alcuni più rapidamente in base alla cultura o all'esperienza della tua azienda.

Dal momento che si tratta di un rapporto commerciale, vorrei anche dedicare del tempo a cercare su google cose come "Che lingua usa <azienda>", sostituendo varie aziende che ammiri. Molti di loro hanno scritto dei loro white paper sul perché hanno fatto scelte linguistiche specifiche, che farebbero ottimi riferimenti da includere.

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

Se $ A è inferiore a $ B, interrompi.

Se le tue carenze conosciute superano il costo del cambiamento (e questo è un grande if!), Analizza in dettaglio le carenze e inizia a cercare un linguaggio / ambiente di sviluppo / cambiamenti del processo di sviluppo che li risolva, uno che non introdurrà altri problemi più costosi.

Ad essere onesti, a meno che tu non stia attualmente cercando di sviluppare app Web in Fortran, l'unico impatto che la lingua che utilizzerai avrà è sul costo degli appaltatori che utilizzi per colmare le lacune. Il flusso principale e i linguaggi / strumenti / processi di sviluppo maturi hanno già risolto la maggior parte dei problemi che probabilmente affronterai laddove gli strumenti più caldi, più nuovi e più sexy arrivano con i formatori 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 li affronti completamente.

Tuttavia, se la redditività non è l'obiettivo principale qui, è necessario tener conto dello 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.