Лучше Или Хуже :: Блоги Lumtu

Перевод статьи "Лучше или хуже" разработчик от DataDog Inc. Статья посвящена вопросу проектирования языков программирования и связи проектирования с попытками оценки качества языков.

Частично в ответ на недавно переведенный вот эта статья .

В сообществе программистов возникает мем об «объективном качестве» дизайна Go. Буквально на днях я встретил его в статья о выборе языков от Honza , где его было очень хорошо видно:

Имейте в виду, что язык объективно очень плохо спроектирован.
[.
] И все же, по данным GitHub, Go гораздо более популярен, чем Haskell. В то же время уже существует очень много отличных проектов, написанных на Go, таких как Docker, InfluxDB и т. д., Consul, Prometheus, Packer и другие.

Я думаю, что это чрезвычайно интересный набор противоречий , и автор с этим согласен.

Было бы сложно так категорично и уверенно сказать, что Go плохо спроектирован, если бы это мнение не было столь распространенным.

В прошлом году ряд статей и сообщений в блогах заложили основу для этой точки зрения.

Среди них были статьи людей, которым Go не нравится, потому что он не заставляет их чувствовать себя умными или потому что ничего принципиально нового в этом нет .

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

Когда люди с таким видением пытаются объяснить популярность Го, они неизбежно приходят к парадоксу.

Если Го настолько плох, почему он так популярен? Более того, в этом случае с когнитивным диссонансом очень сложно бороться.

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

Он не достиг критической массы несмотря на недостатки , на новой платформе, занятой в основном любителями и неопытными разработчиками.

Он был разработан в крупнейшей интернет-компании мира , один из самые опытные программисты в истории и получил свое первое распространение в проектах распределенной инфраструктуры.

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

Лучше Или Хуже

Чем хуже, тем лучше

Это современное проявление того, что Ричард П.

Габриэль описал в своем классическом эссе.

“Чем хуже, тем лучше” .

В нем Габриэль формулирует четыре основные ценности проектирования системы, которые могут противоречить друг другу: простота , верно , логика И полнота .

Далее он описывает две конкурирующие философии: подход Массачусетского технологического института, который отдает приоритет правильности и последовательности, и подход Нью-Джерси, который отдает приоритет простоте реализации.

Даже если можно спорить, является ли подход Нью-Джерси описанием философии Unix постфактум, можно с уверенностью утверждать, что создатели Go явно пропагандировал простоту как ведущий элемент своей философии.

Простота реализации – это четко сформулированная позиция, т.к.

в самом языке , так в библиотеках , и этот явный приоритет простоты над логикой вшиты в язык.

Простота, вероятно, стала еще более признанным приоритетом с момента написания эссе в 1990 году, поскольку Мир компьютеров кардинально изменился .

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

Системы, восхваляемые в старой литературе, такие как КОРБА или иронично названный МЫЛО , в конечном итоге были похоронены гораздо более простыми системами, чьи способы отказа были гораздо менее элегантными, но реализация была на порядки проще.

Изменился и способ разработки программного обеспечения.

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

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

Просто сложные вещи, такие как Паксос в конечном итоге уступают более простым вещам, таким как Плот .

Природа качества

Несмотря на тенденцию к простоте, обсуждения языков программирования обычно происходят на рамка Подход МТИ.

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

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

Намеренное упрощение этих систем всегда рассматривается как недостаток, а не сознательный компромисс.

Проблема в том, что эта тема оценивает качество языков программирования.

нет очевидных связей с их эффективностью при написании реального кода.

Подход Go заключался в том, чтобы начать с C, затем выбросить то, что было трудно правильно использовать, и заполнить пробелы до тех пор, пока не останется ничего достаточно простого или достаточно ортогонального, чтобы можно было добавить.

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

Это непростительно просто инженерный подход к строительным системам.

Конечно, нельзя пожертвовать всем на алтарь простоты.

Многие низкоуровневые языки байт-кода и ассемблера легко писать и портировать, но их интерфейсы слишком сложны для использования программистами.

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

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

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

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

Ошибки имеют сложность, соизмеримую со сложностью их системной реализации.

Могут потребоваться годы, чтобы узнать, какое решение жюри по поводу Го.

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

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

Но мы видим, что Go выбирают проекты, которые 5 лет назад даже не казались бы возможными из-за ужасной ситуации с инструментами в их нише.

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

Теги: #Go #языки #чем хуже, тем лучше #разработка сайтов #программирование #Go

Последнее изменение: 2024-12-19 05:12:58

Вместе с данным постом часто просматривают: