Комментарии 96
Сравнивать количество строк, а не производительность? Интересно кончено.
Количество строк то тоже за уши. На яве видно что специально и try catch везде понапихан (сразу +5 строк же), и бесполезные переменные везде где только можно. Они бы еще открывающую скобку на новую строку переносили, еще бы больше строк было.
Сравнивается все. В первую очередь скорость разработки, скорость работы и стоимость инфры.
Интересные сравнения. В году так 14 писали еще на 7 жабе. А на седьмой без лямд, без стримов естественно было больше кода. Лучше бы с Котлином сравнили
Вся эта "невероятная" скорость разработки на питоне может легко нивелироваться динамической типизацией. Мне случалось разбирать легаси-проект на питоне в бэкенде телекома - и это была пытка. Как раз переписывали с зоопарка из питона и ноды на котлин.
Во-первых, никаких "х3 меньше кода" там не было. Если бизнес-логика навороченная, то это просто так под половичок не заметешь. Самый раздутый код был, кстати,на ноде.
Во-вторых, когда ты не понимаешь, что за тип, черт возьми, пришел к тебе в функцию, и когда ты путешествуешь по всему стеку вызова, чтобы это понять - это адский гандикап. А в половине случаев ты в принципе не можешь узнать, что за тип. Просто какая-то блямба пришла на рестовый эндпоинт, а предыдущий разраб обладал тайным знанием о том, какие проперти у этой блямбы есть. Чтобы разгадать загадку блямбы приходилось ходить аж на ангуляровый фронт - там-то, слава б-гу, был TS и нормальные типы.
Я очень люблю питон и считаю, что программа на нем действительно может выглядеть компактее и выразительнее, чем на дажве. Но! Если сравнивать реальные проекты, компактность кода там достигается как раз счет того, что вы говорите - в жертву было принесено всё что угодно: читаемость, декомпозиция, структуры данных
Когда в Python впилят, наконец, нормальную многопоточность и избавятся от GIL, то вот тогда будет куда интереснее сравнить. Хотя, да, на средних проектах без сверхнагрузок Python выглядит очень неплохо и в нынешнем своем состоянии
И ни слова про типизацию, ошибки, вот это всё
Написать быстро то проблемы нет
Слова были, слова будут, но сейчас слов нет. Статья большая слишком. получилась, вырезали и тема обширная. написал: Эта тема тянет на отдельную публикацию — и в ближайшее время я ею займусь. Пока скажу, что современный Python предлагает полноценный набор инструментов enterprise-уровня
Все необходимое есть. Скину ссылку сюда - как опубликую.
Почему вы сравниваете размер хэлловорлдов, а не реального кода? Так никто не пишет
import json
with open('data.json') as file:
data = json.load(file)
print(data['key']) # Доступ к даннымВ реальном коде это будет функция, которую вызывают из другого кода. А то и класс. Но даже без этого, код за пределами "показать как могу" будет скорее походить на
import json
def main():
with open('data.json') as file:
data = json.load(file
print(data['key']) # Доступ к данным
if __name__ == "__main__":
main()Примере с CSV код на джаве на самом деле не парсит CSV, а только наивно делит по запятым. В реальности значение ячейки может содержать запятую и с этом случае берется в кавычки.
В примере с сортировкой на джаве делается in-place, а в питоне через дополнительные списки
В случае с HTTP вы для питона взяли стороннуюю библиотеку, а для джавы - нет. Взяли бы тогда уж urllib.request. Либо попробуйте для разнообразия туда добавить типизацию данных и сравнить, например, мой dataclass-rest и retrofit.
Для асинхронной обработки вы использовали разную модель многозадачности. Корректнее было взятьThreadPoolExecutor.
Я не уверен насчет обработки иключений в джаве, очень много визуального мусора потому что в джаве вы добавили обработку checked исключений, а в питоне оставили программе падать. В реальном коде, вероятно вы бы и в питоне стали их обрабатывать, или дали джава фреймворку ловить всё (сорри, с джавой не работал, там же фреймворк может сам ловить Exсeption и кидать 500?)
это только для примера. исследовались реальные проекты, причем несколько исследований привожу. они говорят что на ява дольше в 3 раза писать
С тем же эффектом "для примера" можно было сравнить print("hello world") с enterprise level hello world. Если ваш код не делает то же самое, то смысла сравнивать его по прочим параметрам смысла особо нет.
Да в питоне на аннотации typing'а смотришь и уже дурно от одного вида кода.
Почему вы сравниваете размер хэлловорлдов, а не реального кода?
Так зато скорость исполнения замеряется, где много ввода вывода. :сарказм:
Надеюсь, топика за такую публичную софистику уволят =)
А если я сделаю так:
public class JsonParser {
public static void main(String[] args) throws IOException {
var jsonObject = new JSONObject(new String(Files.readAllBytes(Paths.get("data.json"))));
System.out.println(jsonObject.getString("key"));
}
}Да, знаю, код не красивый, но мы же размер строк сравниваем. 🙂
Это просто пример. Можно написать максимально коротко и максимально не понятно.
Поинт в исследованиях которые изучали многие проекты.. и они говорят что на java дольше в 3 раза.
Если вот это вам понятно
import json
with open("data.json", "r", encoding="utf-8") as file:
data = json.load(file)
print(data["key"])А вот это уже максимально непонятно
public class JsonParser {
public static void main(String[] args) throws IOException {
var jsonObject = new JSONObject(new String(Files.readAllBytes(Paths.get("data.json"))));
System.out.println(jsonObject.getString("key"));
}
}То даже не знаю, как мягче сказать. Может в консерватории что-то поменять? Ну и да, давайте под этот коммент еще один скриншот с "исследованиями".
На котлине вообще идентичный код можно написать, если чтение джейсона абстрагировать. Но тоже, наверное, максимально непонятно
open("data.json").let { json ->
println(json["key"])
}
public class JsonParser {
public static void main(String[] args) throws IOException {
System.out.println(new JSONObject(new String(Files.readAllBytes(Paths.get("data.json")))).getString("key"));
}
}А уж если это ещё и на Котлин переписать =):
fun main(): Unit = println(JSONObject(String(Files.readAllBytes(Paths.get("data.json")))).getString("key"))
Можно еще как минимум так упростить:
fun main(): Unit = println(JSONObject(Files.readString(Paths.get("data.json"))).getString("key"))
На котлине уже сто лет как делают так
import kotlinx.serialization.Serializable
@Serializable
data class Data(val a: Int, val b: String)
fun main() {
val obj = Json.decodeFromString<Data>("""{"a":42, "b": "str"}""")
}Думаю, что на Яве тоже тоже Jackson/Gson прикрутят и в две строки парсят
Там ещё какой-то JEP 445 вышел или 463, чтобы анонимные классы писать. Там, глядишь, и в одну строчку код напишем.
Пусть питон обзавидуется.
Зарплату видимо тоже по количеству строк считают ))
На Джаве так никто не пишет. Да и такой код даже близко не показателен. Подозреваю что ваши «исследования» такого же уровня.
Но если цель наговнокодить и выкинуть через пару лет берите Питон вопросов нет. Только бизнесу не забудьте это сказать сразу. Что код через пару лет строго выкидывать надо. Бизнесу этот момент интересен.
Мы на Джаве обычно пишет код живущий 10+ лет. И его и после этого выкидывать не надо. Осовременить, порефакторить и еще 10 лет поживает.
поржал с вашего кода
Полезная статья, спасибо! Прямо обоснование выбора стека, с цифрами и деньгами. Пара замечаний: По JSON - есть же orjson, он еще раза в 3 быстрее. Для embedded есть micropython. По играм - Java не лучший выбор точно, из известного вспоминается только Minecraft, и там Java явно в прок не пошла, много технических проблем. А для сервера онлайн игры я бы выбирал между Go и Rust. На Python для игр есть движки для визуальных новелл.
Я вот почитал комменты и мне очень захотелось посмотреть эти исследования, которыми автор яростно отмахивается от комментаторов. И даже если закрыть глаза на то, что исследованиям больше 10 (а одному и то больше 20) лет, то вот интересный факт: доступ к этим исследованиям надо покупать. Либо нужно создать аккаунт, и при этом ввести и найти свой institution, но чтобы я не пытался ввести, сайт не дает. Прикольно, да?
некоторые только такие нашел. большинство просто ссылки. если найдешь лучше - буду благодарен.
стоп. товарищ аффтор, так а почему вы тогда "просто ссылки" вставляете в статью, и потом опираетесь на них? отойду немного в сторону, мне вот как то дипсик во время одного доказательства выдал несуществующую ссылку, так и зачем тогда вы вообще что то искали? сказали бы, "по данным исследования советских и югославских ученых, язык java на 99.9% медленнее, чем python, в качестве опытов была использована задача о половине землекопа."
Видимо, через VPN ссылки доступны
Лень проверять
На полном серьезе есть сомнения что картина выглядит по другому? и что на языке высокого уровня писать медленей? Что касается исследований - должны быть вчерашние?
насчет исследований, нет, но извините, за >10 лет языки сильно так могли измениться, да и конкретно самой статье у меня претензий нет, мне плевать, какой язык быстрее и удобнее в разработке, все равно оба будут использоваться в разных задачах, я не собираюсь доказывать вам, что brainfuck самый быстрый язык. вот только если вы собираетесь давать какие либо ссылки, вы сначала проверяйте, уместны ли они вообще и будут ли работать (в вашем случае - можно ли будет исследования посмотреть просто перейдя по ссылке)
Выскажу непопулярное мнение: Python сейчас - новая Java. И весь тот негатив (порой оправданный) в адрес Python, почти полностью повторяет негатив со стороны плюсовиков в сторону Java в начале нулевых: прожорливая, медленная, сложно оптимизировать. Ну и позитив, тот же: ниже порог вхождения чем у C++, код компактнее, инструментов больше. Области применения тоже совпадают, то что в нулевых писали на Java (энтерпрайз, финтех) сейчас пишут на Python.
Не-а. Как писали на Java / C++ (в зависимости от необходимости), так и продолжают. Python пришёл с AI/ML проектами, это новые короткоживущие проекты, а не замена старых, которым нужна длительная поддержка.
Python в текущем виде - не замена Java, пока с GIL не разберутся в CPython. Скорее Kotlin / Go / Rust вытеснят Java в части новых долгоживущих проектов, в зависимости от решаемой задачи.
Python очень удобен для быстрого написания кода без указания типов, как только появляется типизация, он перестаёт быть таким же удобным.
Да и у Java существенная часть кода генерируется IDE, там разница в LOC на уровне тык-тык-автодополнение отработало.
А я не понял как вы из количества строк получили скорость разработки? Допустим я 6.5 часов думаю над кодом и 1.5 часа пишу. Если мы меняем язык (java -> python), то думать остается столько же, а писать меньше. То есть из 8 часов на джаве получаем 7 часов на питоне. Числа говно, просто из головы взяты, но если вы оцениваете скорость разработки на основе скорости написания букв, пожалуйста приведите ваши числа.
Для справки, если реально учитываем скорость набора, то при длине 100 символов в каждой строке (оценка сверху, в реальности много строк короче) и 200 знаков в минуту (средняя скорость набора согласно гуглу без учета автодополнения), мы получаем что небольшой проект размером 10к строк можно написать за 10 дней. В реальности он может писаться несколько месяцев.
Почему на Java ошибки обработаны, а на python нет?
Количество строк никак не коррелирует со скоростью написания. На python например дольше отлаживать решение и больше ошибок можно допустить.
Выводы - бред. Много игр пишут на java? У python проще и быстрее вызов C кода, чем у Java. (JNI). Java - это низкоуровневое программирование?
Почему выбирается ЯП для следующего проекта между самым медленным и самым затратым по памяти, может лучше взять Go/Rust или C# ?
Это ж какого уровня тогда рядовые сотрудники в KION, если автор техлид?
да не в этом дело. это просто пример. исследования привел, они реальные проекты изучали
Согласно результатам исследования, в большинстве случаев ошибки в коде на Python не обрабатываются должным образом?
Тогда, наряду с показателями стоимости и производительности, целесообразно учитывать дополнительную метрику - частоту фатальных сбоев либо коэффициент нестабильности, отражающий устойчивость системы к ошибкам и изменениям.
Когда лучше выбрать Java: Игры с высокими требованиями к графике.
Надо было читать статью с конца, сэкономил бы время. Хотя примеры сравнения по строкам весьма потешные.
Некоторое время назад мучил GPT чтобы он сделал похожее сравнение между типизированным PHP и Java 21. В одном чате уламывал признать выгодным разработку на PHP, в другом на Java. GPT соглашался с любым утверждением, но я требовал пруфы с цифрами, которых, очевидно, неоткуда было взять. Считали разные сценарии. В итоге оказалось, что ресурсы RAM и CPU влияют на TCO незначительно при разных начальных условия. А вот компетенция разработчиков, инструменты кодогенерации и сборки влияют настолько, что делают сравнение стеков бессмысленным.
ну не знаю. в исследованиях, которые привожу, говорится более конкретней, там много проектов было изучено.
да отстаньте вы со своими исследованиями, вы буквально выше в моем комментарии признали, что по ссылкам исследования платные и недоступные
Мне, кажется, что 20 лет назад еще не было intellij idea и такого количества готовых библиотек, я даже не знаю в чем тогда писали, возможно и компилировали еще каждый класс отдельно. Сейчас инструментарий решает много в производительности и исследовать нужно современные реалии, а не прошлый век. Поэтому количество строк кода вообще не показатель. И jackson может прям из файла читать, не нужно много строк велосипеда писать, врядли кто-то сейчас вручную парсит json и csv файлы. Не понимаю зачем унижать какой-то язык - нравится питон, пожалуйста, пишите, это ваше дело. В продуктовом enterprise часто задача может согласовываться неделю или две, а потом в 20 строк кода решаться за 1 час и что на питоне, сто на java время написания будет одинаковым, а вот общее время выполнения задачи от языка мало будет зависеть.
Ловко сову на глобус натянули. Вопрос только - зачем?
Я так до конца и не понял статья шуточная или на полном серьезе.
ИИ неплохо статьи стал писать.
Три примера.
Аспирантка начала писать код на Python. Первый месяц была счастлива. После второго сказала, что начались проблемы с глюками из-за отсутствия нормальной (статической) типизации. Через три месяца переписала код на C++ и сообщила, что больше к Python для серьёзных проектов никогда не вернётся.
Студент написал на Python код с использованием необходимых математических библиотек для расчётов столкновений высокоэнергетичных частиц. Расчёт занимал 3.5 часа. Переписал код на Rust - расчёт занял 1 секунду!
Смотрим BigData.
На первом месте из известнейших систем Hadoop. Платформа: Java Virtual Machine. В апреле 2008 года Hadoop побил мировой рекорд производительности в стандартизованном бенчмарке сортировки данных — 1 терабайт был обработан за 209 секунд. Но короткие скрипты в подсистеме MapReduce при прототипировании или при единичных запросах пишут на Python.
Номер 2: Apache Spark. Платформа: Java Virtual Machine.
Номер 3: Microsoft Azure HDInsight. Платформа: Java Virtual Machine. Но, как и в Hadoop, короткие скрипты при прототипировании или при единичных запросах пишут на Python.
Вывод: там, где нужна производительность или надёжность, это не про Python. Там, где нужны короткие скрипты и удобные графики и таблицы, а ошибки некритичны, он подходит. И выбирать надо не сферического коня в вакууме, а адекватный набор инструментов под конкретную задачу.
Были ли у нее тесты? Что она думает об управлении памятью в с++? Сколько сегофолтов она умела словить? Статическая типизация это хорошо, но это не панацея, она лишь помогает быстрее находить определнный класс ошибок.
У меня был код на питоне, который раблта час. Я переписал его на питоне и он стал работать 1 секунду. Ну серьёзно, проблема могла быть вообще не в языке, а например в сложности алгоритма. При этом не спорю, на куче задач Раст будет действительно рвать питон.
Питон хорош тем, что он не требует что все было написано на питоне. Огромное количество инструментов, которые используют питонисты написаны совсем не на питоне. Питон нужен чтобы писать высокоуровнеаую логику. В этом его сила
Я присматриваюсь к тому чтобы писать домен на rust. И юнит тесты на нём писать удобно.
А usecases писать на питон и связывать через PyO3: добавил API, дёрнул репозиторий, получил данные, вызвал бизнес логику из домена, дёрнул репозиторий чтобы сохранить результат
Пока только пробую, но вроде неплохо
Если вместо петухона подставить go, плюсы не изменятся, а минусы исчезнут. Нет ни одной причины пихать везде петухон с ненастоящими потоками, когда есть нормальные языки
странно смотреть на сравнение языков с разными нишами: если писать сервис с небольшой нагрузкой, то большинство будет писать его на питоне. Если нужна бОльшая нагрузка или вычисления становятся сложнее, то Java/C#, если же вам нужен прям высоконагруженный сервис, то напишите его на плюсах
Я, конечно, утрирую, но суть это не меняет
Я, конечно, человек довольно далекий от программирования (последний раз лет 10 назад что-то схалтурил на дельфи), но:
1) разве современные IDE типа того джетбрейнс не автодополняют грамотно код, да так, что по первым трем буквам чуть не всю строку выдают? Я уж молчу про ide+ai типа того же Cursor
2) разве нормальный программист стучит по клавишам как герой фильма Пароль рыба-меч? Или все же кодирование занимает от силы 20% времени?
3) насколько я понимаю, типизация в коде/языке это уже как минимум на 50% документированные сорсы, поэтому сопровождать/исправлять/дописывать/переписывать такой код раза в 2 легче (даже если за срок жизни ПО у вас полностью поменяется команда разрабов)
4) И вообще- эти сотни тысяч ентерпрайзов по всему миру настолько тупее вайти отдела МТС, что за 10 лет не догадались почитать ваши исследования и на калькуляторе посчитать насколько выгоднее питон и поэтому до сих пор сидят на джаве?
Думаю, что в реальном проекте на Spring для решения бизнес задач уйдет не намного больше времени, чем на Python, так еще и поддерживать в будущем проще из-за типизации. Хотя и в Python тоже можно затащить что-то похожее на типизацию
Исследования говорят о другом. тут можно что угодно думать, писать, но факты я привел. В пайтон тоже можно взять фреймворк и сравнивать с ним. результат будет примерно таким же.
Буквально очень нетривиально бывает запустить старый питоновский проект. Бут в этом плане работает десятки лет, везде Бут, поэтому пересаживать людей с проекта на проект - просто.
Показалось интересным, что статью разобрали сверху до низу, но никто не оспорил пункт с оплатой Java разработчика. А ведь для бизнеса это самый важный фактор. Ни строчки кода, ни рпс, ни гигабайты так не продать инвестору, как стоимость разработки. Когда у вас стартап и не известно взлетит он или как всегда, очень не хочется вбухивать бюджет в разработку энтерпрайз уровня который с сильно не нулевой вероятностью ляжет на полку. Даже если его потом попытаться продать, то себестоимость может не обрадовать.
Я набрался сил и прочитал что там пишут по ссылкам на которые ТС ссылается через комментарий.
Исследование Нанца, 2015 год. Анализировали 10 языков программирования на 7 задачах из коллекции Rosetta Code. Результат — программы на Python требуют в среднем в 2,7 раза меньше строк кода и в 1,9 раза меньше времени разработки по сравнению с Java.
Читать тут.
Моими словами: Взяли довольно специфичный репозиторий со спортивным программированием на максималках (дай результат потратив любое время на разработку любой ценой) и считали там строчки/память/cpu. Сравнить в нем потенциально возможное выжимание быстродействие из языка или его эффективность по памяти можно, но толку? Результат и так любой угадает с первого раза. Сайт мертв, но поверьте на слово результаты там абсолютно предсказуемые.
Исследование Биссьянде, 2013 год. На этот раз взяли 100 000 проектов с открытым исходным кодом и оценили время, затраченное на разработку эквивалентных функциональных требований. Результат — на реализацию функциональных требований на Python уходит в среднем в 2–3 раза меньше времени, чем на Java.
Читать тут.
Моими словами: Взяли 100.000 случайных (методология выбора случайных странная, но верим) проектов с Гитхаба и оценивали их. Сравнивали показатели популярность и совместное использование языков в одном проекте. И нормировали на размер в строчках. Популярность языков так оценить можно, но не более того.
Исследование Рэя Байшахи, 2014 год. Проанализировали 729 проектов, 80 миллионов строк кода на GitHub и обнаружили, что Python требует значительно меньше кода для выполнения аналогичных задач. Результат — программисты на Python пишут в 2,5 раза меньше строк кода для эквивалентной функциональности по сравнению с Java.
Читать тут.
Моими словами: Снова взяли рандомные проекты с Гитхаба. Считали и классифицировали баги (ишью, с метками или как-то так) нормированные на размер проекта и на тип ошибки. Даже опасность и забагованность программ для каждого языка так оценить не выйдет. Слишком шумный показатель, который зависит слишком много от чего. Просто проеденный грант.
Исследование Лутца Прехельта, 2000 год. В нем 80 программистов решали одинаковую задачу на разных ЯП. Результат — разработчики на Python завершили задачу в среднем в 2,2 раза быстрее, чем разработчики на Java.
Читать тут. На сладкое 2000 год. История, прямо.
Моими словами: Какой-то рандомный чувак написал один и тот же алгоритм на нескольких языках. И собрал какие-то рантайм метрики. Я студентом качественнее работы писал.
Мое экспертное мнение, что ссылки ТС такие же по качеству как его примеры, из моего комментария повыше полностью оправдалось. Ссылки полный треш, просто выглядят значимо пока читать не начнешь.
Отрицание - первая стадия принятия. не нужно обнулять чудой труд исследований, тем более что из не 1 и не 2.
Следуя этой логике у вас первая стадия принятия, или это другое? Исследования бывают низкого качества и бывают устаревшими, в этом аргументе нет никаких манипуляций. Самому свежему из ваших исследований 10 лет (подозреваю что исследованные проекты были еще существенно старше), джава с тех пор 16 версий сменила (про котлин речи нет)
Статья о полезном и таком нечастом ныне прагматичном подходе без тяжелых бенчмарков.
Создавать софт и MVP надо на Python, а потом, и только если взлетело (а 50% проектов фейлятся) и только если вдруг хочется "еще быстрее" - переписывать код на Java. Лучшее из 2-х миров. Потому что в долгосрочной перспективе крупное десктоп JAVA-приложение обойдется дешевле.
Но если новые фичи нужны для продвижения продаж больше чем сами продажи - итерации 2-х ЯП нужно продолжать. Иначе вас обойдут другие, у кого MVP пиштся в 3-5 раз быстрее любых других ЯП.
У Питона, при работе в IDE или JupyterLab с объявлением типов - все хорошо. Даже между отладками - значения переменных не исчезают, ошибиться в типе не получится, как бы красочно ни звучали кейсы со счастливыми аспирантками, перешедшими на С++ в серьезных проектах.
Автор-питонист хотел поджечь Java-жопы, и ему это удалось. При этом пытался немножко выглядеть объективными и профессиональным, но наличие мемасов в статье выдавало Штирлица. А потом в комментах начали поджигать жопу автору. Нравится!
Теперь совсем про другое: про реализацию quicksort на Java, которую автор привёл. Там в partition() два индекса, и для некоторого количества элементов в начале оба индекса будут совпадать, пока эти начальные элементы меньше pivot-а. Представленный алгоритм будет менять элемент самого с собой. В худшем случае, если исходный массив уже отсортирован, будет много лишней работы. Можно добавить if, но он будет напрасно исполняться на том этапе, когда i уже гарантированно меньше j, тоже неприятно.
private static int partition(int[] arr, int low, int high) {
int pivot = arr[high];
int i = low ;
for (int j = low; j < high; j++) {
if (arr[j] <= pivot) {
if (i < j) {
int temp = arr[i];
arr[i] = arr[j];
arr[j] = temp;
}
i++;
}
}Прямо даже не знаю, хоть два цикла делай.
Почему вы реализуете quicksort по разному? Если сделать аналогичную реализацию на Java, то все будет примерно также как и на Python
public static List<Integer> quicksort(List<Integer> arr) {
if (arr.size() <= 1) {
return arr;
}
var pivot = arr.get(arr.size() / 2);
var left = arr.stream().filter(x -> x < pivot).toList();
var middle = arr.stream().filter(x -> x.equals(pivot)).toList();
var right = arr.stream().filter(x -> x > pivot).toList();
var result = new ArrayList<>(quicksort(left));
result.addAll(middle);
result.addAll(quicksort(right));
return result;
}
public static void main(String[] args) {
System.out.println(quicksort(List.of(3, 6, 8, 10, 1, 2, 1)));
}Почему для Python вы не делаете обработку ошибок, но делаете ее для Java хотя могли бы просто добавить ошибку в сигнатуру Java метода, что сильно уменьшило объем кода?
И как правильно вам уже указали в комментариях, такой код в продакшен никто не пишет, а для объективнсости надо сравнивать именно продакшен код.
Имея опыт работы на трех языках Java/Kotlin/Python, могу сказать что сильнее всего объем кода сокращает Kotlin, благодаря null safety и оператору elvis (?:), а также богатой библиотеки встроенных функций для работы с коллекциями и для трансформации значений. И работая на Python мне больше всего не хватало того что перечислил выше, особенно elvis.
И логичнее тогда уже перейти на Kotlin и остаться в тойже экосистеме, и иметь более производительный код, с меньшим потреблением памяти при одинаковых условиях.
По итогу статья содержит ложные посылы и содержит ссылки на неактуальные материалы, когда еще в Java даже Stream API не было. И несет больше вреда чем пользы, особенно для неокрепших умов, начинающих разработчиков.
Доброго времени суток! У меня вопрос и история.
Вопрос: Для кого это статья?
История: На втором курсе я и мои друзья увлеклись программированием (по образованию мы физики, но теперь все работаем в IT). Я увлекся C#, так как хотел делать игры (Unity), друг выбрал Python (нейросети), а еще один — C++ (микроконтроллеры). Было классное время: студенчество, розовые очки.
Но бывало, берём по бутылочке пивка, сидим, никого не трогаем, и... «А вот C++ быстрее, и вообще Страуструп!», «А ты видел сборщик мусора в C#?», «Поддержи мое пиво, на Python в две строки кода!». Доходило чуть ли не до мордобоя.
Прошло N лет. Теперь встречаемся и смеёмся над всем этим, потому что оказалось, что написание кода занимает всего 15–20% от общего времени. IDE помогают писать код, новый код пишется вообще 2–3% времени, а остальное — правки, интеграция, тестирование и поиск багов. Про нейронки вообще молчу.
В итоге язык программирования — всего лишь инструмент, и каждый решает свою задачу.
На жабе такие монолиты писать можно, что питонистам и не снилось. И оно работает. Микрофреимаорки против спринг Бута.... Ну подключите библиотеки в Бут и вашу фигню, посмотрите интеграции. Закиньте орм и тд. Жава сейчас лучше, чем когда либо. Все меняется, а в буте за 10 лет мало что изменилось, кодовая база теперь сразу понятная, велосипедов практически нет.
Жаль, что огромный пласт Энтерпрайза не видел вашу статью и использует Джаву (сильно больше чем Питон). Столько денег, времени и ресурсов зря теряют. /s
Вы явно долго прорабатывали тему и анализировали. Но мне кажется, что вы увлеклись цифрами:
Наличие скобок фигурных в синтаксисе и увеличение строк кода из-за них - увеличивает когнитивную нагрузку в Джаве? Рили?
Вы рассматриваете в примерах только стандартные библиотеки? А почему? Где то такие ограничения в проектах?
Наличие в Питоне метода "опен" что бы распарсить ДЖЕЙСОН понижает нагрузку? Так я в Джаве тоже могу сделать такой метод. А что будет через 10 лет когда таких методов опен будет 10 по проекту в разных модулях? Что с нагрузкой когнитивной будет?
А вы видели как возможности рефакторинга в IDEA и интеллисенс работают для Джава? Это не сравнить с Питоном. Они понижают нагрузку?
Если у вас алгоритмы одинаковые и блоки строительные одинаковы - то нагрузка когнитивная на этих обоих языках +- одинакова. Если блоки строительные отличаются - их можно привести к общему. Другой вопрос в том, что в обоих языках есть своя стилистика: Джава любит много конкретики, а Питон больше скрывает - это пайтоник-вэй, типа. Но это не повышает когнитивную нагрузку и не увеличивает время.
Сравнивать скорости на основе двух абсолютно разных Веб фреймворков - не корректно.
Как растет когнитивная нагрузка и скорость разработки на тех задачах, где Пайтон сильно очень проседает по скорости или ресурсам от Джава? (например кастомные парсинги, поиски и т.д.)?
Мне кажется вам нужно чуть посмотреть на картинку в целом. Цифр много, но не клеится ваша история.
Python vs Java: кто быстрее и дешевле