[Программирование, Java, .NET] Мне надоело, что индустрия зависит от прихоти создателей языков программирования. Сообществу нужно больше власти

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
08-Сен-2020 21:35

Цитировать

Я программирую 16 лет, и перебрал за это время много технических стеков. Изучать языки весело, в начале они всегда как новенькие игрушки, пока месяце на третьем не появляются первые проблемы.
В языках вечно не хватает чего-то простого — лямбда-функций, именованных объединений, кастомных примитивных типов. Я лезу в обсуждения на Stack Overflow, в Github и вижу, как разрабы жалуются — им не хватает того же, чего и мне. Но обсуждения почти всегда заканчиваются одинаково: нужная фича не появится, потому что главный дизайнер языка и члены его команды нужной ее не считают.
Раньше в эти моменты мне казалось, что это я неграмотный, и чего-то не понимаю. Что создатели языков за гранями приземленной разрабовской критики. Они умны, дальновидны, преисполнены мудрости, и пути их неисповедимы.
Но сейчас я понимаю — это полная чушь.
Последнее время моя работа связана с платформами разработки. Я предоставляю инструменты, библиотеки и разрабатываю шаблонные архитектуры для других программистов. У меня есть четкий план выхода фич на квартал, на полгода. Я на год вперед должен согласовывать с другими инженерами куда мы двигаемся.
Самая большая оценка задачи, которую я выдал за последние годы — 2 месяца. Это была жирная фича, и ровно столько я ее и делал. Параллельно с еще двумя десятками фич поменьше.
Как программист, я не могу сказать: "да, пользователи хотят эту фичу, но лично мне она не нравится — поэтому ее не будет". Я не могу как Роб Пайк сказать своим пользователям-программистам, что дженерики, которые все очень хотят, будут в Go 2, а Go 2 будет когда будет. Роб Пайк задумал Go как очень простой язык. Дженерики по его мнению добавляют сложность, которая испортит код.
Истинные причины отсутствия дженериков всегда лежали в техническом поле. Если вы заглянете в код компилятора Go, то у вас не останется сомнений — всему виной низкое качество кодовой базы компилятора. Добавить их просто невозможно не переписав компилятор, и, как я понимаю, для Go 2.0 они собираются сделать именно это.
Я давно убедился: разработчики языков ничуть не лучше обычных программистов. У них нет никакого уникального знания или экспертизы, которая делала бы их лучше, чем вы. Зачастую они игнорируют базовые практики разработки программного обеспечения, которые известны даже новичкам. Если код компилятора нужно переписать — это вина создателей компилятора, это они не следили за архитектурой и все запустили.
Как и любая другая разработка софта, процесс внесения изменений в язык программирования должен быть предельно прост: пожелания пользователей (то есть нас — программистов) изучены, задача поставлена, адекватные сроки определены, извольте выполнить в срок.
Но они ставят собственное мнение относительно разрабатываемых фич сильно выше вашего, хотя не пользуются продуктом также много, как вы, и не решают тех же проблем, что приходится решать вам. Даже если они соизволят согласиться на добавление возможности, это еще не победа. Складывается впечатление, что разработчики языков живут в другой системе отсчета времени, в которой неважно, когда будет сделана работа — в этом месяце или через 10 лет.
Проблема не в том, что мне не хватает синтаксического сахарка, чтобы сделать "красивенько". Все эти штуки — енамы, рекорды, юнионы — важные промышленные фичи, которые позволяют автоматизировать. Они появились не потому, что кто-то захотел выпендриться, они появились в ответ на конкретные задачи, которые не получалось хорошо решать со старыми инструментами.
Без лямбд, которые позволяют передать фильтер в коллекцию одной строкой, кодовая база наших репозиториев разрослась бы кратно. Когда у тебя кодовая база вдвое больше, чем могла бы быть — ты в полном дерьме. Это работает, как снежный ком. Чем больше на проекте необязательного кода, тем сложнее его будет поддерживать — а чем сложнее его поддерживать — тем быстрее качество его кодовой базы будет ухудшаться. В плохом проекте любое изменение делает его ещё хуже.
Я знаю, идеальных инженеров не существует, и я сам ошибался уйму раз. Сильнее всего меня напрягает другое. Как чисто технические ошибки постепенно обрастают чисто человеческим абсурдом.
Люди склонны оправдывать недостатки подменой понятий — незнание это сила, свобода это рабство, война это мир, ошибки это верные решения. Когда возможности языка, на котором работают миллионы, зависят от настроения одного создателя в день принятия решения — я называют это не философией и визионерством, я называю это диктатурой.
Когда я пишу на языке программирования я чувствую, что я делаю это по чужим правилам, к которым я непричастен и на которые не могу повлиять. Когда я программирую, я отдаю свою профессиональную жизнь на милость решениям Гослинга, Хейлсберга, Одерского, Бреслава, Сайма.
Если вы знакомы с работами ныне популярного Гуриева о современных диктатурах, то вы слышали, что "автократы нового формата стремятся выглядеть демократами". Попытки изобразить, что дизайн языка программирования находится в руках "сообщества" — не проходят простейшую проверку логикой. Комитеты и форумы посвященные дизайну языка, которые "открыты" для предложений, в действительности служат ширмой для диктатуры основной команды разработки языка. Я для примера посмотрел на список основных контрибьюторов в репозитории KEEP (процесс эволюции и улучшения Kotlin), топ 10 человек там — это члены основной команды Kotlin. Сами предложили — сами реализовали.
Там где есть диктатура, всегда рождается культ. Программисты на определенном языке всецело и самоотверженно посвящают себя ему. Для этого есть все: ворох литературы, конференции только по этому языку, митапы, телеграм каналы, инстаграм аккаунты, приезды Создателя в ваш город. После речи именитого дизайнера люди спрашивают всякую ерунду, которая гуглится за 5 секунд. Это дает спрашивающим не ответы — это дает чувство причастности. Вот мой лидер и он прислушивается ко мне, мы вместе идем верным путем!
Культ языка программирования, чаще всего, агрессивный. Я помню как в конце нулевых я пытался объяснить джавистам, что их язык отстал от C#. Вместо вдумчивых обсуждений нужны ли в языке лямбда-функции (C# 3.5 2007) я встречал агрессию, усмешки и снисходительные комментарии в духе: "мелкомягкие все скопировали у богов".
В Stack Overflow в вопросах вида “как сделать в Java X” именитые участники сообщества отвечают, что X вреден и делать так ни в коем случае не надо, а то что язык такого не позволяет — это величайшее благо, ибо защищает программистов. Такие комментарии люто заплюсованы. И наоборот: заминусованы те, что находятся не в канве основной линии партии.
Нет ничего хорошего в том, чтобы выбирать объективно худшие подходы в угоду чьей-то "идеологии". Нет ничего хорошего в том, чтобы отказываться от автоматизации, потому что кому-то она показалась сложной.
Видели ли вы когда-либо в книге уровня "Философия Java" (Брюса Эккеля) раздел хотя бы на пару страниц, в котором обсуждались бы возможные улучшения в языке? Хотя бы одним глазком посмотреть: как может быть или (не дай Бог) как должно быть. Были ли лямбда-функции такой уж инновационной концепцией, что сложно было предположить, как это могло бы выглядеть в Java? Или, к примеру, как может выглядеть null-safety в Java, хотя бы гипотетически?
Самое главное — идеология всегда выглядит непоколебимой, Евразия всегда воюет с Остазией. На деле — идеология меняется, и культисты переобуваются вслед за ней.
Когда-то давно случай распорядился так, что Oak вытащили из мусорного ведра, назвали Java и влили в него беспрецедентные маркетинговые бюджеты со статьями в Wall Street Journal. Затем Java сопротивлялась добавлению "синтаксического сахара" около 10-ти лет (условно 2002-2012). Наконец-то в нее добавляют все то, что должно быть в хорошем языке программирования. Это не было каким-то вынужденным 10-ти летним простоем в дизайне языка, во время которого переписывали компилятор или решали другие объективные проблемы развития. Просто Sun и Oracle предпочитали нанимать юристов, а не разработчиков.
В C# только что добавили тип данных запись (record type), это заняло всего лишь 9 лет — отсчитывая от релиза другого языка F# 2.0 (2010), в котором уже была очевидна полезность этих типов. Оба языка разрабатывались под одной крышей Microsoft. Трудно предположить, что в команде C# не заметили возможностей F#. Просто они решили не торопиться. Возможно года через 3-4 мы получим именованные объединения (tagged union или discriminated union) в C#. Почему так долго? А нет никаких причин — просто дизайнерам языка так захотелось.
В Scala 3 (aka Dotty) добавляют новое ключевое слово enum. 14 лет выходили новые релизы этого языка начиная с 2006 года (релиз 2.0), но за это время создатели Scala не подумали сделать нормальные перечисляемые типы. Есть enumeratum, и различные другие "варианты", но сам факт добавления нового ключевого слова enum прямо говорит о том, что эти костыли не работают как надо. Если бы только мы не должны были ждать Dotty более 3 лет.
Я давно фильтрую “идеологию” в программировании. С помощью идеологии можно оправдать любой недостаток языка. Есть конкретные, практические проблемы и их надо решать. Если они не решаются в сжатые сроки в конкретном языке, значит этот язык пока что плох, и разработчики не имеют необходимой квалификации. Они пытаются прикрыть эти факты пропагандой и ощущением одобрения большинства. Не верьте им — это дешевые уловки. Скажете себе за это спасибо, когда они переобуются в очередной раз.

Спасибо пацанам из Мы обречены. Побывал у них гостем. Смотрите, там весело.

===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_programmirovanie (Программирование), #_java, #_.net, #_jazyki_programmirovanija (языки программирования), #_diktatura (диктатура), #_programmirovanie (
Программирование
), #_java, #_.net

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 18:47
Часовой пояс: UTC + 5