Perché usare Scala su Java


16

Sono totalmente interessato alla Scala come lingua ... e ancora faccio fatica a capire perché qualsiasi azienda dovrebbe passare da Java a Scala. Scala è solo zucchero sintetico in cima alla JVM o ci sono miglioramenti fondamentali in Scala su Java che migliorerebbero le applicazioni del mondo reale?


4
Questo ha ottenuto di avere un qualche duplicato.

2
Sembra che tu l'abbia usato molto (Scala) (beh, più di me) - cosa hai trovato nelle tue esperienze personali?
FrustratedWithFormsDesigner,

Ho visto domande come ... Cosa pensano gli sviluppatori Java di Scala, Cosa devo fare dopo come sviluppatore Java, Come posso avviare la mia migrazione da Java a Scala ... ma dove non ho visto una domanda o una risposta che si concentra sui motivi alla base dell'utilizzo di Scala come linguaggio di programmazione per lo sviluppo del mondo reale.
Dakotah North

1
@delnan, almeno su SO: stackoverflow.com/questions/6073517/… . @DakotahNorth, ti preghiamo di non incrociare post tra i siti SE: scegli il forum più adatto alla tua domanda e pubblica solo lì. Su altri siti, il tuo post verrà comunque chiuso, proprio come è successo con quello su SO.
Péter Török,

1
Ecco un altro duplicato quasi esatto su SO, con risposte eccellenti: stackoverflow.com/questions/2683914/…
Péter Török,

Risposte:


19

Disclaimer: non sono un guru della Scala.

Scala fa due cose estremamente bene che Java (attualmente) non fa.

Risolvi problemi funzionali

  • Al livello più elementare, Scala ha una vera e propria chiusura con il supporto delle collezioni. Ciò significa che non è più necessario scrivere il codice della piastra della caldaia come (strappato senza vergogna da un post DZone)

    public List<Item> bought(User user)
    {
        List<Item> result = new ArrayList();
        for (Item item : currentItems)
        {
            if (user.bought(item))
            {
                result.add(item);
            }
        }
        return result;
    }

Invece scrivi qualcosa del tipo:

def bought(user: User) = items.filter(user bought _)
  • C'è più amore funzionale, ma non sono qualificato per parlarne poiché attualmente faccio ancora schifo alla programmazione funzionale :)

Risolvi la concorrenza in un modo più sicuro

  • Scala ha un modello di attori (+ qualche altra bontà) che è intrinsecamente più sicuro dei dati mutabili di Java + blocchi sul modello di thread (non importa quanto siano efficaci le librerie, Java è ancora ostacolato dal linguaggio).

Onestamente non riesco a pensare ad altro che fa sì che Scala si alzi sopra Java. Un sacco di piccoli guadagni e miglioramenti sì, ma anche molta più corda per appenderti. YMMV

HTH un po '


3
Vorrei sottolineare che Akka (modello attore) è disponibile sia per Scala che per Java. Vedi akka.io
Giorgio,

5
Mi piace Scala e sto migrando da Java. Tuttavia mi fa incazzare quando si confrontano Java e Scala e gli sviluppatori di Scala cercano di scrivere il codice Java verboso e multilinea possibile e si sforzano molto di sostituirlo con Scala one liner. Senza perdita di leggibilità sopra il codice Java potrebbe rientrare in 5 righe, non 12
matt

2
"Un sacco di piccoli guadagni e miglioramenti sì, ma anche molta più corda per appenderti." +1
Rob,

@lucek Soprattutto perché lo snippet usa la convenzione con le parentesi graffe di C invece di quella di Java: P
Andres F.

