Застрял с JVM, Sick of Java... Куда пойти?

В течение следующих 3 лет мне придется работать с JVM (требование проекта), используя очень специфический сторонний API. Они хотят Java, но мне дали свободу действий, чтобы отойти от Java. Я надеялся, что мы сможем вернуться к платформе .NET, чтобы я мог разработать код в F #, будучи абсолютно влюбленным в OCaml. Разработка .NET была прервана нашим клиентом. Это не выход.

Я обратился к тому, чтобы смотреть, читать и пихать блоги или форумы по программированию, пытаясь понять, какой язык может понравиться мне далее: Scala или Clojure. Кажется, у них самая большая база сообщества/болельщиков. Будучи опытным с ML-языками, я вижу много людей, которые сравнивают Scala с ML. Однако при проведении такого сравнения есть некоторые реальные скептики. Если бы Scala был близок к ML, моя производительность и кривая обучения выиграли бы от этого переключателя.

Интернет полна дезинформации и удивляется, если я страдаю от такого. Мне не нравится синтаксис Lisp (не делайте мне больно!), Но если Scala имеет бородавки, которые я читаю (плохая поддержка IDE, флюс, модуль тестирования модулей, проблемы с производительностью) Мне интересно, Clojure - лучший вариант. Я хочу быть продуктивным из ворот, используя функции в качестве объектов первого класса и минимизируя боль concurrency.

Так или иначе, прежде чем я потрачу слишком много времени в Интернете и не работаю... Я застрял в JVM, устал от Java и задался вопросом, куда идти?

ОТВЕТЫ

Ответ 1

Вы считали Groovy? Я не думаю, что он такой же функциональный, как Scala/Clojure, но он, безусловно, намного более функциональный, чем Java **. В общем, я могу выполнить ту же работу в Groovy примерно с 50% кода, который мне понадобился бы на Java.

Это связано с тем, что Groovy синтаксически похож на Java и обеспечивает беспрепятственный доступ к библиотекам JDK, но добавление множества языковых функций (закрытие, метапрограммирование, свойства) и динамическое типирование устраняет почти все связанные с шаблоном с программированием на Java.

** Я имею в виду функциональность в смысле "функционального программирования", а не "правильную работу"

Ответ 2

По-моему, оба Clojure и Scala не имеют большой поддержки IDE, если это действительно важно для вас. Тем не менее, вот что я могу собрать из своего чтения и опыта.

Scala профи

  • Быстрее, чем Clojure, благодаря более статической типизации
  • Ближе к ML (синтаксис, программирование по типу)
  • API API с более высоким стандартом API (Clojure) развиваются очень медленно, потому что они хотят, чтобы они находили лучшие идиомы, прежде чем публиковать их. Тем не менее, Clojure все еще имеет полуофициальные дополнительные API)
  • Улучшенные методы интеграции с типичным набором Java-инструментов (Clojure все еще делает некоторые варианты, поэтому менее прочно установлены в этом отношении)
  • Старее чем Clojure (но Clojure построен поверх очень старого и проверенного ядра: Lisp)
  • Люди говорят, что у него есть шансы достичь основного, в то время как они не будут говорить об этом Clojure

Clojure профи

  • Невероятно легкий, быстрый и правильный concurrency благодаря основанным на MVCC STM и другим механизмам concurrency
  • Неизменяемость по умолчанию помогает делать правильные вещи в первую очередь
  • Более стабильный стандартный API
    • Когда что-то меняется, обычно вам не нужно переписывать какой-либо существующий код
    • (Scala коллекции снова переделываются на 2.8)
    • (Я также где-то читал, что общеизвестно, что реализация Scala Actors нуждается в переосмыслении и переписывании.)
  • Легче учиться (маленький язык, будучи (очень чистым) Lisp)
  • Возможность для вас расти, изучая что-то другое.
  • Clojure производительность со временем улучшится; есть еще место для хороших оптимизаций в компиляторе
  • Scala привязка к Java кажется более ограниченной, чем Clojure (взаимодействия между Scala и системами статического типа Java). Иногда можно сказать то же самое о Clojure (поддержка Object-Orientation не соответствует 1:1, но поддержка для этого скоро улучшится)
  • У Rich Hickey есть подарок для выбора, который ставит Clojure в положение наличия технических ведущих функций, которые будут приняты другими языками в последующие десятилетия. И у него также есть подарок для объясняющий их. Поэтому используйте их сегодня в Clojure или ждите, чтобы использовать их на другом языке за несколько лет.:)

В распределенном concurrency

Если ваши потребности concurrency распределены, Clojure еще ничего не имеет для этого, если вы не запускаете его поверх Terracotta или что-то подобное, и в этом случае вы сможете использовать все его concurrency функции. Если вы это сделаете, вы получите лучший распределенный опыт concurrency, чем с Scala Актерами, IMO.

Заключение

IMO Scala пытается сделать все и успешно выполняет большую часть этого. Clojure не пытается использовать одно и то же, но то, на что он фокусируется, более чем достаточно и преуспевает так хорошо, что большинство людей, действительно знающих Clojure, не захотят вернуться к чему-то другому. Раскрытие: мои личные предпочтения идут, конечно, до Clojure. Надеюсь, я смог быть объективным в том, что я написал.

