Sono più alla fine novella dello spettro degli sviluppatori di software, ma ciononostante ho avuto l'esposizione a parecchi linguaggi e framework di programmazione. Da tutte le tecnologie che ho usato, non ho trovato nessuno con un'API ben strutturata e user-friendly come Java. Perchè è questo? Perché i solidi linguaggi come C ++, Perl e Python non hanno API che si avvicinino addirittura a Java?
La tua opinione potrebbe cambiare quando avrai più esperienza con altre lingue. Ho trovato le API Java piuttosto scadenti:
Data e calendario e le classi correlate sono un disastro.
Le classi di raccolta sono ingombranti e non funzionano bene con gli array. Questo è un problema perché alcuni metodi restituiscono raccolte mentre altri metodi richiedono array. Mancano le operazioni di raccolta molto comuni. Ho trovato le collezioni di template standard C ++ per essere più potenti e più facilmente estendibili.
Le librerie Java standard supportano la divisione delle stringhe, ma non supportano ancora l'unione delle stringhe, disponibile in quasi tutte le altre lingue.
Sono curioso di sapere cosa pensi dell'api di C # / .NET, btw, per quanto ne so è on-par se non migliore di Java. (Senza pregiudizi, io sono un ragazzo Java io stesso)
Per quanto riguarda la tua domanda, ho alcune teorie. Le librerie C ++ sono costruite con la vecchia libreria C e l'STL in aggiunta. Quando, era una delle prime librerie standard e uno dei primi linguaggi di programmazione orientati agli oggetti (preceduto da Smalltalk e probabilmente pochi altri - non ho molta familiarità con la cronologia delle lingue di OO). Ciò significa non troppe esperienze ancora, tra le altre cose.
Ciò che rende le API / librerie / documentazione di Java (e .NET) migliori sono due cose:
Esperienza in quanto erano in grado di iniziare con una lavagna pulita al momento: non era richiesta alcuna retrocompatibilità con le librerie esistenti, in modo che potessero creare una libreria standard basata sulle migliori idee del passato, e poi alcune. Naturalmente, la qualità effettiva delle librerie API / standard si è deteriorata, principalmente a causa del mantenimento della compatibilità con le versioni precedenti (ad esempio le vecchie classi Collection come Vector e Hashtable, che sono state sostituite da List e Map ma sono ancora nell'API per motivi di compatibilità con le versioni precedenti.
Il supporto aziendale è molto importante qui, poiché ciò significava che c'era un gruppo di persone che poteva trascorrere l'intera giornata lavorativa scrivendo la biblioteca e la documentazione. Questo è contrario alle lingue / alle biblioteche senza supporto aziendale, che si basano su volontari e su una comunità.
Sono abbastanza sicuro che sia anche una questione di cultura. Anche Java (e .NET) sono molto "aziendali" - alta sicurezza, compatibilità con le versioni precedenti, ecc. Python e Lisp e così via sono più rivolti alla comunità degli "hacker" (per generalizzare, non posso pensare di una parola migliore). Non si vede molto Java nel mondo * Nix (e nessun .NET vale la pena menzionare, per quello che conta), ma una quantità enorme di Python, Lisp e what-have-you.
Java è stato scritto come linguaggio di programmazione per colletti blu per programmatori professionisti. (Il motivo per cui insegnare Java agli studenti è inappropriato)
Dai un'occhiata alle cose originali di Java di James Gosling.
Quindi ha dei brutti bit nelle librerie (ci si abitua e alla fine si riparano)
Ma ha anche una lunga storia di ingegneria conservativa del software che non infrange le mie milioni di linee di codice solo per aggiungere funzionalità di linguaggio o libreria gee-whiz. Non voglio assegnare risorse alla correzione della migrazione della versione. Non c'è nessun vantaggio competitivo per me lì.
Contrasta con l'approccio di C # ai generici, dove ottieni una nuova libreria di raccolte.
Questo approccio conservativo rende difficile cambiare oggetti di libreria mal progettati, ma alcuni progressi sono stati fatti su questo.
Quindi un po 'più di tempo viene dedicato alla lucidatura della documentazione. E arriviamo dove siamo oggi.
Hai controllato le strutture Cocoa e Cocoa Touch? Questi due framework sono altrettanto belli e ben progettati come le macchine hardware Apple.
Come dice Kevin:
Your opinion might change as you get more experience with other languages.
Assolutamente vero.
L'impegno che il team Java ha fatto per evitare di introdurre modifiche non retrocompatibili significa che probabilmente pensano a lungo e duramente quando estendono le loro API, invece di lanciare qualcosa là fuori. Confrontalo con (per esempio) PHP, che ha completamente cambiato la gestione dell'XML in PHP5 - nessuna deprecazione, se n'è andata.
Le ragioni sono storiche e filosofiche, con la storia che influenza profondamente la filosofia.
C ++, Perl e persino Python sono tutti più vecchi di Java e, a causa della legge di Moore, sono stati sviluppati in un ambiente in cui il disco e la memoria erano uno o due ordini di grandezza più costosi. Gli sviluppatori desideravano molto scegliere e scegliere le API che avevano su un sistema perché la memoria e il disco erano costosi e le reti erano lente. Perché non lasciare che gli sviluppatori esercitino il loro giudizio e scelgano la libreria che hanno ritenuto migliore?
Java è stato originariamente sviluppato per software proprietario e incorporato in modo da fornire tutte le librerie utilizzate in fase di esecuzione. Quando la migrazione di Java verso il calcolo generico ha funzionato molto bene per le persone che fanno software line-of-business, ma è stato anche uno dei motivi per cui inizialmente Java è stato colpito come lento e gonfio.
Se vai in un bel ristorante, spesso ti viene data una scelta tra "prix fixe" e "ala carte". Ogni corso del pasto fissa il pasto, e forse anche il vino viene scelto dallo chef in anticipo. Questo è fantastico se non sai molto del cibo e fidati dello chef. Se hai gusti molto particolari o pensi che lo chef sia un deficiente, ti consigliamo di ordinare alla carta, dove scegli ogni portata per soddisfare esattamente i tuoi gusti.