Naturalmente, la persona migliore per porre questa domanda è qualcuno del Comitato esecutivo JCP, non noi. Tuttavia, ciò non mi impedirà di impegnarmi in alcune speculazioni oziose.
La risposta a ogni domanda "perché non è stata implementata questa funzionalità" è sempre perché i vantaggi non hanno superato i costi.
Eric Lippert (ex membro del team C #) dice che, affinché un prodotto abbia una funzionalità , quella funzione deve essere:
- pensato in primo luogo
- desiderato
- progettato
- specificato
- implementato
- testato
- documentato
- spedito ai clienti
In altre parole, devono esserci molte cose importanti che devono accadere prima che qualsiasi nuova caratteristica del linguaggio di programmazione possa essere realizzata. I costi sono maggiori di quanto pensi siano.
Nel team C #, ogni nuova richiesta di funzionalità inizia con un punteggio inferiore a 100. Quindi il team valuta i vantaggi e i costi, aggiungendo punti per i vantaggi e sottraendo punti per i costi. Se il punteggio non supera lo zero, la funzione proposta viene scartata sommariamente. In altre parole, la nuova funzione deve fornire un vantaggio interessante.
Ma il Elvis Operator è stato trasformato in C #. Quindi, perché non è diventato Java?
Nonostante le apparenti somiglianze, Java e C # hanno filosofie linguistiche significativamente diverse. Ciò è evidenziato dal fatto che i programmi aziendali Java tendono ad essere grandi collezioni strutturali di architettura. La brevità e l'espressività della lingua sono sacrificate sull'altare della cerimonia e sulla facilità di codifica. I ben noti modelli architettonici del software che tutti i membri del team di sviluppo possono riconoscere sono preferiti rispetto alle comodità linguistiche.
Considera questo scambio Reddit :
The Elvis operator has been proposed for every version of Java since 7, and has been rejected every time. Different languages fall on different points along the spectrum from "pure" to "pragmatic", and languages implementing the Elvis operator do tend to be further toward the pragmatic end of the spectrum than Java.
If you have a team of 15+ year Java pros writing a highly-distributed, highly-concurrent backend processing system of some sort, then you probably want a great degree of architectural rigor.
However, if you have a junior to mid-level team, half of whom migrated from Visual Basic, and you have them writing an ASP.NET web app that mostly just does CRUD operations... then it might be overkill to design a bunch of AbstractFactoryFactory classes to abstract away the fact that you have no control over which columns are nullable in the shitty legacy database that you must use.
Queste profonde differenze nella filosofia della lingua si estendono non solo al modo in cui le lingue vengono utilizzate, ma al modo in cui viene intrapreso il processo di progettazione della lingua stessa. C # è un dittatore benevolo lingua. Per ottenere una nuova funzionalità in C #, hai davvero per convincere una persona: Anders Hejlsberg .
Java assume un approccio più conservativo. Per ottenere una nuova funzionalità in Java, è necessario ottenere il consenso da un consorzio di grandi produttori come Oracle, IBM, HP, Fujitsu e amp; Cappello rosso. Ovviamente, quel processo sarà più lento e presenterà una barra più alta per le nuove funzionalità linguistiche.
La domanda "perché non è stata implementata la funzione x ..." include sempre implicitamente le parole "... se è ovviamente una buona idea?" Come ho dimostrato adeguatamente qui, la scelta non è mai così semplice.