Di solito non puoi scegliere una lingua per lavoro. Non c'è abbastanza tempo per impararlo, padroneggiarlo, e fare lo stesso per le sue tecniche di confezionamento, il suo ecosistema di moduli e programmatori disponibili, le sue stranezze di debugging e così via. Per non parlare dell'economicità degli investimenti in strumenti, apprendimento e tempo di accelerazione.
Quindi di solito le scelte linguistiche sono basate su "Cosa so?" e "Qual è la cosa più vicina che conosco al lavoro che viene considerato?" Solo raramente incontriamo veramente a base zero , greenfield , foglio di carta pulito decisioni. Le tue abilità preesistenti e il tuo bagaglio devono essere presi in considerazione.
Ma occasionalmente arriviamo ad aggiungere un altro linguaggio / ambiente / approccio al nostro skillset, o modernizzare / riconsiderare quali strumenti stiamo usando in un campo che già conosciamo. Quindi abbiamo una decisione molto meno vincolata. Alcune considerazioni comuni per eliminare le possibilità:
-
Grado di Differenza Se fossi un programmatore Perl professionale (cioè per un linguaggio pragmatico, dinamico, solitamente a thread singolo), potrei decidere di passare a Python o Ruby (altro lingue dinamiche e pragmatiche). Sono molto meno propenso ad abbracciare con tutto il cuore linguaggi come OCaml e Haskell che sono funzionali, tipizzati staticamente, spesso concentrati su strutture dati immutabili, richiedono vaste programmazioni meta / concettuali, ecc. Alcuni potrebbero, come un esercizio di "stretching". Ma la maggior parte delle persone e delle organizzazioni considera "turni adiacenti", non "cambia tutto in una volta" i turni.
-
Popolarità, comunità e traiettoria presunta Le persone sono creature sociali. Anche la scelta di lingue / ambienti è un investimento. Quindi tendiamo a voler passare a luoghi che sono popolari, che hanno comunità forti e solidali, in cui avvengono cambiamenti e innovazioni entusiasmanti e che sembrano essere "l'onda del futuro". Non importa quanto amo Smalltalk, ad esempio; non è l'onda del futuro, non ha una grande comunità, ecc. (Scusa, Smalltalkers! Lo adoro anche io!) Invece, sceglierei molto più facilmente Ruby o un'altra lingua ispirata a Smalltalk, piuttosto che Smalltlak in sé. Vedete questo "andare dove si stanno formando comunità vibranti" dinamiche (favorendo artisti come CoffeeScript, Go, Rust, Scala ...).
-
Approccio e competenze Nonostante decenni di obiettivi mirati a questo obiettivo, non esiste una lingua che sia la migliore in tutti i posti di lavoro. Le lingue che cercano di estendersi da sistemi e computazioni integrate fino alla logica di business astratti tendono a finire come un brutto scherzo. (Guardandoti PL / I, Ada e C ++! Scusa ai loro sostenitori!) Quindi, se stai provando a fare lavori integrati o di sistema, tenderesti a scegliere un linguaggio C, D, Go, Rust o simile con caratteristiche, prestazioni e comunità particolarmente adatte. Potresti cercare di "allungare" i confini normali. Esistono buoni esempi, ad es., Di Java, JavaScript e Python utilizzati nel lavoro embedded, o simili a Python nei server. Ma non imposterete il core del vostro prossimo sistema operativo in Perl, né il vostro prossimo server altamente thread in Python, Ruby o COBOL. C'è una ragione per cui i linguaggi e i sistemi di massimo livello sono ancora, fino ad oggi, implementati in C e simili.
Quindi, in sintesi, ci sono molte, molte ragioni per cui puoi scartare le scelte linguistiche, ma la loro distanza logica e culturale dalle tue attuali competenze; la loro relativa popolarità, comunità e traiettoria; e la loro "zona di competenza" è diversa dai lavori su cui vuoi focalizzarti - quelle sono le principali forze di esclusione.