Scala è pronto per la prima serata? [chiuso]

Anche se è vero che Scala è stato utilizzato allo scoperto su Guardian e su Twitter, c'è una preoccupazione fondamentale.

Gran parte della popolarità di Java deriva dal fatto che è relativamente facile da leggere e conservare. Scala ha un problema qui in quanto può essere scritto in molti stili diversi. Lo stile OO vs lo stile funzionale è l'ovvio divario qui, ma diventa più complicato quando parli dei 3 livelli di Scala .

Devi assicurarti che il tuo team e eventuali nuovi assunti possano seguire tutti lo stesso stile e che lo stile sia abbastanza semplice per essere effettivamente in grado di assumere sviluppatori che possano essere efficaci (non tutti possono assumere il top 2%).

Anche il supporto degli strumenti non è ancora del tutto pronto, anche se mi aspetto che questo divario venga chiuso abbastanza rapidamente. Puoi anche ottenere supporto per lo stack Scala completo dalla folla TypeSafe . Penso che Scala si ritaglierà la sua nicchia, ma fino a quando i livelli non saranno effettivamente incorporati nel linguaggio / compilatore / qualsiasi cosa, vedo un mal di testa di manutenzione che si abbatte sui team dopo i primi 1-2 anni di entusiasmante produttività.

Vedi questa risposta correlata per ulteriori dettagli.

Scala è attualmente utilizzato da Twitter e da The Gaurdian, quindi è sicuramente pronto per applicazioni non banali.

I programmatori di Scala saranno molto motivati e probabilmente molto bravi. Scegliere una nuova lingua è un ottimo modo per attrarre talenti.

Naturalmente, i programmatori di Scala spesso non hanno esperienza di Scala professionale, e ci possono essere varietà negli idiomi che usano. Alcuni potrebbero sforzarsi per la purezza di Haskell, mentre altri potrebbero vederlo come Java con chiusure. Quindi ci vorrà probabilmente del tempo per sviluppare standard e convenzioni di codifica coerenti.

Molti strumenti Java funzioneranno bene, sebbene IntelliJ Idea varrà probabilmente l'investimento su Eclipse.

Nel complesso, potrebbe essere una buona scelta se hai il controllo sul progetto. Se questo fa parte di una grande compagnia di assicurazioni, potresti incorrere in problemi se ci sono linee guida architetturali come: "Tutti i progetti devono essere costruiti da Maven e distribuiti in WebSphere". (Non ho motivo di pensare che questa particolare regola sarebbe un problema, ma una proliferazione di tali regole potrebbe farti inciampare a un certo punto.)

La mia impressione è che gran parte dell'ecosistema che viene fornito con linguaggi "convenzionali" (come Java) è destinato a compensare la loro goffaggine.

La domanda non è, quanti strumenti ci sono per una data lingua (Scala), ma se gli strumenti esistenti per quella lingua sono migliori degli strumenti esistenti per la lingua di riferimento (Java). Perché 100 strumenti mediocri non ti daranno ciò che un buon strumento può darti. E una cosa che non dovresti dimenticare è che il linguaggio stesso fa parte di quegli strumenti.

La dichiaratività di una lingua

• è inversamente proporzionale alla quantità e alla severità dei bug che produci con esso, motivo per cui Java è così bravo a produrre bug e hai bisogno di molti strumenti per evitarli e rintracciarli
• è proporzionale alla tua produttività, ecco perché Java è così estremamente prolisso e hai bisogno di un sacco di generatori di codice e strumenti simili

