Ho visto alcune lingue che cambiano rapidamente (voglio dire che sono migliorate ogni anno ad esempio) e altre che sono migliorate lentamente.
La mia domanda, se una lingua cambia rapidamente, è una cosa buona o cattiva per il programmatore? I programmatori amano imparare cose nuove nella lingua o preferiscono attenersi a ciò che già sanno?
if a language changes quickly is this a good thing or a bad thing for the programmer?
Buona
Bad
Do programmers like to learn new thing in the language or do they prefer to stick with what they already know?
Molti programmatori apprezzano la loro curiosità giocando con le nuove funzionalità. Tuttavia, ciò non significa che le nuove funzionalità siano sempre appropriate nel codice di produzione. Si tratta di una decisione caso per caso che deve valutare i vantaggi delle nuove funzionalità rispetto al costo dell'aggiornamento nella propria situazione specifica.
Potrei divertirmi o divertirmi a conoscere nuove funzionalità, ma alla fine della giornata quello che mi interessa davvero è consegnare un prodotto utile a qualcuno. Devo scegliere il set di strumenti che sarà abbastanza moderno per avere supporto e stabilità ragionevoli, ma non così antico da non poter essere ragionevolmente produttivo.
I miglioramenti sono grandi ... se sono retrocompatibili .
C # lo fa bene. Aggiungono le espressioni lamdba, un migliore supporto per il multithreading, linq, ... Ma il tuo programma C # 2.0 di cinque anni funzionerà ancora bene senza bisogno di modifiche e può essere facilmente aggiornato a C # 4.0 senza bisogno di modifiche.
Imparare nuove cose è fantastico se ti consente di svolgere le tue attività in un modo più semplice e rapido. Se trascorrere un'ora di apprendimento significa risparmiare ore in termini di sviluppo, ne vale la pena.
Voglio miglioramenti regolari, ma non voglio che rompa un codice di 500 kloc & innescare un massiccio "progetto di aggiornamento" solo per far funzionare il codice come fa con la versione precedente.
La stabilità linguistica è un must per le aziende e per gli sviluppatori. I cambiamenti nella lingua sono ben accetti se risolvono problemi o introducono caratteristiche che mancavano nelle versioni precedenti, ma cambiare linguaggio in modo che sia di moda o semplicemente perché vuoi raggiungere un concorrente non è un granché.
Quando la lingua è stabile, nel tempo, gli sviluppatori smettono di focalizzare gli sforzi sull'apprendimento della lingua perché l'hanno padronanza e iniziano a concentrare i loro sforzi nel servire il business con ciò che sanno. Il risultato è un progetto più breve, utenti felici e sviluppatori più orgogliosi!
Il cambiamento arriva anche con i costi e i tempi di apprendimento. Non tutti i datori di lavoro sono disposti a educare gli sviluppatori a nuove funzionalità. Ciò aggiunge un notevole onere agli sviluppatori di allenarsi da sé o altrimenti - Questo non è banale, i corsi specializzati possono essere $ 1500- $ 3500 ciascuno!
Il cambiamento continuo può bloccare gli sviluppatori nel software "legacy". Prendiamo il caso di uno sviluppatore ASP che non ha intercettato MVVM tra 2 anni o il caso di uno sviluppatore Windows Form che non ha appreso WPF. Questo blocco potrebbe danneggiare in modo significativo la carriera degli sviluppatori.
Overtime, l'architettura del software in un'azienda diventa un'insalata da giardino. Tutti i tipi di strumenti e versioni e trovi progetti che non fanno altro che aggiornare il software da una versione all'altra senza alcun guadagno di business.
Non penso che ci sia una risposta giusta.
In generale, quando una lingua è relativamente giovane, c'è molta più libertà di fare cambiamenti relativamente grandi in tempi relativamente brevi. Non c'è una grande base di codice esistente da rompere, quindi le persone sono generalmente molto più aperte alla sperimentazione.
Man mano che il linguaggio invecchia, supponendo che entri in un utente abbastanza vasto per cui qualcuno possa davvero preoccuparsi, la base del codice esistente inizia a porre restrizioni più stringenti e più strette su quali modifiche possono essere apportate. Non solo c'è più codice che fa uso di più funzioni, quindi è più difficile indovinare quali cambiamenti potrebbero infrangere il codice, ma le aspettative delle persone cambiano.
Per esempio, supponiamo che ci fosse lo stesso numero di persone che scrivono Ruby e Fortran. Inoltre, supponiamo che ci fosse circa la stessa quantità di codice in entrambi. Direi che è molto probabile che un cambiamento che ha rotto esattamente la stessa percentuale di ciascuno (e in un modo che ha richiesto lo stesso lavoro per correggere) sarebbe un lotto più accettabile per gli utenti di Ruby rispetto agli utenti di Fortran come regola generale (almeno supponendo che lo vedessero come un miglioramento).
Penso che molto dipenda anche dalla percezione della lingua da parte delle persone. Le persone che scelgono una lingua perché è "all'avanguardia" hanno molte più probabilità di sopportare cambiamenti importanti che infrangono un sacco di codice esistente, se è quello che serve a mantenere è all'avanguardia.
Un altro fattore è la dimensione e l'aspettativa di vita dei progetti per i quali la lingua è destinata. Un linguaggio che si rivolge a progetti relativamente piccoli oa quelli che conosciamo in anticipo hanno una breve aspettativa di vita (ad esempio un'interfaccia utente web) può farla franca relativamente spesso, perché è improbabile che molte persone continuino a utilizzare lo stesso codice base per, diciamo, 10 anni in ogni modo. Un linguaggio (ad es., C ++ o Java) che si rivolge di più a progetti più grandi e di più lunga durata, che possono richiedere, per esempio, 5 anni per ottenere una versione iniziale, può essere in uso regolare (e sviluppo continuo) per tre o quattro decenni. un grande migliora la stabilità.
Ho avuto un ragazzo che mi ha detto che gli piace il suo C ++ e che rimarrà in questo modo. Non gli importa o ha interesse per D, non vuole sapere né usare C #. Ha imparato java perché aveva a che fare con i molti progetti che doveva fare e, a quanto pare, fa un buon lavoro nelle lingue che conosce
Un altro ama C # e non conosce tutte le parole chiave o conosce le librerie .NET 4 (asincrona e tutte) e non ha usato le parole chiave astratte o gli attributi usati.
Sto semplicemente dicendo che molte persone NON FANNO CURA
Ora gli effetti dell'aggiornamento si stanno interrompendo (per le librerie o il codice compilato) le persone si prenderanno cura di loro.
Risponderò per C # (ma questa analisi può essere applicata anche a Scala):
Questa modifica delle caratteristiche causa alcuni problemi quando ti stai avvicinando a uno "stile" di una lingua:
Nel 2011, C # può fare molte cose diverse, e questo è buono. Sfortunatamente ha due diversi paradigmi (se non di più):
Diversi tipi di controllo dei tipi
Non è sempre chiaro quando vuoi usarne uno o l'altro.
Penso che dipenda veramente dalla lingua e dalla lingua che segue. Per esempio, penso che se C # e Java iniziassero a saltare le modifiche in un ritmo più rapido che sarebbero state accettate (a patto che siano compatibili all'indietro come Carra ha detto). Tuttavia, se la lingua non ha ancora ottenuto trazione e sta ancora cambiando rapidamente, so che non mi preoccuperei di farlo poiché c'è una possibilità che quello che cerco di imparare oggi sarà totalmente diverso da quello che è uscito in 6 mesi e dal momento che la lingua è nuova / impopolare, non sarebbe dannoso per me (leggi: la mia carriera) per me solo passarci sopra.
Leggi altre domande sui tag programming-languages