A che cosa non rinuncerei e che cosa mi manca
Un chiarimento
Il presente post vuole affrontare l’annosa questione di un confronto tra due delle piattaforme di sviluppo più utilizzate (Java/JEE e .Net), con l’intento di raccontare qualcosa dei miei ultimi due anni e mezzo di lavoro, nei quali mi sono avventurato nel mondo Microsoft dopo un decennio di sviluppo sulla piattaforma Sun/Oracle. Affronterò la questione non solo confrontando i due (per altro molto simili) linguaggi principali utilizzati per fare sviluppo su JVM e su .Net, bensì anche riportando le mie impressioni su quali sono le differenze tra le due piattaforme in questione e, più in generale, tra gli ecosistemi che ad esse fanno riferimento.
Disclaimer
L’intento di questo post non è quello di dare il via a flame o guerre di religione: è semplicemente quello di riportare la mia esperienza, per quel che vale. Presenterò pertanto le mie opinioni, le quali – come dovrebbe essere ovvio ma è sempre utile ricordare – dipendono fortemente dalla mia forma mentis e non hanno la pretesa di avere un qualche valore assoluto.
Due linguaggi
Java e C#, senza dubbio i due linguaggi più utilizzati per fare sviluppo sulle due piattaforme in questione, sono per molti versi due linguaggi molto simili: entrambi linguaggi C-like, si differenziano nell’uso di tutti i giorni per alcune feature, che uno solo dei due ha o che sono implementate in modo diverso nei due casi. Di seguito, una lista (non esaustiva) delle principali differenze (e del mio parere in proposito).
Property
Cresciuto javista, nel primo periodo di passaggio a C# non apprezzavo più di tanto questa feature, che ora invece mi piace molto; nulla di indispensabile (fondamentalmente uno zucchero sintattico), ma un modo utile per distinguere – a livello di interfaccia OO – tra query e command. Non un motivo sufficiente per preferire C# a Java ma, dato che ci sono… perché non usarle?
Enum
Implementazione C-style in C# (ogni elemento di una enum è, fondamentalmente, una costante intera, sul cui utilizzo il compilatore fa ben pochi controlli), implementazione object oriented in Java (ogni elemento dell’enum è istanza di una classe e le classi corrispondenti ai diversi elementi dell’enum hanno una superclasse comune): ogni elemento dell’enum può avere attributi e metodi (con polimorfismo). Nulla che non si possa fare anche in C#, col vantaggio però che, nel caso di codice Java, il compilatore si occupa dei dettagli noiosi.
Generics
Simile nella sintassi, il supporto per l’utilizzo di generics costituisce la differenza più grossa tra i due ambienti a livello di piattaforma (vedi sezione successiva); questo si riflette in differenti possibilità di utilizzo, per cui nel codice C# ci sono possibilità che agli sviluppatori Java non sono disponibili. Su tutte:
new T()- overloading sui tipi parametrici (possibilità cioè di definire metodi generici le cui firme differiscono solo per il numero di tipi parametrici)
Senza dubbio l’unico motivo serio per cui sceglierei un linguaggio piuttosto che l’altro (ma, come dicevo, è questione di piattaforma sottostante, più che di linguaggio in sé).
Conversioni implicite di tipo ed extension method
Si tratta di due feature di C# che mi piacciono molto (benché sia facile finire per abusarne): in particolare, mi sembrano assai preziose quando
- si ha necessità di aggiungere regole/comportamenti di business a tipi standard (penso ad esempio a metodi di utilità che estraggano un elemento a caso da una lista o convertano un’istanza di
DateTimein epoch UNIX) - si vuole sviluppare qualcosa di simile ad un DSL
- si vogliono separare alcuni comportamenti aggiuntivi (metodi di utilità) dal modello di base che rende disponibili struttura dati e logica di business
Parametri out e ref
Si tratta di una feature disponibile in C# e non in Java; non ne sentivo la mancanza e, se non si tratta di utilizzare API scritte da altri che ne fanno uso, per parte mia probabilmente non la utilizzerei mai (fondamentalmente perché rompe l’idea di metodi come funzioni pure, utilizzando un approccio che decisamente non è nelle mie corde).
Convenzioni
Diversi linguaggi, diverse piattaforme… e diverse convenzioni – tema sul quale tradizionalmente le persone si accapigliano senza cambiare di una virgola le proprie abitudini: il Bene contro il Male. Nel dettaglio:
Formattazione
Due anni e mezzo di coding C#, ed ancora non riesco a considerare bello il modo in cui tale codice si presenta per quanto riguarda la formattazione. La posizione delle graffe, che nel mondo Java vede coesistere una scuola di pensiero maggioritaria ed una minoritaria con abitudini diverse, nel mondo C# è tradizionalmente quella mutuata dal mondo C. A livello di pura estetica, non avrei dubbi: non mi piace per nulla. A livello di opportunità, al solito, sono convinto che il punto focale sia, più che utilizzare una convenzione propria, utilizzare una convenzione di team, quale che sia, condivisa ed accettata, che renda facile agli uni mettere mano a codice scritto da altri. Al di là delle convenzioni ufficiali (Microsoft, come Sun, pubblica le proprie), dunque, darei valore a convenzioni localmente condivise – non per niente qualunque ambiente di sviluppo, per qualunque linguaggio o piattaforma sia pensato, permette di personalizzare facilmente le regole di formattazione da applicare. In questo senso, per giungere alla definizione di uno stile di team o di progetto, valuterei – oltre ovviamente alle abitudini pregresse dei membri del team – il grado di frizione che l’adozione di una particolare convenzione produce a fronte del fatto che su un particolare progetto si lavora spesso in più di un linguaggio. Produce più frizione leggere codice C# formattato in modo inusuale per quel linguaggio, o passare di continuo tra sorgenti C# formattati in un modo e sorgenti JavaScript formattati in un altro?
Naming convention
Altro tema difficoltoso per chi passa da una piattaforma all’altra, che possiamo riassumere citando il caso più evidente: iniziale maiuscola o minuscola per il nome dei metodi? Personalmente qui non avrei dubbi: adottare la stessa convenzione adottata nella libreria standard su cui si basa l’utilizzo del linguaggio (oltre che per quanto riguarda il case delle iniziali, tradizionalmente differente in Java ed in C#, lo stesso discorso vale per quanto riguarda l’adozione di uno stile di nomenclatura camel case piuttosto che di uno stile snake case): dunque metodi con nome maiuscolo in C#, con nome minuscolo in Java. E comunque dopo due anni e mezzo inizio quasi a pensare i nomi dei metodi con la maiuscola… 😉
Tra una settimana proseguiremo parlando delle caratteristiche peculiari delle due piattaforme e della vitalità dei due ecosistemi.
