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

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

Статический набор по-прежнему важен.

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

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

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

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

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

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

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

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

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

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

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

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

Личное замечание

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

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

Да, конечно.

Почему компании по-прежнему «охотно» используют Java?

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

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

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

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

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

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

3. Хорошо зарекомендовавшие себя инструменты поддержки и сторонняя поддержка.

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

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

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

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

да.

Не думаю, что есть что еще сказать.