Come incoraggi la tua organizzazione a passare da Java a Scala? [chiuso]


15

Qualcuno ha avviato la migrazione da Java a Scala? Se sì, come lo fai? Cosa posso fare per incoraggiare i miei colleghi a fare lo stesso?


aggiungi scala e migrazione al tag se hai l'autorità per farlo
nanda

9
Forse dovresti spiegare perché
TheLQ

È necessaria una conoscenza interna sufficiente per garantire un fattore di bus "sufficientemente elevato".

Risposte:


15

Probabilmente il modo più semplice è usare Scala solo per i test. In questo caso, potresti anche non dover dire al tuo capo :-) Se gli chiede, digli "è solo il mio caso di test privato, è molto più facile e veloce usare Scala per questo". Una volta che tu (e la tua organizzazione) avete abbastanza esperienza con Scala, potete iniziare ad usarlo per il codice "reale".


Questi erano i miei pensieri, esattamente, per la migrazione da C # a F #.
GregC,

7

Dal punto di vista delle aziende è meglio rimanere con Java se non vi è alcun vantaggio distinto che otterranno migrando a Scala. È più facile per loro assumere programmatori Java per creare e gestire l'applicazione. Potresti andartene dopo aver implementato tutto in Scala :-) Senza offese :-)


1
Plain Java è qui per restare. Scala può o no. È troppo presto per dirlo.

"È più facile assumere sviluppatori Java" è probabilmente vero. Ma assumere quelli che sono "facili da assumere" potrebbe non essere il modo più economico per completare il tuo progetto.
Kevin Cline,

7