Ad esempio, una volta ho letto un orribile post sul blog di un ragazzo Ruby, che sosteneva che la digitazione statica non ha senso, perché i test copriranno la sicurezza del tipo. Ciò veniva chiaramente da qualcuno che non aveva ancora lavorato con un sistema di tipo statico espressivo. Supponendo che io possa rappresentare tutte le relazioni di tipo in una semantica linguistica e non è molto lavoro da fare (e non lo è, dato che la maggior parte dei linguaggi moderni supporta l'inferenza di tipo), ottengo tutto questo gratuitamente.

Per spingere un pensiero un po 'più in avanti: i test unitari assicurano che un'unità funzioni come specificato, o per riformularlo, le unit test sono specifiche eseguibili. Tuttavia attraverso la programmazione dichiarativa, le unità stesse sono specifiche eseguibili. Di nuovo, ottieni qualcosa gratuitamente.

Quello che sto cercando di dire è che non dovresti sottovalutare ciò che le caratteristiche del linguaggio possono fare per te. E a meno che tu non li provi davvero sul campo, non capirai mai.

Quindi, tornando alla domanda iniziale: gli strumenti esistenti per Scala sono migliori di quelli di Java? Difficile da dire. Dipende da cosa vuoi fare. Penso che saremmo tutti d'accordo sul fatto che la lingua è significativamente migliore, ora la domanda è: quanto è buono un ecosistema che troverai nella tua zona d'affari.
Per il Web, Lift è davvero un'opzione valida. Non so su desktop o dispositivi mobili.

let's say "non-trivial" is a multi-year, multi-release, 10-20 developers project.

Questo è un sacco di rischi. Le ricompense dovrebbero valerne la pena. Nel mondo delle app per aziende e progetti di dimensioni medio-grandi, l'assunzione di rischi è generalmente limitata. O piuttosto c'è già abbastanza rischio da affrontare ... La prevedibilità è più importante.

Dubito che l'adozione funzionerà in questo modo.

È più probabile iniziare come una manciata di persone che lavorano su una parte in cui il rischio è contenuto come POC, componenti non critici, test o parti in cui il problema sembra essere affrontato molto meglio da Scala rispetto alle alternative (forse se qualcosa coinvolge l'attore per esempio) ... Poi come strumenti maturi, la comunità cresce, il know-how cresce in azienda, quindi potrebbe espandersi.

Sfruttando il runtime Java, Scala è sicuramente pronto per la programmazione. Se è possibile distribuire un'applicazione Scala, una volta generato il bytecode, dovrebbe sempre funzionare con quella particolare versione del runtime Java. La libreria basata su Scala funzionerà come qualsiasi altra libreria di terze parti Java che ti è familiare.

In termini di IDE, strumenti di compilazione e tutto il resto, Scala non ha lo stesso livello di proliferazione di Java. Quindi non hai molti framework basati su Scala o strumenti basati su Scala. Questo ha più da dire con la popolarità di Java che con la crescente popolarità di Scala. Scala ha strumenti funzionali includono Scala IDE e sbt, strumento di costruzione. Ma non sono sofisticati come alcuni degli altri strumenti di supporto Java puri.

Punti di raccolta delle ciliegie da @huynhjl e @FarmBoy:

• Trovare un numero abbastanza grande di programmatori esperti di Scala potrebbe essere difficile.

• Il dogma della "best practice" per Scala è ancora in evoluzione (*).

• Le guide di stile, le convenzioni, ecc. sono ancora in evoluzione (*).

• Il supporto degli strumenti è ancora in evoluzione (*).

Tirando queste cose insieme, forse una domanda migliore da fare per te (te stesso / se stessi) è se la tua organizzazione è pronta per usare Scala su un progetto "non banale"? Avete le persone che possono far fronte a un grande progetto con così tante cose "ancora in evoluzione"? Al contrario, sarebbe meglio fare prima un progetto più piccolo?

(* In effetti, la maggior parte delle lingue si sta ancora evolvendo in uno o più di questi aspetti. Il problema qui è la velocità di cambiamento / flusso ... e se la tua squadra può farcela. )

David Pollak su Good Stuff ha un eccellente post sul blog intitolato I linguaggi funzionali saranno Regola ( ma non quest'anno) che entra nel nitty grintoso dei linguaggi funzionali in generale, e Scala in dettaglio che consiglio vivamente di leggere per capire meglio se Scala è pronto per la prima serata.

Non ho mai capito la distinzione tra enterprise e non enterprise programmi.

Uso gli stessi programmi sul lavoro come a casa. Non userei un programma mediocre nel mio tempo libero - perché dovrei?

Che cos'è un programma non professionale? Ho visto applicazioni scadenti, perché l'utente non conosceva meglio, a causa di problemi di compatibilità, o l'utente si rifiutava di provare qualcosa di nuovo.

Ma è un problema di software obsoleto e di obiettivi, lo sviluppatore aveva in mente - non della lingua, il programma era scritto. Se inizi a pensare, in quale linguaggio è scritto un programma, è già finito: fallire .

Enterprise -application è un termine marekting, che non è utile per discussioni serie.

E quale cliente sa in quale lingua hai svolto il tuo lavoro? A volte loro si preoccupano, a volte no.

Potresti avere domande relative alla maturità di una lingua, ma non puoi rispondere alla domanda per tutti i tipi di imprese e tutte le applicazioni.