Se una lingua cambia rapidamente, è considerata una buona cosa?

Ho visto alcune lingue che cambiano rapidamente (ad esempio, ogni anno vengono migliorate) e alcune che vengono migliorate lentamente.

La mia domanda, se una lingua cambia rapidamente, è una cosa positiva o negativa per il programmatore? Ai programmatori piace imparare cose nuove nella lingua o preferiscono attenersi a ciò che già sanno?

se una lingua cambia rapidamente, questa è una cosa positiva o negativa per il programmatore?

Buona

• Le modifiche potrebbero aggiungere un po 'di zucchero sintetico che semplifica la scrittura del codice futuro con meno bug
• Le modifiche possono standardizzare un linguaggio comune / modello di progettazione per il quale i programmatori hanno dovuto implementarsi o fare affidamento su terzi.
• Le modifiche possono rendere più semplice l'integrazione con le tecnologie con cui la lingua viene generalmente utilizzata
• Le modifiche possono aiutare a prevenire errori comuni
• Le modifiche possono deprecare o eliminare pratiche di programmazione pericolose
• Le modifiche potrebbero includere utili aggiunte alla libreria standard del linguaggio per cose che un tempo dovevo implementare o fare affidamento su terze parti.

Cattivo

• Il linguaggio ha aggiunto complessità - le nuove funzionalità potrebbero non sempre giocare bene con le funzionalità legacy (ovvero la relazione tra C ++ e C)
• Il codice legacy potrebbe non essere aggiornato e potrebbe non funzionare più nella nuova versione della lingua senza aggiornamenti (Python 2.x -> 3.x)
• I compilatori e altri strumenti per la lingua devono essere aggiornati. Ora esistono potenzialmente più versioni.
• Le librerie di terze parti potrebbero non supportare la versione più recente della lingua
• Nonostante l'esistenza di uno standard, potrebbe essere necessario del tempo per trovare un modo standard / normale per implementare nuove funzionalità e definire alcuni dei casi più oscuri del loro comportamento

Ai programmatori piace imparare cose nuove nella lingua o preferiscono attenersi a ciò che già sanno?

Molti programmatori si divertono a soddisfare la loro curiosità giocando con le nuove funzionalità. Tuttavia, ciò non significa che le nuove funzionalità siano sempre appropriate nel codice di produzione. Questa è una decisione caso per caso che deve valutare i vantaggi delle nuove funzionalità rispetto al costo dell'aggiornamento nella specifica situazione.

Potrei divertirmi o divertirmi a conoscere le nuove funzionalità, ma alla fine quello che mi interessa davvero è fornire un prodotto utile a qualcuno. Devo scegliere il set di strumenti che sarà abbastanza moderno da avere ragionevole supporto e stabilità ma non così antico da non poter essere ragionevolmente produttivo.

I miglioramenti sono grandi ... se sono retrocompatibili .

C # lo fa bene. Aggiungono cose espressioni lamdba, miglior supporto per il multithreading, linq, ... Ma il tuo programma C # 2.0 di cinque anni funzionerà ancora bene senza bisogno di cambiamenti e può essere facilmente aggiornato a C # 4.0 senza bisogno di cambiamenti.

Imparare nuove cose è fantastico se ti consente di svolgere i tuoi compiti in un modo più semplice e veloce. Se passare un'ora a imparare significa risparmiare ore nello sviluppo, ne vale la pena.

Voglio miglioramenti regolari, ma non voglio che rompa una base di codice da 500 kloc e attivi un enorme "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 funzionalità che mancavano nelle versioni precedenti, ma cambiare le lingue in modo che sia di tendenza o semplicemente perché vuoi raggiungere un concorrente non è così buono.

Quando la lingua è stabile, nel tempo, gli sviluppatori smettono di concentrare gli sforzi sull'apprendimento della lingua perché l'avrebbero padroneggiata e inizieranno a concentrare i loro sforzi nel servire l'azienda con ciò che sanno. Il risultato è un progetto più breve, utenti finali felici e sviluppatori più orgogliosi!

Il cambiamento arriva anche con costi e tempi di apprendimento. Non tutti i datori di lavoro sono disposti a educare gli sviluppatori a nuove funzionalità. Questo aggiunge un onere significativo agli sviluppatori per allenarsi o no - Questo non è banale, i corsi specializzati possono essere $ 1500- $ 3500 ciascuno!

