Forum libero

Scritto da:
> Scritto da:
> > https://apple.slashdot.org/story/16/04/07/2124257/...
> >
> > Dopo Microsoft che rende gratuito Xamarin con la possibilità di programmare in C# su Android, ora anche Google cerca un'alternativa a Java in Android Studio.
> >
> > </java>
>
> Perché questo dovrebbe rappresentare la morte di Java? Non mi risulta che il suo mercato sia soltanto Android.

In pratica Java è morto su:
- sviluppo applet WEB (ci sono ancora rarissimi casi in cui è usato ma in generale nessuno si fida più di java [né di altri plugin] sul browser e comunque i vari browser stanno sradicando i plugin in toto)
- sviluppo applicazione Desktop (ci sono ancora casi dove è utile ed utilizzato [vedi ad esempio le applicazioni per compilare il 730] ma la quantità di bug nel framework che obbliga l'utente a continui aggiornamenti oltre al fatto di dover distribuire la JVM lo rende poco appetibile)


Sta morendo su Android:
- Microsoft ha reso gratuito Xamarin che permette di sviluppare applicazioni Android con lo stesso linguaggio con cui si sviluppano applicazioni per Windows (C#) che oltretutto è un linguaggio molto piacevole e per nulla verboso come invece è Java.
- Probabilmente grazie ad Oracle (ma forse per via dell'inutile verbosità del linguaggio) ora Google vuole liberarsi di Java

A questo punto resta solo il lato server che esiste ancora solo per il fatto che essendo Java molto "vecchio" ha un sacco di librerie disponibili... ma le altre piattaforme oramai non sono da meno.

Bisogna vedere a questo punto se le nuove generazioni vorranno ancora sorbirsi Java, con tutta la sua inutile e vecchia verbosità e il fatto che se vuoi lavorarci sopra senza dover reinventare la ruota mille volte devi includere varie librerie per cercare di rendere almeno accettabile programmarci sopra.



Alcuni esempi stupidi che però rompono i coglioni:

Voglio comparare due stringhe: stringa1 e stringa2

Java: stringa1.equals(stringa2)
C#: stringa1 == stringa2

Come vedi il metodo C# è molto più naturale, è praticamente il metodo usato da QUALSIASI altro linguaggio moderno, Java è praticamente l'unico linguaggio ancora oggi esistente che richiede quell'assurda forma di comparazione per le stringhe e, infatti, uno degli errori più frequenti di chi passa a Java è di usare l'uguaglianza per il confronto facendo errori difficili da capire per uno che non programma in Java regolarmente.

Altro esempio che mi è capitato proprio 30 secondi fa mentre stavo programmando un App per Android:

Ho una variabile long e vorrei farci un normalissimo switch-case tipo

switch (miaVariabileLong) {
    case 1:
       blabla
    case 32094320423940293402:
       blabla
    blablablabla
}

Peccato che lo switch-case, per qualche assurda ragione, non funzioni con i long. Funziona per gli int, funziona per i char, funziona per stocazzo, funziona persino con le stringhe (ma solo dalla JDK7, se hai un framework più vecchio col cazzo)... ma per i long... no. Vai a capire perché. Se voglio devo fare uno schifosissimo quanto patetico cast su int... e se la mia variabile è più grande degli int... bé... m'inculo.

Ovviamente in C# lo switch-case funziona anche sui long.


Altra cosa che mi è capitata poco fa sempre su Android: ho una data (dataIniziale) composta da data e ora... e voglio solo la data.

Java (senza librerie esterne):

 Calendar cal = Calendar.getInstance();
 cal.setTime(dataIniziale);
 cal.set(Calendar.HOUR_OF_DAY, 0);
 cal.set(Calendar.MINUTE, 0);
 cal.set(Calendar.SECOND, 0);
 cal.set(Calendar.MILLISECOND, 0);
 Date laDataCheVolevo = cal.getTime();

C# (senza librerie esterne):
var laDataCheVolevo = dataIniziale.Date;


Sempre poco fa... voglio sapere quanti giorni ci sono fra due date: data1 e data2

Java (senza librerie esterne):

 long diff = date2.getTime() - date1.getTime();
 long giorni = TimeUnit.DAYS.convert(diff, TimeUnit.MILLISECONDS);

C# (senza librerie esterne):
var giorni = (date2 - date1).Days;


L'altro giorno... voglio convertire una data in una stringa nel formato yyyy-MM-dd HH:mm:ss... ovvero ad esempio 2016-03-14 12:00:00

Java (senza librerie esterne):
String strData = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(data);

C# (senza librerie esterne)
var strData = data.toString("yyyy-MM-dd HH:mm:ss");

Quale dei due secondo te è il metodo più pulito e chiaro da capire? Perché diavolo in Java devo stare a creare un nuovo oggetto per fare un cazzo di "toString" formattato?


Poi... voglio creare una lista di oggetti di tipo Prenotazione

Java:
ArrayList<Prenotazione> lista = new ArrayList<Prenotazione>();

C#:

var lista = new List<Prenotazione>();

Che motivo c'è di ripetere a sinistra il tipo dell'oggetto che è ovvio da quello che sta scritto a destra? Non c'è. Infatti rende solo il codice più complicato da leggere e da capire, non lo rende affatto più chiaro.


Ancora... ho due pacchetti di dati (diciamo liste, ma potrebbero anche essere dati provenienti da un database) e voglio estrarre alcuni dati dalla prima lista, altri dalla seconda, unendole con un join come si fa con i database e in più voglio mettere dei filtri, ordinare i dati in uscita e creare un oggetto anonimo con la nuova lista risultante.

C# (senza librerie esterne) con LINQ che fa parte del linguaggio:

 var risultato = from l1 in lista1
                 join l2 in lista2 on l1.matricola equals l2.matricola
                 where l1.sesso == "M" && l2.lezione == "Informatica"
                 orderby l1.cognome descending
                 select new { 
                    Nome = l1.Nome, 
                    Cognome = l1.Cognome, 
                    OreFrequenza = l2.OreFrequenza 
                 }

Java (senza librerie esterne):
Ho paura solo a pensarci. Onestamente non saprei neanche farlo senza dividere il problema in multipli passaggi rompicazzo (tieni conto però che Java lo uso raramente, forse la suora ha una soluzione che non faccia completamente cagare).

LINQ esiste in C# dal framework 3.5, ovvero dal 2008 ed è molto familiare a chi conosce SQL (cioè praticamente tutti i programmatori) quindi non devi impararti cose troppo diverse da quelle che già consoci.

Java 8 (2014) ha finalmente le stream-api e le lambda che semplificano molto la cosa ma per esempio il join non saprei come farlo.


Insomma, se devo scegliere se usare Java o C#, scelgo immediatamente il secondo. È più espressivo di Java, meno verboso e ha un sacco di cose "innate" che in Java richiedono o varie righe di codice o l'uso di librerie esterne. Non c'è motivo per preferire Java a C#... l'unica ragione per cui si usa ancora Java è semplicemente che essendo nato molti anni prima ha una userbase vasta e molte librerie già pronte... ma raramente in C# mi sono trovato a dover includere librerie esterne per fare cose "di ogni giorno"... gran parte di quello che mi serve è già incluso nel framework base. Onestamente, dopo aver usato C#, tornare a Java mi fa sentire come tornare a programmare in Basic.

Scritto da: ::1
> Non ho voglia di rispondere alle wakkate per filo e per segno così apro un subthread apposta. Quando valuti un linguaggio non puoi fermarti alla sintassi, o a quello che offre di default, ma valutare l'ecosistema nella sua interezza.
> Il punto di forza di Java è l'ecosistema di librerie, implementazioni, interoperabilità disponibile e le performances delle implementazioni della jvm, con i gc ottimizzati che altri runtime si sognano.
> Java come linguaggio può morire anche domani, ma la jvm resisterà per molto tempo.

Adesso sto giocando a Minecraft. Torno dopo o domani.