Como você incentiva sua organização a mudar do Java para o Scala? [fechadas]

A organização de alguém iniciou a migração do Java para o Scala? Se sim, como você faz isso? O que posso fazer para incentivar meus colegas a fazer o mesmo?

Provavelmente, a maneira mais fácil é usar o Scala primeiro apenas para testes. Nesse caso, talvez você não precise contar ao seu chefe :-) Se ele perguntar, diga a ele "esse é apenas o meu caso de teste particular, é muito mais fácil e rápido usar o Scala para ele". Quando você (e sua organização) tiver experiência suficiente com o Scala, poderá começar a usá-lo para o código 'real'.

Do ponto de vista das empresas, é melhor ficar com Java se não houver uma vantagem distinta que eles obterão migrando para o Scala. É mais fácil para eles contratar programadores Java para criar e manter o aplicativo. Você pode sair depois de implementar tudo no Scala :-) Sem ofensas :-)

Faça com que seu chefe leia experiências como esta:

1. Atualmente, estou fazendo a maioria das minhas coisas em Scala agora. (Devo mencionar que acho que Scala é a melhor coisa desde a invenção da roda há algum tempo. :-D)

   Na minha humilde opinião, é a única linguagem que realmente permite que as pessoas escolham a melhor abordagem para uma tarefa sem uma divisão desnecessária entre abordagens (mais) orientadas a objetos e (mais) funcionais.

   Olhando para os idiomas que afirmavam algo assim antes, basicamente posso ver dois campos de design de idiomas concorrentes:

   • Os do lado orientado a objetos que viram que a programação funcional ganhou alguma força ultimamente e pensaram "Bem, nós realmente não entendemos essa coisa funcional, mas vamos adicionar um pouco de açúcar sintático sofisticado à nossa linguagem, para que possamos afirmar que ela é funcional também!" (exemplos: Java, Python)

   • Depois, aqueles do lado funcional, que pensaram "Bem, nossa abordagem funcional é muito superior a qualquer outra coisa e essa bobagem orientada a objetos é irritante, mas vamos colocar algumas palavras-chave adicionais em nossa linguagem, que farão com que nossa linguagem escape da academia com certeza ! " (exemplos: F #, OCaml)

   Os designers de Scala unificaram muitas abordagens vindas de ambos os lados e criaram uma linguagem bem projetada, que é - na minha humilde opinião - a maior diferença para outras linguagens, que decidiram adotar a abordagem "Frankenstein" para o design de linguagem de programação.

2. Tendo feito apenas coisas menores com o Lift ainda e apenas uma experiência superficial com o Rails e o Django, tenho que admitir que na maioria das vezes eu me perguntava por que algo no Lift funcionava de maneira diferente do que eu esperava, isso se devia ao fato de minhas expectativas serem falha e abordagem de Lift superior.

   O Lift certamente não é uma "introdução fácil ao Scala", mas aprender como o Lift funciona foi quase tão gratificante quanto aprender o Scala antes dele.

   A capacidade de ter uma visão "limpa" sem nenhuma lógica é uma grande melhoria para outras estruturas que afirmavam o mesmo, mas ficaram aquém disso. O suporte literal XML da Scala possibilita verificar a boa formação da sua resposta: O compilador comprova, em tempo de compilação, que você emite apenas XML bem formado para um cliente.

3. O Lift é uma tecnologia viável e, no momento, a única abordagem real se você deseja criar aplicativos da Web que pareçam, se sintam e se comportem como aplicativos de desktop "reais" sem escrever você mesmo quantidades insanas de código.

[ Fonte ]

Nos últimos dois anos, progredimos de maneira justa ao longo dessa jornada no guardian.co.uk - nossa Plataforma Aberta é baseada no Scala, nosso CMS principal (originalmente em Java) está gradualmente incorporando mais Scala (em breve estamos mudando de Maven para o SBT para nossa compilação) e tem sido uma experiência maravilhosa - realmente revigorando nossos desenvolvedores, alguns dos quais estavam ficando um pouco cansados ​​do Java :)

Encorajo-vos a ler estes dois artigos sobre nossa transição e talvez usá-los como evidência de apoio com seus cabelos pontudos:

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

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