Chiedi al tuo capo di leggere esperienze come questa:

  1. Al momento sto facendo la maggior parte delle mie cose a Scala. (Devo dire che penso che Scala sia la cosa migliore dall'invenzione della ruota qualche tempo fa. MrGreen)

    Secondo la mia modesta opinione, è l'unico linguaggio che consente davvero alle persone di scegliere l'approccio migliore a un'attività senza una divisione non necessaria tra approcci (più) orientati agli oggetti e (più) funzionali.

    Guardando le lingue che hanno affermato qualcosa del genere prima, posso praticamente vedere due campi di progettazione linguistica concorrenti:

    • Quelli dal lato orientato agli oggetti che hanno visto che la programmazione funzionale ha acquisito una certa trazione ultimamente e hanno pensato "Beh, non capiamo davvero quella cosa funzionale, ma aggiungiamo un po 'di zucchero sintattico alla nostra lingua, quindi possiamo affermare che è funzionale pure!" (esempi: Java, Python)

    • Quindi quelli dal lato funzionale, che hanno pensato "Bene, il nostro approccio funzionale è di gran lunga superiore a qualsiasi altra cosa e che l'assurdità orientata agli oggetti è fastidiosa, ma mettiamo alcune parole chiave aggiuntive nella nostra lingua, che renderanno sicuramente la nostra lingua sfuggire al mondo accademico !" (esempi: F #, OCaml)

    I designer di Scala unificarono molti approcci provenienti da entrambe le parti e crearono un linguaggio ben progettato, che è - a mio modesto parere - la più grande differenza rispetto ad altre lingue, che decise di adottare l'approccio "Frankenstein" alla programmazione del linguaggio di programmazione.

  2. Avendo fatto solo cose più piccole con Lift e solo un'esperienza superficiale con Rails e Django, devo ammettere che il più delle volte quando mi chiedevo perché qualcosa in Lift funzionasse in modo diverso da quello che mi aspettavo, ciò era dovuto al fatto che le mie aspettative erano difettoso e l'approccio di Lift superiore.

    Lift non è certamente una "facile introduzione a Scala", ma imparare come funziona Lift è stato quasi gratificante come imparare prima di Scala.

    La capacità di avere una visione "pulita" senza alcuna logica in essa è un grande miglioramento rispetto ad altri framework che hanno rivendicato lo stesso, ma non ce l'hanno fatta. Il supporto letterale XML di Scala consente di verificare la correttezza della risposta: il compilatore dimostrerà al momento della compilazione di emettere solo XML ben formato su un client.

  3. Lift è una tecnologia praticabile e al momento l'unico vero approccio se si desidera creare applicazioni Web che sembrano, si sentono e si comportano come applicazioni desktop "reali" senza scrivere da soli quantità insane di codice.

[ Fonte ]


3

Negli ultimi due anni abbiamo compiuto un buon cammino lungo questo viaggio su guardian.co.uk: la nostra piattaforma aperta è costruita su Scala, il nostro core CMS (originariamente in Java) sta gradualmente incorporando più Scala (ci stiamo presto spostando da Maven a SBT per la nostra build) ed è stata un'esperienza meravigliosa - davvero corroborante per i nostri sviluppatori, alcuni dei quali stavano diventando un po 'stanchi di Java :)

Ti incoraggio a leggere questi due articoli sulla nostra transizione e forse li userei come prova a sostegno dei tuoi capelli a punta:

http://skillsmatter.com/podcast/home/how-we-moved-from-java-to-scala

http://www.infoq.com/articles/guardian_scala

Alcuni consigli rapidi:

  • Inizia scrivendo i tuoi test in Scala: in questo modo puoi familiarizzare con la lingua, aumentare la tua fiducia in essa e non dover superare le paure che potresti avere sull'aggiunta del runtime ai tuoi server di produzione immediatamente.

  • Non chiedere l' autorizzazione per provare nuove tecnologie. Meglio chiedere perdono se devi :-)


+1! per "Non chiedere il permesso di provare nuove tecnologie. Meglio chiedere perdono se devi :-)"
Giorgio

2

Questa domanda è stata inserita in un'altra domanda. Questo è per quali tipi o progetti la migrazione a Scala offre un valore aggiunto? Faccio Java day il mio lavoro quotidiano, ma sogno il giorno in cui posso usare Scala "con rabbia".

Una coppia risponde alla mia domanda:

  • Problemi per i quali la concorrenza basata sugli attori fornirebbe grandi vantaggi (Akka)

  • Le applicazioni Web di cui i dati sono stati trasferiti tramite COMET (Lift)

Altre intuizioni o esperienze ancora migliori?


1

Sto scrivendo test per le mie app Java in Scala e sono d'accordo che sia un buon punto di partenza. La mia copertura dei test è migliore perché è più veloce e più semplice scriverli (anche da quando uso Scala, mi concentro volentieri sulla scrittura di test in più).

Ho anche iniziato a realizzare prototipi e POC usa e getta in Scala praticamente esclusivamente. Cerco di rendere i manager e i supervisori il più consapevoli possibile di aver usato Scala per questi pezzi unici e sottolineo che sono stato in grado di far funzionare rapidamente qualcosa grazie a Scala. Avevamo bisogno (beh, un po 'di bisogno) di un'app web per tracciare il nostro gioco di elefanti bianchi per le feste - 1,5 ore con Scalatra e MongoDB e il mio intero dipartimento sta vedendo questa app e chiedendoci. Ammettiamolo, non riuscirai mai a descrivere ai manager quanto sia più espressivo il linguaggio o che il suo modello di concorrenza sia molto migliore. Ma se mostri loro che puoi fare di più più rapidamente, guadagni terreno.

Ma penso che il pezzo più grande sia entusiasmare gli sviluppatori per Scala. Sono sicuro che lavoriamo tutti con sviluppatori che non si tengono attivamente al passo con le nuove tecnologie, e a volte è difficile entusiasmare quelle persone nel fare qualcosa di nuovo (perché, davvero non capisco). Mostrare a queste persone alcuni vantaggi di Scala (provare il REPL) è la chiave. Se hai abbastanza sviluppatori che ronzano per gli stessi vantaggi della produttività, allora hai molte più probabilità di ottenere l'adozione ufficiale di Scala nella tua organizzazione.

Spargere la voce e far rotolare lo sforzo di base è il mio obiettivo principale nel 2011. Vedremo come andrà a finire, perché non vedo l'ora che io possa usare Scala per gran parte del mio lavoro.


1

Mi chiedo perché scegliere l'uno o l'altro? Perché decidere di buttare Java fuori dalla porta e andare fino in fondo?

Non esiste lo strumento perfetto per il lavoro. Non c'è motivo di abbandonare completamente la competenza in una lingua e sostituirla con un'altra.

Non vorrei lavorare (più) in un'azienda che si concentra su una lingua o un ambiente, ad esempio. È meglio conoscere molte cose e scegliere lo strumento giusto per il lavoro.

Inoltre, è difficile, se non impossibile, far passare completamente la tua organizzazione a Scala. Invece, proverei a portare a termine alcuni progetti (o anche parti di progetti) a Scala, invece di seguire l'approccio del tutto o niente. Potresti, ad esempio, scegliere di testare il tuo codice Java con Specs2, che ha una sintassi abbastanza buona rispetto al semplice vecchio JUnit - e non è nemmeno un codice Scala e paradigmi complessi, confusi e difficili, solo uno zucchero sintattico nel definire il comportamento della tua applicazione .


0

Un buon modo è dimostrare due versioni dello stesso programma. In questo modo puoi mostrare ai tuoi colleghi (in pratica) l' Espressività di Scala . Fare la stessa cosa per altri problemi (XML, concorrenza, ecc.) Può dimostrare i vantaggi dell'utilizzo di Scala anziché Java per affrontare problemi specifici.

Ovviamente non aspettatevi che la migrazione avvenga in un giorno. Ci sono molti problemi che potresti sottovalutare: la curva di apprendimento, la base di codice esistente, ecc.

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.