Кто-нибудь из организаций начал переход с Java на Scala? Если да, как ты это делаешь? Что я могу сделать, чтобы побудить моих коллег сделать то же самое?
Кто-нибудь из организаций начал переход с Java на Scala? Если да, как ты это делаешь? Что я могу сделать, чтобы побудить моих коллег сделать то же самое?
Ответы:
Вероятно, самый простой способ - сначала использовать Scala только для тестирования. В этом случае вам, возможно, даже не придется говорить своему боссу :-) Если он спросит, скажите ему: «Это всего лишь мой личный тестовый случай, гораздо проще и быстрее использовать для этого Scala». Когда у вас (и у вашей организации) достаточно опыта работы со Scala, вы можете начать использовать его для «реального» кода.
С точки зрения компаний, лучше остаться с Java, если нет особого преимущества, которое они получат, перейдя на Scala. Им проще нанять Java-программистов для создания и поддержки приложения. Вы можете просто уйти после внедрения всего в Scala :-) Без обид :-)
Попросите вашего босса прочитать такой опыт:
В настоящее время я делаю большинство своих вещей в Scala прямо сейчас. (Должен отметить, что я считаю, что Scala - лучшая вещь с момента изобретения колеса некоторое время назад. :-D)
По моему скромному мнению, это единственный язык, который действительно позволяет людям выбирать лучший подход к задаче без какого-либо ненужного разделения между (более) объектно-ориентированным и (более) функциональным подходами.
Глядя на языки, которые утверждали что-то подобное раньше, я в основном вижу два конкурирующих языковых лагеря дизайна:
Те из объектно-ориентированной стороны, которые увидели, что функциональное программирование в последнее время приобрело некоторую популярность, и подумали: «Ну, мы на самом деле не понимаем эту функциональную штуку, но давайте добавим немного необычного синтаксического сахара в наш язык, поэтому мы можем утверждать, что он функциональный тоже!" (примеры: Java, Python)
Затем те из функциональной стороны, которые подумали: «Ну, наш функциональный подход намного превосходит все остальное, и эта объектно-ориентированная ерунда раздражает, но давайте добавим несколько дополнительных ключевых слов в наш язык, которые наверняка заставят нашу академию ускользать от языка». !» (примеры: F #, OCaml)
Дизайнеры Scala объединили множество подходов, исходящих с обеих сторон, и создали какой-то хорошо продуманный язык, который, по моему скромному мнению, является самым большим отличием от других языков, которые решили использовать подход Франкенштейна к проектированию языков программирования.
Сделав с Lift только небольшие вещи и только поверхностный опыт с Rails и Django, я должен признать, что большую часть времени, когда я удивлялся, почему что-то в Lift работает не так, как я ожидал, это было связано с тем, что мои ожидания были недостатки и подход Лифта превосходят.
Lift, конечно, не «простое введение в Scala», но изучение работы Lift было почти таким же полезным, как изучение Scala до него.
Возможность иметь «чистое» представление без какой-либо логики в нем является большим улучшением для других платформ, которые утверждали то же самое, но не достигли этого. Поддержка литералов XML в Scala позволяет проверить правильность вашего ответа: во время компиляции компилятор докажет, что вы отправляете клиенту только правильно сформированный XML.
Lift является жизнеспособной технологией и на данный момент единственным реальным подходом, если вы хотите создавать веб-приложения, которые выглядят, чувствуют и ведут себя как «настоящие» настольные приложения без написания безумных объемов кода самостоятельно.
[ Источник ]
За последние два года мы продвинулись честно в этом путешествии на 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 - так вы сможете познакомиться с языком, повысить свою уверенность в нем и не избавляться от каких-либо опасений, связанных с добавлением среды выполнения на рабочие серверы.
Не спрашивайте разрешения попробовать новые технологии. Лучше попросить прощения, если придется :-)
Этот вопрос увлекся другим вопросом. То есть для каких видов или проектов миграция в Scala обеспечивает дополнительную ценность? Я работаю на Java каждый день, но мечтаю о том, как смогу использовать Scala «в гневе».
Пара отвечает на мой вопрос:
Проблемы, для которых параллелизм на основе акторов принесет большую пользу (Akka)
Веб-приложения, которые передают данные через COMET (Lift)
Любые другие идеи или еще лучше?
Я пишу тесты для своих Java-приложений в Scala и согласен, что это хорошее место для начала. Мое тестовое покрытие лучше, потому что их легче и быстрее писать (также, поскольку я использую Scala, я охотно больше фокусируюсь на написании тестов).
Я также начал делать прототипы и одноразовые POC в Scala. Я стараюсь сделать так, чтобы менеджеры и супервайзеры как можно лучше осознавали, что я использовал Scala для этих уникальных выступлений, и подчеркиваю, что я смог быстро что-то запустить и запустить благодаря Scala. Нам понадобилось (ну, в некотором роде) веб-приложение для отслеживания нашей игры «Белый слон» на праздничной вечеринке - 1,5 часа с Scalatra и MongoDB, и весь мой отдел просматривает это приложение и спрашивает об этом. Посмотрим правде в глаза, вы никогда не получите описания менеджерам, насколько выразительнее язык или что его модель параллелизма намного лучше. Но если вы покажете им, что вы можете сделать больше быстрее, вы наберете силу.
Но я думаю, что самая большая часть волнует разработчиков о Scala. Я уверен, что мы все работаем с разработчиком, который не идет в ногу с новыми технологиями, и иногда трудно заставить этих людей взволноваться делать что-то новое (почему, я действительно не понимаю). Показывая этим людям некоторые преимущества Scala (попробуйте REPL), это ключ. Если вы получаете достаточно разработчиков, которые жалеют о тех же преимуществах производительности, то у вас гораздо больше шансов официально принять Scala в вашей организации.
Моя основная цель в 2011 году - распространять информацию и добиваться успеха на низовом уровне. Посмотрим, как это получится, потому что я не могу дождаться того дня, когда смогу использовать Scala для основной части моей работы.
Мне интересно, почему выбирают один или другой? Почему решили выбросить Яву за дверь и пройти Скала до конца?
Идеального инструмента для работы не существует. Нет никаких оснований выбрасывать знания по одному языку полностью и заменять его другим.
Я бы не хотел больше работать в компании, которая фокусируется на одном языке или среде. Лучше знать много вещей и выбрать правильный инструмент для работы.
Кроме того, трудно, если не невозможно, заставить вашу организацию полностью перейти на Scala. Вместо этого я бы попытался выполнить некоторые проекты (или даже части проектов) в Scala вместо того, чтобы использовать подход «все или ничего». Например, вы можете попробовать протестировать свой Java-код с помощью Specs2, который имеет довольно приятный синтаксис по сравнению с простым старым JUnit - и это не сложный, запутанный и сложный Scala-код и парадигмы, просто синтаксический сахар для определения поведения вашего приложения ,
Хороший способ - продемонстрировать две версии одной и той же программы. Делая это, вы можете показать своим коллегам (на практике) выразительность Scala . То же самое для других задач (XML, параллелизм и т. Д.) Может продемонстрировать преимущества использования Scala вместо Java для решения конкретных задач.
Конечно, не ожидайте, что миграция произойдет за один день. Есть много проблем, которые вы можете недооценивать: кривая обучения, существующая кодовая база и т. Д.