Я занимаюсь программированием уже 16 лет и перепробовал множество технических стеков. Изучение новых языков – это очень весело. Поначалу новые языки всегда похожи на новые игрушки, пока где-то на третьем месяце вы не столкнетесь с проблемами.
Всегда чего-то простого не хватает – лямбда-функций, помеченных объединений, пользовательских примитивных типов. Я вижу, как другие разработчики жалуются на StackOverflow и Github, отчаянно ища те же функции. Эти жалобы всегда заканчиваются одним и тем же: столь желанная функция не будет реализована, потому что разработчики языка не считают, что эта функция необходима.
Раньше я думал, что недостаточно компетентен и не до конца понимаю рассуждения создателей языка. Я думал, что они не поддаются критике со стороны таких разработчиков, как я. Они умны, дальновидны, полны мудрости, и их пути невозможно отследить.
В последнее время я работаю инженером платформы. Я предоставляю инструменты, библиотеки и разрабатываю примеры архитектур для других разработчиков. У меня есть конкретный план на текущий спринт и дорожная карта, которая охватывает как минимум полгода работы. Я должен координировать функции и направления с другими инженерами.
Самая большая оценка, которую я дал за последние три года, составила два месяца. Это была большая функция, которую я смог предоставить вместе с двумя десятками других более мелких функций.
Как инженер-программист, я не могу сказать: “Мои пользователи хотят эту функцию, но лично мне она не нравится – так что это не будет развито”. Я не могу поступить так, как Роб Пайк, который сказал, что столь востребованные дженерики будут в Go 2, а Go 2 будет “готов, когда будет готов”. Видите ли, по его мнению, дженерики добавляют сложности, а ему не нравится сложность.
Реальные причины отсутствия дженериков всегда были в технической области. Если вы взглянете на код компилятора Go, у вас не останется сомнений – качество кодовой базы настолько низкое, что добавление дженериков просто невозможно без переписывания компилятора.
Языковой компилятор и инструменты – это всего лишь программное обеспечение, а разработчики языков ничем не лучше любых других разработчиков программного обеспечения. Однако они часто игнорируют основные методы разработки. Разработчики сами виноваты, если кодовая база настолько плоха, что ее приходится переписывать. Разработчики не проделали большой работы с архитектурой.
Разработка языка должна быть такой же простой, как: изучение запросов пользователей (т.е. запросов разработчиков), создание рабочих элементов, оценка и планирование работы, предоставление новых функций.
Языковые дизайнеры не используют свой собственный язык так часто, как вы, они не решают те же проблемы, что и вы. Однако они ставят свое собственное мнение относительно языковых особенностей выше вашего. Даже если они опустятся так низко, чтобы согласиться с тем, что какая-то функция полезна и должна быть реализована, это еще не конец. Похоже, им все равно, когда эта функция будет реализована: в этом месяце или через 10 лет.
Функции, которых мне не хватает, – это не простой синтаксический сахар. Все эти вещи: перечисления, записи, объединения с тегами – это важные функции промышленного программирования, они позволяют мне автоматизировать больше. Они познакомились с некоторыми языками, потому что они решают очень специфические проблемы, которые без них не могли бы быть решены достаточно хорошо.
Рассмотрим функцию лямбда-функции, которая позволяет фильтровать коллекцию в одной строке. Отсутствие лямбда-функций приводит к раздутой кодовой базе. Когда ваша кодовая база вдвое больше, чем могла бы быть, вы знаете, что у вас серьезные проблемы, и они растут как снежный ком. Чем больше у вас дополнительного кода – тем сложнее поддерживать кодовую базу – тем быстрее ухудшается качество.
Я знаю, что идеальных инженеров не бывает. Все совершают ошибки. Я делал это много раз. Что меня действительно беспокоит: как эти чисто технические ошибки превращаются в абсурд.
Когда я пишу код, я чувствую, что делаю это по чужим правилам. Я не могу повлиять на эти правила. Я в основном отдаю себя на милость Гослинга, Хейлсберга, Одерского, Бреслава, Сайма.
Если вы знакомы с последними исследованиями современных диктатур, вы знаете, что автократы новой волны стремятся представить себя демократическими лидерами. Попытка притвориться, что дизайн языка программирования контролируется или находится под влиянием “сообщества”, просто смешна. Комитеты и форумы, предназначенные для работы над дизайном языка, являются всего лишь прикрытием для диктатуры основной команды разработчиков языка. Например, я проверил участников репозитория KEEP (Процесс оценки и улучшения Kotlin) – 10 лучших разработчиков являются членами основной команды Kotlin. Они предлагают изменения и внедряют их.
За диктатурой всегда следует культ. Разработчики, использующие определенный язык программирования, всецело посвящают себя этому языку. У них есть все: литература, конференции, встречи, форумы Reddit, аккаунты в Instagram (кто бы мог подумать!?) и, конечно же, лекции создателей языка. После того, как разработчик языка произнес такую речь, у разработчиков есть возможность задать им вопросы. Обычно они задают самые простые вопросы, которые можно было бы погуглить за 5 секунд. Им не нужны ответы, они хотят чувствовать участие. ” Вот мой лидер, и он/она слушает меня, мы движемся вперед вместе!”
Языковой культ большую часть времени агрессивен. Я до сих пор помню, как в конце 200x я пытался объяснить Java-программистам, что Java сильно отстает от C # с точки зрения языкового дизайна. Вместо какой-то разумной дискуссии о том, нужны ли языку лямбда-функции (представленные в C # 3.5 в 2007 году), были ненависть, ухмылки и снисходительные комментарии о том, как “Microsoft украла все у богов”.
В вопросах типа “Как сделать X в Java?” на Stackoverflow ветераны сообщества объясняют, что X вреден и не нужен, а тот факт, что в Java нет X, является величайшим благом, поскольку он защищает разработчиков. Такие комментарии обычно не нравятся, и наоборот, не нравятся те предложения, которые X могут быть полезны в Java.
Вы когда-нибудь видели какую-нибудь книгу на уровне “Мышление на Java” (Брюса Экеля), предлагающую, по крайней мере, на одной или двух страницах, какие улучшения можно было бы внести в язык? Разве не было бы интересно кратко взглянуть на то, что можно было бы сделать или даже должно быть сделано в дизайне языка? Была ли концепция лямбда-функций настолько революционной идеей, что было абсолютно непредсказуемо, что однажды она появится в Java? Или, если обратиться к более современному примеру, как гипотетически может выглядеть нулевая безопасность в Java?
Диктатура всегда выглядит твердой и непоколебимой. На самом деле идеология в конечном итоге изменится, и последователи культа совершат поворот на 180 градусов.
Давным-давно язык Oak был вытащен из мусорного ведра, назван “Java” и получил беспрецедентные маркетинговые бюджеты благодаря материалам в Wall Street Journal. После этого мы увидели 10 лет отрицания каких-либо улучшений языка (где-то в 2002-2012 годах). Наконец, в Java добавляется большинство обычных функций. Не было никаких веских причин для этого бездействия (например, перезаписи компилятора), кроме предпочтения Sun и Oracle нанимать юристов вместо разработчиков.
Тип записи только что был добавлен в C#. Прошло всего 9 лет, считая с 2010 года, когда они были представлены в F #. Оба языка были разработаны под крышей Microsoft, и кажется невозможным, чтобы разработчики C# не заметили, насколько полезны типы записей. Они просто решили не торопиться с этим. Может быть, через 3-4 года мы сможем получить помеченные союзы в C#. Почему это заняло так много времени? На это нет ответа – дизайнеры C# хотели, чтобы все было именно так.
Scala 3 (он же Dotty) получает новое ключевое слово “enum”. За последние четырнадцать лет, начиная с версии 2.0 (2006), было выпущено несколько выпусков Scala, но ни в одном из них разработчики не чувствовали себя обязанными добавлять обычные типы перечислений. Есть перечисление и некоторые другие “опции”, но факт добавления нового ключевого слова “enum” говорит нам о том, что эти “опции” не работают. Было бы неплохо, если бы нам не пришлось ждать Дотти 3 года.
Я отфильтровываю “идеологию” в программировании. Идеология используется в основном для того, чтобы скрыть недостатки языка. В языке есть специфические проблемы, и они должны быть решены. Если они не будут решены в разумные сроки, это будет означать, что язык сейчас не так хорош, и разработчики языков не справляются с большой работой. Вместо этого они пытаются прикрыть это пропагандой и созданием культа. Это дешевый трюк, не верьте им. Вы поблагодарите меня, когда они сделают еще 180.
Оригинал: “https://dev.to/vsapronov/programming-language-dictatorship-28l0”