@robjb: "Un sacco di piccoli guadagni e miglioramenti sì, ma anche molta più corda per appenderti." Non sono d'accordo sul fatto che Scala ti dia più corda per appenderti. Almeno, non c'è alcuna spiegazione per questa affermazione nella risposta e non riesco a vederne una. Inoltre, Scala non introduce solo alcuni idiomi funzionali su un linguaggio OO (come ad esempio C # e Java 8), ma cerca di integrare OOP e FP in un paradigma. IMHO non si tratta di "piccoli miglioramenti", ma piuttosto di un cambio di paradigma.
Giorgio,

9

Dipende dalla tua definizione di "solo zucchero sintattico". Ad esempio, in che modo Java è più di un semplice zucchero sintattico sul codice macchina?

Qualsiasi lingua può fare meno del codice macchina, ma nessuna lingua può fare di più.

Ciò che le lingue di alto livello apportano alla tabella sta rendendo il codice più facile da leggere e comprendere, più facile da comporre e rilevare più errori. E, secondo me, è il primo di questi che fa la differenza - precisamente "solo zucchero sintattico".

Ma considerando solo gli altri due, ci sono ancora vantaggi di Scala rispetto a Java.

Non ribadire il punto, ma avere chiusure rende il codice molto più compostabile che non avere chiusure. E mentre Java 7 aggiungerà qualcosa chiamato chiusure, non saranno così - saranno solo funzioni anonime.

Per quanto riguarda la rilevazione di più errori, l'eccezionale gestione della varianza di Scala ne è la prova sufficiente. Inoltre, la sua enfasi sull'immutabilità previene anche tutti i tipi di errori - non è che Java non possa fare immutabile, ma semplicemente non viene fornito con la libreria per farlo.


4
In realtà le "chiusure" di Java non arriveranno fino a Java 8
Martijn Verburg,

1
@Martijn Grazie per la correzione. A questo punto, in realtà non mi interessa più.
Daniel C. Sobral,

1
Direi che lo zucchero sintattico è solo una sintassi alternativa in aggiunta alla semantica esistente. Poiché la semantica del codice macchina non include oggetti, classi, ecc., Penso che Java non sia solo zucchero sintattico rispetto al codice macchina. Il paradigma della semantica e della programmazione è diverso.
Giorgio,

@Martijn Verburg: Java ha già una forma di chiusure (sotto forma di classi interne anonime). Ciò che manca sono le funzioni anonime (che possono essere pensate come speciali classi anonime con esattamente un metodo e qualche sintassi speciale).
Giorgio,

@Giorgio - vero, ma la classe interna anon è scarsamente performante rispetto all'imminente implementazione basata su invokedynamic ed è bene, codice sorgente brutto IMO :-)
Martijn Verburg

2

Oltre alla risposta di Martijn, vorrei aggiungere che Scala è più espressiva di Java e i vantaggi sono che (1) ti rende più produttivo (2) scrivere meno codice per risolvere lo stesso problema significa che puoi ridurre i bug nel tuo codice (il codice IMHO privo di bug è un mito).


0

Sto usando Scala da circa 3 mesi e ancora non riesco a trovare nulla che non sarei in grado di fare in Java. Per me letteralmente ogni letteratura sulla Scala sembra parlare la stessa cosa boilerplate . Se quello che stai cercando è ridurre il boilerplate, Scala è per te ma IMHO, ad esempio, l'esempio di filtro sopra riportato potrebbe essere risolto usando le raccolte apache

<T> CollectionUtils.filter(Predicate<T>...)

o utilizzare le chiusure in questo modo

<T> CollectionUtils.forAllDo(..., Closure<T>)

Ma ovviamente più prolisso. Mi piace l'inferenza del tipo però. Man mano che impari Scala, ti renderai conto che questo è probabilmente ciò che sta accadendo sotto il cofano. Secondo me, ogni lingua viene fornita con + ve e -ve.


-3

lista comprensione, per comprensione.

per esempio in Java scrivi:

int myVar;
if (condition) {
  myVar = //some value
}
else {
 myVar = //some other value
}

In scala, lo stesso codice, è scritto molto più elegantemente (come Python) come:

int myVar = (//some value) if (condition) else // other value;

e fatto.

C'è così tanto che Scala offre che Java non lo fa. Semplicemente non c'è nessun confronto. L'unico problema è che le persone hanno più familiarità con Java (questo è ciò che insegnano nelle classi CS) e non ancora abili con il paradigma Scala.

Scala ha una ricorsione della coda, può restituire tuple (qualcosa che potrebbe arrivare in Java 8 credo).

Non c'è paragone. Scala è stata sviluppata da Martin Ordersky, che ha lavorato nel core team di Java Generics.

Scala è solo un linguaggio di gran lunga superiore. Questo è tutto quello che c'è da fare. Le persone che dicono il contrario semplicemente non hanno esplorato Scala abbastanza per conoscerlo meglio.

Sopra, intendevo dire l'ottimizzazione della ricorsione della coda (che la JVM non può fare come può fare il compilatore di Scala).

Scala inoltre compila e funziona più velocemente delle app JVM (Sì, è vero). Per non parlare dei quadri. Usiamo Tomcat per esempio e distribuiamo alcuni servel per gestire REST.

Una cosa che Tomcat non può fare, sono le operazioni asincrone che richiedono I / O non bloccanti. Per questo, gli sviluppatori JAVA hanno in genere inventato una soluzione alternativa utilizzando una coda di messaggi (invia il messaggio alla coda e alcuni altri processi o thread lo raccolgono e fanno quello che vuoi in background).

Sfortunatamente, questo metodo è cr * p e un hack per i limiti della distribuzione di servlet Java su Tomcat.

Vai a dare un'occhiata a Akka + spray. Utilizza gli attori di Scala (gli attori sono proprio come i thread, tranne che l'unico modo in cui possono comunicare è attraverso i messaggi).

E fatto, le chiamate REST asincrone hanno reso facile. Attività in background di lunga durata? Nessun problema. Basta sparare e dimenticare, ed eseguire alcuni sondaggi REST per controllare lo stato dal front-end di tanto in tanto.

Se stai ancora usando Java e pensi che sia meglio di Scala, potresti anche smettere di usare il tuo computer per scrivere e tornare ai giorni delle penne d'oca e scrivere a lume di candela. Java è fondamentalmente antidiluviano rispetto a Scala.


4
Questo non è un esempio di comprensione di un elenco. E in Java scrivi:int myVar = condition ? someValue : otherValue
Kevin Cline il

1
È necessario modificare tali //some value //other valuecommenti per adattarli /*some value*/o altro. Attualmente sta incasinando l'evidenziazione della sintassi: p
KChaloux,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.