Il cambiamento continuo può bloccare gli sviluppatori nel software "legacy". Prendiamo il caso dello sviluppatore ASP che non ha riscontrato MVVM tra 2 anni o il caso di uno sviluppatore Windows Form che non ha appreso WPF. Questo blocco potrebbe danneggiare significativamente la carriera degli sviluppatori.

Gli straordinari, l'architettura del software in un'azienda diventa come un'insalata di giardino. Tutti i tipi di strumenti e versioni e trovi i progetti che iniziano a non fare altro che aggiornare il software da una versione all'altra senza alcun guadagno aziendale.

Non credo che ci sia una risposta esatta.

In generale, quando una lingua è relativamente giovane, c'è molta più libertà di apportare cambiamenti relativamente grandi relativamente rapidamente. Non c'è una grande base di codice esistente da rompere, quindi le persone sono generalmente molto più aperte alla sperimentazione.

Con l'invecchiamento della lingua, supponendo che arrivi a un utente sufficientemente ampio da interessare davvero a tutti, la base del codice esistente inizia a porre restrizioni sempre più rigide su quali modifiche possono essere apportate. Non solo c'è più codice che fa uso di più funzionalità, quindi è più difficile indovinare quali cambiamenti potrebbero violare il codice, ma le aspettative delle persone cambiano.

Solo per esempio, supponiamo che ci fosse circa lo stesso numero di persone che scrivevano Ruby e Fortran. Inoltre, supponiamo che ci fosse circa la stessa quantità di codice in entrambi. Direi che è abbastanza 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) sia molto più accettabile per gli utenti Ruby rispetto agli utenti Fortran come regola generale (almeno supponendo che lo vedessero come un miglioramento).

Penso che molto dipenda anche dalla percezione che la gente ha della lingua per cominciare. Le persone che scelgono una lingua perché è "all'avanguardia" hanno molte più probabilità di tollerare cambiamenti importanti che interrompono un sacco di codice esistente, se è quello che serve per mantenerlo all'avanguardia.

Un altro fattore è la dimensione e l'aspettativa di vita dei progetti a cui la lingua è destinata. Un linguaggio che si rivolge a progetti relativamente piccoli o che conosciamo in anticipo ha una breve aspettativa di vita (ad esempio, un'interfaccia utente Web) può cavarsela con la rottura delle cose relativamente frequentemente, perché è improbabile che molte persone continuino a utilizzare la stessa base di codice per, diciamo, 10 anni in ogni caso. Un linguaggio (ad es. C ++ o Java) che si rivolge di più a progetti più grandi e di lunga durata che potrebbero richiedere, per esempio, 5 anni per arrivare a una versione iniziale, potrebbe essere in uso regolare (e sviluppo continuo) per tre o quattro decenni, ovviamente richiedono una grande stabilità di più.

Ho avuto un ragazzo che mi ha detto che gli piace il suo C ++ e che rimarrà così. Non gli interessa o non ha interesse per D, non vuole conoscere né usare C #. Ha imparato java perché ha dovuto per i molti progetti che doveva fare e apparentemente 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 (asincrone e tutte) e non ha usato le parole chiave astratte o gli attributi usati.

Sto semplicemente dicendo che la maggior parte delle persone NON CURA

Ora gli effetti dell'aggiornamento si stanno rompendo (per le librerie o il codice compilato) la gente si preoccuperà.

Risponderò per C # (ma questa analisi può essere applicata anche a Scala):

La modifica di questa funzione causa alcuni problemi quando ti avvicini a uno "stile" di una lingua:

Nel 2011, C # può fare molte cose diverse, e questo è buono. Sfortunatamente ha due paradigmi diversi (se non di più):

• OOP
• Funzionale (pensa alle funzioni lambda e LINQ)

Diversi stili di controllo del tipo

• Digitazione dinamica
• Digitazione statica

Non è sempre chiaro quando si desidera utilizzare l'uno o l'altro.

Penso che dipenda davvero dalla lingua e dai seguenti contenuti della lingua. Ad esempio, penso che se C # e Java iniziassero a far apparire i cambiamenti con un ritmo più rapido di quello che verrebbero accettati (fintanto che sono retrocompatibili come Carra ha detto). Tuttavia, se la lingua non ha ancora acquisito trazione e sta ancora cambiando rapidamente, so che non mi preoccuperei, poiché c'è una possibilità che ciò che provo ad imparare oggi sia 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) passarlo semplicemente.