Algumas dicas rápidas:

• Comece escrevendo seus testes no Scala - para que você se familiarize com o idioma, aumente sua confiança nele e não tenha que vencer nenhum medo que possa ter sobre adicionar o tempo de execução aos servidores de produção imediatamente.

• Não peça permissão para experimentar novas tecnologias. Melhor pedir perdão se você precisar :-)

Esta questão mergulha em outra questão. Isso é para que tipos ou projetos a migração para Scala fornece valor agregado? Faço Java no meu trabalho do dia-a-dia, mas sonho com o dia em que posso usar o Scala "com raiva".

Algumas respostas para minha própria pergunta:

• Problemas para os quais a simultaneidade baseada em ator proporcionaria grande benefício (Akka)

• Aplicativos da Web que têm dados enviados a eles via COMET (Lift)

Quaisquer outras idéias ou experiências ainda melhores?

Estou escrevendo testes para meus aplicativos Java no Scala e concordo que é um bom lugar para começar. Minha cobertura de teste é melhor porque é mais rápida e fácil escrevê-las (também desde que uso o Scala, concentro-me de bom grado em escrever mais testes).

Também comecei a fazer protótipos e POCs descartáveis ​​em Scala praticamente exclusivamente. Tento conscientizar os gerentes e supervisores de que usei o Scala para esses eventos pontuais e enfatizo que consegui colocar algo em funcionamento rapidamente por causa do Scala. Precisávamos (bem, meio que precisávamos) de um aplicativo da web para rastrear nosso jogo de elefante branco para festas - 1,5 horas com Scalatra e MongoDB e todo o meu departamento está vendo esse aplicativo e perguntando sobre ele. Vamos ser sinceros, você nunca chegará a lugar nenhum descrevendo aos gerentes o quanto a linguagem é mais expressiva ou que seu modelo de concorrência é muito melhor. Mas se você mostrar a eles que pode fazer mais rapidamente, ganha terreno.

Mas acho que a maior parte é animar os desenvolvedores com o Scala. Tenho certeza de que todos trabalhamos com desenvolvedores que não acompanham ativamente as novas tecnologias e, às vezes, é difícil deixar essas pessoas empolgadas em fazer algo novo (por que eu realmente não entendo). Mostrar a essas pessoas alguns benefícios do Scala (experimente o REPL) é essencial. Se você tem desenvolvedores suficientes falando sobre os mesmos benefícios da produtividade, é muito mais provável que o Scala seja adotado oficialmente em sua organização.

Divulgar e divulgar esse esforço de base é o meu principal objetivo em 2011. Veremos como ele se desenrola, porque mal posso esperar pelo dia em que usar o Scala para a maior parte do meu trabalho.

Eu estou querendo saber por que escolher um ou outro? Por que decidir jogar o Java pela porta e seguir o Scala até o fim?

Não existe a ferramenta perfeita para o trabalho. Não há razão para lançar completamente o conhecimento em um idioma e substituí-lo por outro.

Eu não gostaria de trabalhar (mais) em uma empresa que se concentra em um idioma ou ambiente, tbh. É melhor saber muitas coisas e escolher a ferramenta certa para o trabalho.

Além disso, é difícil, se não impossível, fazer com que sua organização mude para o Scala completamente. Em vez disso, tentaria realizar alguns projetos (ou mesmo partes de projetos) no Scala, em vez de optar pela abordagem do tudo ou nada. Você pode, por exemplo, optar por testar seu código Java com o Specs2, que possui uma sintaxe bastante agradável em comparação com a antiga JUnit antiga - e também não é um código e paradigmas complexos, confusos e difíceis de Scala, apenas um açúcar sintático para definir o comportamento do seu aplicativo. .

Uma boa maneira é demonstrar duas versões do mesmo programa. Ao fazer isso, você pode mostrar aos seus colegas (na prática) o Scala Expressividade . Fazer o mesmo com outros problemas (XML, simultaneidade etc.) pode demonstrar os benefícios do uso do Scala em vez do Java para resolver problemas específicos.

Obviamente, não espere que a migração ocorra em um dia. Há muitos problemas que você pode subestimar: a curva de aprendizado, a base de código existente etc.