Ответ 3

Я рассмотрю те моменты, которые вы подняли о Scala.

  • Поддержка IDE:

    Scala не имеет того же уровня или поддержки IDE, что и Java, или, если на то пошло, что F # должен иметь с VS10.

    Тем не менее, он имеет одну из лучших (может быть, даже лучших?) IDE поддерживает JVM, вне Java. Сейчас NetBeans достаточно хорош, и люди постоянно говорят, что IDEA все еще лучше (слухи). Однако плагин Eclipse нестабилен.

    Но вы упоминали трехлетний диапазон, а поддержка IDE для Scala должна быть значительно увеличена после выхода Scala 2.8, так как это обеспечит некоторую поддержку компилятора для IDE. Там дата выпуска не определена, но она выглядит в течение следующих шести месяцев, может быть, трех. И плагин Eclipse будет обновлен вместе с ним.

  • В фреймовом модуле тестирования:

    Да, если вы имели в виду, что он яркий, развивающийся и хорошо поддержанный, вместо того, чтобы застаиваться и покидать. ScalaTest, Specs и ScalaCheck - это высококачественные фреймворки, совместимые между собой и совместимые с другими фреймворками и библиотеками Java, такими как JUnit и JMock.

    На самом деле тестовые рамки - это почти детский плакат того, что возможно с помощью Scala.

    EDIT: Scala имеет базовую поддержку unit test в своей стандартной библиотеке (scala.testing.SUnit). Однако, учитывая, что появилось много превосходных, активно поддерживаемых и бесплатных альтернатив, это устарело и, скорее всего, не будет частью библиотеки, поставляемой с Scala 2.8.

  • Проблемы с производительностью:

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

    Во всяком случае, вы можете написать код Scala так же быстро, как Java-код (даже быстрее с некоторыми предстоящими функциями). И вы можете написать Scala код с функциональными функциями почти так же быстро, как Java-код.

Ответ 4

Совершенно откровенно, получить другую работу.

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

Даже если вам удастся получить нужный вам язык, если вы являетесь частью команды (которая, как я полагаю, вы есть), остальной части команды может не понравиться этот язык. Если остальные из них кодируются на Java, а вы в "заполняете пустой" язык программирования, тогда могут возникнуть проблемы.

В конце концов, это не так уж плохо.

Поговорите с вашим боссом, сообщите ему, как вы себя чувствуете. Начните искать альтернативы и получите хороший и профессиональный "отпуск".

Нет причин, по которым у вас не могут быть хорошие отношения с вашим нынешним боссом. Если в конце концов у них будет новый проект .net, вы можете вернуться. Поговорите об этом и с ними. Оставьте ваши двери открытыми.

Ответ 5

Это не игра с нулевой суммой, узнайте их все! ps: Я проголосую за Clojure, я нахожу его самым забавным!

Ответ 6

Вам следует подумать, что вы можете использовать JVM, потому что JVM становится все более популярным для альтернативных языков программирования, чем Java.

Помимо Java там Groovy, Scala, Clojure (диалект Lisp на JVM), JRuby (Ruby на JVM), Jython (Python на JVM), Jaskell (Haskell на JVM), Fan (работает на JVM, а также .NET CLR) и многое другое, а также OCaml-Java, OCaml, который работает на JVM.

Таким образом, в JVM есть много вариантов в языках программирования, от чисто функциональных до простых сценариев и поддерживаемых языков OO.

Ответ 7

Поддержка инструментов для Scala и Clojure может быть незрелой, но она неуклонно улучшается.

Так как вам нравится F #, то Scala, скорее всего, ваш лучший выбор. Я говорю, попробуйте это и сформируйте собственное мнение - вы можете обнаружить, что вещи, о которых люди говорят, - это вещи, которые для вас не важны, или вещи, которые вы можете обойти.

Ответ 8

Не забывайте jRuby и обратите внимание, что IDE является необязательным для не-Java

Думаю, у вас отличная ситуация. Сколько людей получает разрешение на выбор языка реализации? Все, что доступно для JVM с выбранной вами средой, не является большим ограничением.

  • Вам не нужна большая поддержка IDE в менее подробных языках.
  • На языке, столь же мощном, как Ruby без объявлений типа, вам совсем не нужна IDE
  • Scala был разработан специально для лечения verbose-java-blues
  • посчитайте, что вам повезло, что у вас есть три года работы: -)
  • Clojure может быть интересным и обеспечивает функциональные concurrency -самые шаблоны проектирования

Ответ 10

С точки зрения поддержки IDE и других сомнений, которые у вас есть, Clojure не лучше, чем Scala. И для человека с фоном ML/F # (или вообще, что на строго, статически типизированных языках FP), вы определенно найдете Scala гораздо ближе к тому, к чему вы привыкли.

Ответ 11

Если вам нравится ML, вам может понравиться CAL, который является более или менее Haskell 98 для JVM.

Это высокое качество и очень стабильный, и имеет хорошую поддержку IDE на Eclipse, но, к сожалению, больше не находится в активной разработке.