Fattori di accettazione

Direi una combinazione di varie cose, ma non penso che siano tutte necessarie. Alcune lingue considerate mature oggigiorno chiaramente non soddisfano alcune di queste.

Direi una combinazione di:

• Tooling:
  • mainline: Almeno una suite di strumenti "ufficiale" o ampiamente accettata (di fatto o raccomandata dal fornitore / supportata) (compilatore, interprete, vm, editor).
  • alternativa : alcune alternative stabili e non stabili degli strumenti di cui sopra (varianti chiuse o open source, varianti gratuite o commerciali, estensioni, ecc ...).
• Comunità: un gruppo attivo , ma non necessariamente grande di follower e collaboratori.
• Riconoscimento:
  • Qualche grado di riconoscimento e utilizzo da parte di alcuni attori industriali (anche se in una nicchia).
  • Qualche grado di riconoscimento nella cultura popolare (anche se in una nicchia).

Su Fama, Riconoscimento e Maturità

Si noti che qui il differenziatore ha i validatori di criteri forti e attivi, non numerosi o numerosi. Per chiarire, considera questi esempi molto diversi:

• Ruby è stato per molto tempo un linguaggio con un ampio supporto alla comunità, un'implementazione ufficiale di riferimento e così via, ma potrebbe difficilmente essere considerato maturo fino a quando non ha appianato alcuni dei suoi spigoli. Era famoso prima di essere maturo.

• D'altra parte, alcune lingue un tempo molto diffuse (COBOL, FORTRAN ...) sono ora meno visibili, ma sono ancora mature in tutti i sensi. Erano una volta famosi e maturi.

• Inoltre, alcune lingue di nicchia sono a mio avviso decisamente mature, nonostante la loro piccola (ma consolidata) penetrazione nel mercato. Considera Oberon o Limbo. Sono maturi ma non sono mai diventati famosi. Gli altri, come R, sono relativamente famosi in quanto le loro "nicchie" non sono proprio delle nicchie (mi infastidiscono quando la gente chiama cose come Scala o Clojure "lingue di nicchia", che sicuramente non lo sono), sebbene il loro campo di applicazione non sia esattamente quello che chiameresti mainstream.

Stabilità

Che cosa è comunque stabile? È abbastanza relativo ...

• Compliance?
  • Allo standard (se ce n'è uno)?
  • a un'implementazione di riferimento (se ce n'è una)?
• Numero di bug? (Difficilmente una buona misura)
• Utilizzare in ambienti critici?

In generale, la stabilità significa semplicemente che non mi sorprendo quotidianamente quando faccio il mio lavoro medio usando il toolkit del linguaggio, e posso ottenere risposte definitive su cosa dovrebbe o non dovrebbe accadere quando cerco di fare qualcosa con il linguaggio e il suo toolkit, sia che si tratti del build-time o del runtime dei miei programmi.

Ma la stabilità per chi scrive app per smartphone e stabilità per chi scrive sistemi medici o avionici è un tipo diverso di uccello.

In realtà ho avuto la stessa meraviglia di qualche anno fa. Allora, ho deciso che un linguaggio è maturo (cioè buono per risolvere problemi di tipo x) se ha la maggior parte delle funzionalità necessarie per risolvere quel problema. In altre parole, quanti degli specifici strumenti per la risoluzione dei problemi devo creare me stesso rispetto a quanti già vengono con la lingua. Come per il tuo commento sto rimuovendo l'esempio specifico della lingua e lo sostituisco con un linguaggio agnostico:

Fondamentalmente pensavo che un linguaggio con un sacco di librerie "helper" e "utility" fosse più maturo di quello in cui alcune di quelle non esistevano (e in cui avrei dovuto scriverle) o qualcosa di simile a loro - me stesso)

Sto parlando di tutto questo in passato perché in questi giorni ho praticamente abbandonato quel modo di pensare e penso alla maturità di una lingua più simile a questa:

• quanto è strong la community per quella lingua. Quanti documenti, libri, esempi pertinenti ci sono. Questo è importante, perché puoi avere lingue che sono molto belle e che potrebbero essere più adatte per qualche compito specifico di altre, ma che sono scarsamente documentate, in modo da non vedere mai i loro vantaggi.

• prestazioni. Per una determinata attività e una determinata implementazione x, la lingua in cui tale implementazione verrà eseguita più velocemente è più matura. Sì, questa è un'area molto grigia e per la maggior parte delle lingue e delle piattaforme è difficile fare il confronto. Tuttavia per alcune lingue e piattaforme è abbastanza semplice vedere quale out-performs quale. Per alcuni tipi di problemi questo è molto importante.

• bug. Oh si. Non ci avrei mai pensato prima di averlo visto con i miei occhi. Non darò alcun esempio perché non voglio sembrare come se stessi colpendo una lingua o l'altra, ma ci sono lingue là fuori (beh, più precisamente, ambienti di compilazione e run-time per certe lingue) che sono molto buggy, al punto in cui non puoi più fidarti e stimare come funzionerà qualcosa. Per me la maturità di una lingua cala pesantemente quando questo è il caso.

I motivi per cui ho cambiato il modo in cui penso a una lingua più matura sono:

• prima di tutto, il fatto che una lingua abbia una tonnellata di librerie e utility helper potrebbe non sempre significare che siano effettivamente utili. Queste librerie sono ancora generiche e potrebbero essere molto lontane da alcune esigenze specifiche, cosicché alla fine tendo a riscrivere parte di esse per avere una soluzione più efficiente e specifica per il problema.

• inoltre, cose come lingua e amp; le prestazioni e la documentazione della piattaforma sono cose per le quali è più difficile da compensare rispetto alla mancanza di librerie. Se il codice che hai scritto in lingua xe piattaforma y è lento, ottimizzarlo da solo non sarà mai buono come sostituirlo con lingua x2 e piattaforma y2 per cui una coorte di persone (probabilmente più intelligenti) di me hanno fatto ottimizzazioni. Lo stesso vale per la documentazione, la mancanza di ciò si traduce in un maggiore dispendio di tempo nel fare prove di concetti, prove ed errori, codice sorgente e unit test di esplorazione per vedere come qualcosa deve essere fatto. E anche se si passa attraverso tutto questo, non si sa ancora se la soluzione che si è scelto sia la più adatta, come i creatori linguistici hanno previsto che funzioni.