Помимо проблем с производительностью, почему Java по-прежнему выбирается вместо Groovy/JRuby и т. Д.?
[Это эмпирический вопрос о состоянии дел: я НЕ спрашиваю, является ли Java круче или менее крутым, чем динамические языки, работающие в JVM.]
Помимо случаев, когда производительность является основным фактором принятия решения, компании / разработчики по-прежнему охотно выбирают Java вместо Groovy, JRuby или Jython?
Изменить: Если ответ "да", почему?
Личное примечание: причина, по которой я спрашиваю, состоит в том, что, хотя я делаю некоторую часть моей профессиональной работы в Ruby (пока не на JRuby), в моих личных проектах я использую Java. Хотя я писал нетривиальные приложения на Groovy, я предпочитаю Java, но мне интересно, должен ли я просто преодолеть это и делать все на Groovy. Мне нравится Java, потому что я чувствую, что статическая типизация экономит мое время и помогает рефакторингу. (Нет, я не знаком со Scala.) Однако я чувствую, что этот очень эмпирический вопрос о программировании по теме может повлиять на мое решение.
6 ответов
Не статически типизированные языки плохо масштабируются в смысле обслуживания. До нескольких десятков тысяч строк кода они обслуживаемы. Прошлое, что они просто требуют больше усилий для поддержания, перефакторинга или обновления. Это справедливо для любых нестатических типизированных языков: 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?
Потому что компании по своей природе консервативны. Они не меняют технологии, потому что они крутые или даже классные. Они неохотно меняются, когда есть разумная причина для этого. Ранние усыновители платят очень тяжелые штрафы за то, что они были ранними
Изменить: это не "инерция" в уничижительном смысле, как "нет причин избегать изменений, кроме сопротивления изменениям", но в смысле благоразумия. Компании вправе не отказываться от того, что работает, до тех пор, пока не появится нечто, что доказуемо лучше.
И не в том, что "делает разработчиков счастливыми, потому что это круто", чувство лучшего, а в том, что касается более быстрого и надежного удовлетворения любых бизнес-требований, которые способствуют развитию организации.
Java предлагает:
Большая база обученных, опытных разработчиков. Достаточно сложно найти людей, которые могут хорошо заниматься разработкой программного обеспечения, не выбирая язык, который существует не так давно. А обучение людей на новом языке стоит дорого, как времени, так и денег.
Признание бренда и легко проверенный послужной список успешно завершенных проектов. Это не то, что надо издеваться: если я скажу высшему руководству, что начинаю проект на каком-то отличном новом языке, о котором они никогда не слышали, я должен обучить их этому, и они оценят это как риск. С любым "установленным" языком я могу пропустить этот шаг.
Хорошо зарекомендовавшие себя, зрелые инструменты поддержки и поддержка сторонних производителей.
Эти преимущества возникают при любом сравнении между давно установленным языком и новым, а не только Java и вашим списком. Я ожидаю, что однажды Groovy и др. Станут общепринятым языком, и будут люди, задающие тот же вопрос о каком-то более новом, более блестящем языке. Это цикл. Это было так дольше, чем я был в бизнесе.
Помимо случаев, когда производительность является основным фактором принятия решения, компании / разработчики все еще охотно выбирают Java вместо Groovy, JRuby или JPython?
Да, и я считаю, что основной причиной является инерция со стороны разработчика или компании:
- Компания: существующие инвестиции в Java (с точки зрения навыков персонала и инфраструктуры), риски изменений воспринимаются как перевешивающие преимущества
- Разработчик: доступно множество рабочих мест на Java, так зачем же изучать другой язык?
Нехватка доступных ресурсов, вероятно, является еще одной причиной, хотя это проблема курицы с яйцом (или мексиканское противостояние, или самоисполняющееся пророчество, или что-то еще). Я полагаю, что многие компании смотрят Groovy, Jython и т. Д., Но ждут, когда они станут более широко распространенными, прежде чем сделать решающий шаг. Очевидно, что, откладывая усыновление, они усугубляют проблему нехватки ресурсов.
Личное В стороне
Я провел последний год, работая разработчиком Groovy/Grails. Я недавно сменил работу и сейчас работаю разработчиком на Java 1.4, и (по сравнению с программированием на Groovy) это так же приятно, как выбивать глаза ржавой ложкой.
Статическая типизация хороша тем, что она облегчает проверку во время компиляции и инструменты анализа кода, такие как FindBugs, но никоим образом не компенсирует огромное количество (стандартного) кода, необходимого для выполнения простейших задач при написании Java (особенно если вы использовать версию более раннюю, чем 1.5).
Я могу рассказать вам, что происходит в моей компании. Наше текущее приложение сделано в Java, но мы начали переход на grails/groovy, и, скорее всего, это будет платформа для следующего поколения наших продуктов.
Поскольку вы задаете эмпирический вопрос, а я предполагаю, что ищем эмпирические ответы:
Помимо случаев, когда производительность является основным фактором принятия решения, компании / разработчики все еще охотно выбирают Java вместо Groovy, JRuby или JPython?
Да.
Я не думаю, что есть что-то еще, чтобы сказать.