Как вы поощряете вашу организацию перейти с Java на Scala? [закрыто]

15

Кто-нибудь из организаций начал переход с Java на Scala? Если да, как ты это делаешь? Что я могу сделать, чтобы побудить моих коллег сделать то же самое?

нанда
источник
пожалуйста, добавьте scala и миграцию в тег, если у вас есть для этого полномочия
nanda
9
Возможно, вы должны объяснить, почему
TheLQ
Вам нужно достаточно собственных знаний, чтобы обеспечить «достаточно высокий» фактор шины.

Ответы:

15

Вероятно, самый простой способ - сначала использовать Scala только для тестирования. В этом случае вам, возможно, даже не придется говорить своему боссу :-) Если он спросит, скажите ему: «Это всего лишь мой личный тестовый случай, гораздо проще и быстрее использовать для этого Scala». Когда у вас (и у вашей организации) достаточно опыта работы со Scala, вы можете начать использовать его для «реального» кода.

Томас Мюллер
источник
Это были мои мысли именно для миграции с C # на F #.
GregC
7

С точки зрения компаний, лучше остаться с Java, если нет особого преимущества, которое они получат, перейдя на Scala. Им проще нанять Java-программистов для создания и поддержки приложения. Вы можете просто уйти после внедрения всего в Scala :-) Без обид :-)

Компьютерщик
источник
1
Обычная Ява здесь, чтобы остаться. Скала может или не может. Пока рано говорить.
«Легче нанимать разработчиков Java», вероятно, правда. Но найм тех, кого «легко нанять», может быть не самым дешевым способом завершить ваш проект.
Кевин Клайн
7

Попросите вашего босса прочитать такой опыт:

  1. В настоящее время я делаю большинство своих вещей в Scala прямо сейчас. (Должен отметить, что я считаю, что Scala - лучшая вещь с момента изобретения колеса некоторое время назад. :-D)

    По моему скромному мнению, это единственный язык, который действительно позволяет людям выбирать лучший подход к задаче без какого-либо ненужного разделения между (более) объектно-ориентированным и (более) функциональным подходами.

    Глядя на языки, которые утверждали что-то подобное раньше, я в основном вижу два конкурирующих языковых лагеря дизайна:

    • Те из объектно-ориентированной стороны, которые увидели, что функциональное программирование в последнее время приобрело некоторую популярность, и подумали: «Ну, мы на самом деле не понимаем эту функциональную штуку, но давайте добавим немного необычного синтаксического сахара в наш язык, поэтому мы можем утверждать, что он функциональный тоже!" (примеры: Java, Python)

    • Затем те из функциональной стороны, которые подумали: «Ну, наш функциональный подход намного превосходит все остальное, и эта объектно-ориентированная ерунда раздражает, но давайте добавим несколько дополнительных ключевых слов в наш язык, которые наверняка заставят нашу академию ускользать от языка». !» (примеры: F #, OCaml)

    Дизайнеры Scala объединили множество подходов, исходящих с обеих сторон, и создали какой-то хорошо продуманный язык, который, по моему скромному мнению, является самым большим отличием от других языков, которые решили использовать подход Франкенштейна к проектированию языков программирования.

  2. Сделав с Lift только небольшие вещи и только поверхностный опыт с Rails и Django, я должен признать, что большую часть времени, когда я удивлялся, почему что-то в Lift работает не так, как я ожидал, это было связано с тем, что мои ожидания были недостатки и подход Лифта превосходят.

    Lift, конечно, не «простое введение в Scala», но изучение работы Lift было почти таким же полезным, как изучение Scala до него.

    Возможность иметь «чистое» представление без какой-либо логики в нем является большим улучшением для других платформ, которые утверждали то же самое, но не достигли этого. Поддержка литералов XML в Scala позволяет проверить правильность вашего ответа: во время компиляции компилятор докажет, что вы отправляете клиенту только правильно сформированный XML.

  3. Lift является жизнеспособной технологией и на данный момент единственным реальным подходом, если вы хотите создавать веб-приложения, которые выглядят, чувствуют и ведут себя как «настоящие» настольные приложения без написания безумных объемов кода самостоятельно.

[ Источник ]

missingfaktor
источник
3

За последние два года мы продвинулись честно в этом путешествии на guardian.co.uk - наша открытая платформа построена на Scala, наша основная CMS (изначально на Java) постепенно включает в себя все больше Scala (мы скоро переходим от Maven для SBT для нашей сборки), и это был замечательный опыт - по-настоящему бодрящий наших разработчиков, некоторые из которых стали немного измученными с Java :)

