Помимо проблем с производительностью, почему Java по-прежнему выбрана вместо Groovy / JRuby и т. Д.?

Question

[Это эмпирический вопрос о состоянии дел: я НЕ спрашиваю, является ли Java круче или менее крутым, чем динамические языки, работающие в JVM.]

Помимо случаев, когда производительность является основным фактором принятия решения, компании / разработчики все еще охотно выбирают Java вместо Groovy, JRuby или Jython?

Редактировать: Если ответ "да", почему?

Личное примечание: Причина, по которой я спрашиваю, состоит в том, что, хотя я делаю некоторую часть моей профессиональной работы в Ruby (пока не на JRuby), в своих личных проектах я использую Java. Хотя я писал нетривиальные приложения на Groovy, я предпочитаю Java, но Интересно, должен ли я просто преодолеть это и сделать все в Groovy. Мне нравится Java, потому что я чувствую, что статическая типизация экономит мое время и Помогает рефакторинг. (Нет, я не знаком со Scala.) Однако я чувствую, что этот очень эмпирический вопрос о программировании по теме может повлиять на мое решение.

Answer 1

нестатически типизированные языки плохо масштабируются в смысле обслуживания. До нескольких десятков тысяч строк кода они обслуживаемы. Прошлое, что они просто требуют больше усилий для поддержания, перефакторинга или обновления. Это справедливо для любых нестатических типизированных языков: Perl, Python, Groovy, Ruby и т. Д. Инструменты для работы с полмиллиона строк кода Python по сравнению с тем же количеством строк кода на C / C ++ / Java просто не подходят не там. Теперь это правда, что Python составляет примерно от 1/3 до 1/5 числа строк кода в эквивалентной Java-программе. Так что это никогда не будет яблоками и апельсинами, но есть точка отсечения, когда количество строк кода в нестатическом языке будет иметь убывающую отдачу от обслуживания. И все знают, что обслуживание - это то, где истинная стоимость программного проекта всегда была.

Answer 2

Статическая печать все еще важна.

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

Я не хочу спорить, является ли этот аргумент правильным, поэтому я предполагаю, что это так, для этого ответа.

В этом случае есть еще одна проблема: многие магазины не имеют процедур / ноу-хау / правил / руководства для производства достаточного количества высококачественных модульных тестов.

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

Аналогичная проблема существует с двойная отправка :

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

Любой код, который в большинстве случаев вызывает метод с подписью foo(String), может внезапно вызвать foo(Integer) или foo(SomethingElseEntirely), в зависимости только от фактического типа аргумента во время выполнения . На языке Java это никогда не произойдет, потому что точная сигнатура вызываемого метода определяется во время компиляции.

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

Answer 3

Да, очевидно.

Почему компании все еще "охотно" используют Java?

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

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

И не в том, что «радует разработчиков, потому что это круто», чувство лучшего, но с точки зрения более быстрого и надежного удовлетворения любых бизнес-требований, стимулирующих развитие в организации.

Java предлагает:

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

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

3. Хорошо развитые, зрелые инструменты поддержки и поддержка сторонних производителей.

Эти преимущества имеют место при любом сравнении между давно установленным языком и новым, а не только Java и вашим списком. Я ожидаю, что однажды Groovy и др. Станут общепринятым языком, и будут люди, задающие тот же вопрос о каком-то более новом, более блестящем языке. Это цикл. Так было дольше, чем я занимался бизнесом.

Answer 4

Помимо случаев, когда производительность основной фактор решения, сделать компании / разработчики по-прежнему охотно выбрал Java вместо Groovy, JRuby или JPython

Да, и я считаю, что основной причиной является инерция со стороны разработчика или компании:

• Компания : существующие инвестиции в Java (с точки зрения квалификации персонала и инфраструктуры), риски изменений воспринимаются как перевешивающие преимущества
• Разработчик : доступно множество рабочих мест на Java, так зачем же изучать другой язык?

Нехватка доступных ресурсов, вероятно, является еще одной причиной, хотя это является проблемой курицы и яйца (или мексиканское противостояние, или самоисполняющееся пророчество, или что-то еще). Я полагаю, что многие компании смотрят Groovy, Jython и т. Д., Но ждут, когда они станут более широко распространенными, прежде чем сделать решающий шаг. Очевидно, что, откладывая усыновление, они усугубляют проблему нехватки ресурсов.

Личное в стороне

Я провел последний год, работая разработчиком Groovy / Grails. Я недавно сменил работу и сейчас работаю разработчиком на Java 1.4, и (по сравнению с программированием на Groovy) это так же приятно, как выбивать глаза ржавой ложкой.

Статическая типизация хороша тем, что она облегчает проверку во время компиляции и инструменты анализа кода, такие как FindBugs, но никоим образом не компенсирует огромное количество (стандартного) кода, необходимого для выполнения простейших задач при написании Java (особенно если вы используете версию ранее 1.5).

Answer 5

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

Answer 6

Поскольку вы задаете эмпирический вопрос, а я предполагаю, что ищем эмпирические ответы:

Помимо случаев, когда производительность является основным фактором принятия решения, компании / разработчики все еще охотно выбирают Java вместо Groovy, JRuby или JPython?

Да.

Я не думаю, что есть что-то еще, чтобы сказать.