Qualcuno ha avviato la migrazione da Java a Scala? Se sì, come si fa? Cosa posso fare per incoraggiare i miei colleghi a fare lo stesso?
Probabilmente il modo più semplice è utilizzare per la prima volta Scala solo per i test. In questo caso, potresti anche non doverlo dire al tuo capo :-) Se glielo chiede, digli "è solo il mio caso privato, è molto più facile e veloce usare Scala per questo". Una volta che tu (e la tua organizzazione) hai abbastanza esperienza con Scala puoi iniziare a usarlo per il codice "reale".
Dal punto di vista delle aziende è meglio stare con Java se non ci sarà alcun vantaggio che otterranno migrando a Scala. È più facile per loro assumere programmatori Java per costruire e mantenere l'applicazione. Potresti andartene dopo aver implementato tutto in Scala :-) No offences: -)
Chiedi al tuo capo di leggere esperienze come questa:
I'm currently doing most of my things in Scala right now. (I should mention that I think that Scala is the best thing since the invention of the wheel some time ago. :-D )
In my humble opinion it is the only language which truly allows people to choose the best approach to a task without some unnecessary divide between (more) object-oriented and (more) functional approaches.
Looking at the languages which claimed something like this before, I can basically see two competing language design camps:
The ones from the object-oriented side which saw that functional programming gained some traction lately and thought "Well, we don't really understand that functional thingie, but let's add some fancy syntactical sugar to our language, so we can claim it is functional too!" (examples: Java, Python)
Then the ones from the functional side, who thought "Well, our functional approach is far superior to anything else and that object-oriented nonsense is annoying, but let's put some additional keywords into our language, that will make our language escape academia for sure!" (examples: F#, OCaml)
Scala's designers unified many approaches coming from both sides and created some well-designed language, which is - in my humble opinion - the biggest difference to other languages, which decided to take the "Frankenstein" approach to programming language design.
Having done only smaller things with Lift yet and only superficial experience with Rails and Django, I have to admit that most of the time when I wondered why something in Lift worked differently from what I expected, this was due to the fact that my expectations were flawed and Lift's approach superior.
Lift is certainly no "easy introduction to Scala" but learning how Lift works was almost as rewarding as learning Scala before it.
The ability to have a "clean" view without any logic in it is a great improvement to other frameworks which claimed the same, but fell short of it. Scala's XML literal support makes it possible to verify the well-formedness of your response: The compiler will prove at compile time that you only emit well-formed XML to a client.
Lift is viable technology and at the moment the only real approach if you want to build web applications which look, feel and behave like "real" desktop applications without writing insane amounts of code yourself.
[ Source ]
Negli ultimi due anni abbiamo progredito in modo equo in questo viaggio su guardian.co.uk - la nostra piattaforma aperta è basato su Scala, il nostro core CMS (originariamente in Java) sta gradualmente incorporando più Scala (ci stiamo rapidamente spostando da Maven a SBT per la nostra build) ed è stata un'esperienza meravigliosa - davvero rinvigorente i nostri sviluppatori, alcuni dei quali stavano diventando un po 'stanchi con Java:)
Ti incoraggerei a leggere questi due articoli sulla nostra transizione e forse usarli come prova a sostegno con i tuoi capelli a punta:
Alcuni suggerimenti rapidi:
Inizia scrivendo i tuoi test in Scala - in questo modo puoi acquisire familiarità con la lingua, aumentare la tua fiducia in essa e non dover superare le paure che potresti avere sull'aggiunta del runtime ai server di produzione immediatamente .
Non chiedere l'autorizzazione per provare nuove tecnologie. Meglio chiedere perdono se devi: -)
Questa domanda si tuffa in un'altra domanda. Questo è per quali tipi o progetti la migrazione a Scala fornisce un valore aggiunto? Faccio il giorno di Java il mio giorno di lavoro, ma sogna il giorno in cui posso usare Scala "con rabbia".
Una coppia risponde alla mia domanda:
Problemi per i quali la concorrenza basata su attori fornirebbe un grande vantaggio (Akka)
Le applicazioni Web hanno dati trasferiti su di esse tramite COMET (Lift)
Altre informazioni o esperienze ancora migliori?
Sto scrivendo dei test per le mie app Java su Scala e sono d'accordo che è un buon punto di partenza. La mia copertura di test è migliore perché è più veloce e più facile scriverli (anche da quando uso Scala, mi concentro volentieri a scrivere test più).
Ho anche iniziato a realizzare prototipi e POC a gettoni in Scala praticamente esclusivamente. Cerco di rendere i manager e i supervisori il più possibile consapevoli del fatto che ho usato Scala per questi pezzi unici e ho sottolineato che sono riuscito a ottenere qualcosa in fretta grazie a Scala. Avevamo bisogno (beh, tipo di bisogno) di un'app web per tenere traccia del nostro gioco di elefanti bianchi delle feste di festa - 1,5 ore con Scalatra e MongoDB e il mio intero reparto sta vedendo questa app e chiedendole. Ammettiamolo, non riuscirai mai a descrivere i manager quanto più espressiva è la lingua o che il suo modello di concorrenza è molto meglio. Ma se li mostri puoi ottenere più risultati più velocemente, guadagni terreno.
Ma penso che il pezzo più grande sia suscitare l'entusiasmo degli sviluppatori su Scala. Sono sicuro che lavoriamo tutti con sviluppatori che non seguono attivamente la nuova tecnologia, ea volte è difficile convincere la gente a fare qualcosa di nuovo (perché, davvero, non capisco). Mostrare a quelle persone alcuni benefici di Scala (prova il REPL) è la chiave. Se ottieni abbastanza sviluppatori che ronzano sugli stessi vantaggi della produttività, è molto più probabile che Scala venga adottata ufficialmente nella tua organizzazione.
Sparire la voce e ottenere lo sforzo di base è il mio obiettivo principale nel 2011. Vedremo come si evita, perché non posso aspettare il giorno in cui avrò usato Scala per la maggior parte del mio lavoro.
Mi chiedo perché scelga l'una o l'altra? Perché decidere di lanciare Java fuori dalla porta e andare fino in fondo alla Scala?
Non esiste lo strumento perfetto per il lavoro. Non c'è motivo di gettare completamente l'esperienza in una lingua e sostituirla con un'altra.
Non vorrei lavorare (più) in un'azienda che si concentra su una lingua o un ambiente, tbh. È meglio conoscere molte cose e scegliere lo strumento giusto per il lavoro.
Accanto a ciò, è difficile, se non impossibile, far sì che la tua organizzazione passi completamente a Scala. Invece, proverei a fare alcuni progetti (o anche parti di progetti) fatti in Scala, invece di optare per l'approccio "tutto o niente". Potresti, ad esempio, optare per testare il tuo codice Java con Specs2, che ha una sintassi piuttosto bella rispetto al semplice vecchio JUnit - e non è nemmeno complesso, confuso e difficile codice e paradigmi di Scala, solo zucchero sintattico intorno alla definizione del comportamento della tua applicazione .
Un buon modo è quello di dimostrare due versioni dello stesso programma. In questo modo puoi mostrare ai tuoi colleghi (in pratica) Expressiveness di Scala. Fare la stessa cosa per altri problemi (XML, concorrenza, ecc.) Può dimostrare i vantaggi dell'uso di Scala anziché di Java per affrontare problemi specifici.
Naturalmente non aspettarti che la migrazione avvenga in un giorno. Ci sono molti problemi che potresti sottovalutare: la curva di apprendimento, la base di codice esistente, ecc.