Я бы посоветовал вам прочитать эти две статьи о нашем переходе и, возможно, использовать их в качестве подтверждающих доказательств с вашими заостренными волосами:

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

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

Несколько быстрых советов:

  • Начните с написания своих тестов в Scala - так вы сможете познакомиться с языком, повысить свою уверенность в нем и не избавляться от каких-либо опасений, связанных с добавлением среды выполнения на рабочие серверы.

  • Не спрашивайте разрешения попробовать новые технологии. Лучше попросить прощения, если придется :-)

Роберто Тайли
источник
+1! для «Не проси разрешения попробовать новые технологии. Лучше попросить прощения, если придется :-)»
Джорджио
2

Этот вопрос увлекся другим вопросом. То есть для каких видов или проектов миграция в Scala обеспечивает дополнительную ценность? Я работаю на Java каждый день, но мечтаю о том, как смогу использовать Scala «в гневе».

Пара отвечает на мой вопрос:

  • Проблемы, для которых параллелизм на основе акторов принесет большую пользу (Akka)

  • Веб-приложения, которые передают данные через COMET (Lift)

Любые другие идеи или еще лучше?

user3463
источник
1

Я пишу тесты для своих Java-приложений в Scala и согласен, что это хорошее место для начала. Мое тестовое покрытие лучше, потому что их легче и быстрее писать (также, поскольку я использую Scala, я охотно больше фокусируюсь на написании тестов).

Я также начал делать прототипы и одноразовые POC в Scala. Я стараюсь сделать так, чтобы менеджеры и супервайзеры как можно лучше осознавали, что я использовал Scala для этих уникальных выступлений, и подчеркиваю, что я смог быстро что-то запустить и запустить благодаря Scala. Нам понадобилось (ну, в некотором роде) веб-приложение для отслеживания нашей игры «Белый слон» на праздничной вечеринке - 1,5 часа с Scalatra и MongoDB, и весь мой отдел просматривает это приложение и спрашивает об этом. Посмотрим правде в глаза, вы никогда не получите описания менеджерам, насколько выразительнее язык или что его модель параллелизма намного лучше. Но если вы покажете им, что вы можете сделать больше быстрее, вы наберете силу.

Но я думаю, что самая большая часть волнует разработчиков о Scala. Я уверен, что мы все работаем с разработчиком, который не идет в ногу с новыми технологиями, и иногда трудно заставить этих людей взволноваться делать что-то новое (почему, я действительно не понимаю). Показывая этим людям некоторые преимущества Scala (попробуйте REPL), это ключ. Если вы получаете достаточно разработчиков, которые жалеют о тех же преимуществах производительности, то у вас гораздо больше шансов официально принять Scala в вашей организации.

Моя основная цель в 2011 году - распространять информацию и добиваться успеха на низовом уровне. Посмотрим, как это получится, потому что я не могу дождаться того дня, когда смогу использовать Scala для основной части моей работы.

Janx
источник
1

Мне интересно, почему выбирают один или другой? Почему решили выбросить Яву за дверь и пройти Скала до конца?

Идеального инструмента для работы не существует. Нет никаких оснований выбрасывать знания по одному языку полностью и заменять его другим.

Я бы не хотел больше работать в компании, которая фокусируется на одном языке или среде. Лучше знать много вещей и выбрать правильный инструмент для работы.

Кроме того, трудно, если не невозможно, заставить вашу организацию полностью перейти на Scala. Вместо этого я бы попытался выполнить некоторые проекты (или даже части проектов) в Scala вместо того, чтобы использовать подход «все или ничего». Например, вы можете попробовать протестировать свой Java-код с помощью Specs2, который имеет довольно приятный синтаксис по сравнению с простым старым JUnit - и это не сложный, запутанный и сложный Scala-код и парадигмы, просто синтаксический сахар для определения поведения вашего приложения ,

Ктулху
источник
0

Хороший способ - продемонстрировать две версии одной и той же программы. Делая это, вы можете показать своим коллегам (на практике) выразительность Scala . То же самое для других задач (XML, параллелизм и т. Д.) Может продемонстрировать преимущества использования Scala вместо Java для решения конкретных задач.

Конечно, не ожидайте, что миграция произойдет за один день. Есть много проблем, которые вы можете недооценивать: кривая обучения, существующая кодовая база и т. Д.

sakisk
источник