О бытовом заблуждении

Потому что как это так, разве можно выкидывать из языка фичи

Фичи можно и нужно выкидывать не только из языков программирования, а вообще из всего. Если они затратны в реализации и мало полезны на практике.

Взять сетевые протоколы. Взять тот же IPv4. Хорошая, вроде бы, идея — реализовать фрагментацию пакетов. Но опыт работы интернета показал, что фрагментация — зло, она или не реализована у некоторых абонентов, или реализована криво (и это создает уязвимости), или реализована хорошо, но с огромными затратами ресурсов (память, процессор). А теперь, если вернуться к исходному положению и еще раз подумать, нужна ли вообще эта фрагментация, если она дается такой ценой? И люди пришли к твердому «нет»: не нужна. И в IPv6 ее выкинули (хотя, к сожалению, не до конца).

И так во всем. Overengineering — бич современного мира технологий. Но люди учатся на ошибках, приходят к пониманию того, что лучше сделать проще. Технологии становятся проще, и за счет этого совершеннее, там, где это возможно. По-видимому языки программирования — это то направление, которое находится далеко не в конце своего развития. Отсюда и недостатки многих существующих языков. Трудно найти тот минимально необходимый набор возможностей языка, который имел бы приемлемую цену в реализации и давал при этом большую пользу в облегчении программирования. Но люди трудятся над этой задачей. Тут нужны годы опыта всего сообщества. Когда-нибудь найдутся лучшие решения.

Глава «Новый выстрел „Серебряной пули нет“» Брукса из его Мифический-человека месяц начинается с гениальной цитаты Александра Поупа:

Кто хочет увидеть образец совершенства,
Тот мечтает о том, чего никогда не было, нет и не будет.

compact-programming.narod.ru/Index.htm
В одном флаконе, и зачем так гневаться, ну не осталось инженеров в IT, значит так и надо.

Я наблюдал развитие средств разработки последние два десятка лет. И меня не покидает смутное сомнение. Средства разработки становятся «как бы проще»: не надо выделять память и потом следить за её освобождением, не надо думать, на что указывает указатель, не надо даже скобки расставлять… Но вот объём знаний, который должен иметь разработчик, чтобы сделать действительно серьёзный продукт, от этого нисколько не уменьшается. И даже наоборот, растёт чуть ли не по экспоненте. Каждая среда разработки, каждый фреймворк вносят свои абстракции, и на первый взгляд всё работает. Но наступает момент, когда абстракция начинает трещать по всем швам. И тогда приходится лезть в глубины того же фреймворка и смотреть, что у него не так с той же памятью, с теми же указателями…

Т.е. простота и удобство инструментария не отменяет знаний глубин взаимодействия софта и железа.

И по мере того, как эта истина проявлялась, возникал вопрос: почему? Моё ощущение, что разработчики сред разработки в определённый момент начали гонку за студентами и топ-менеджерами, приучая их именно к своему детищу. Когда я был студентом, были популярны C++ и Delphi. Потом стала набирать популярность Java, потом появился C#. Как бизнес набросился на RAD-разработку! Это же целый прорыв: за мизерные деньги можно было сделать свой http-сервер! И как потом бизнес-сообщество приняло .NET!..

Семя упало в плодородную почву, «простые» фреймворки заполонили головы молодёжи и топ-менеджеров. И теперь программисты должны учить не только выполнение машинного кода ядром процессора и распределение байтов в регистрах памяти, но и уйму информации о функциях используемых ими библиотек, а потом ещё и оправдываться за то, что эти библиотеки не работают так, как хотелось бы бизнесу… Как говорил Стив Балмер, «у нас не монополия, у нас рынок, а это не одно и то же».

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

Прошу прощения, но я не согласен с автором, хотя и поддерживаю некоторые его аргументы.

При всем уважении в профессору Вирту, его оценка сложности языков программирования основана на правилах грамматики, то есть, говоря по-простому, оценивает лишь синтаксис, не затрагивая семантику. Однако, проблема в том, что семантику сложно, а в большинстве случаев невозможно оценить в цифрах. Я уже не говорю о том, что само понятие «семантика» _немного_ расплывчато. Тем не менее, я следую понятию семантики из википедии: ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%BC%D0%B0%D0%BD%D1%82%D0%B8%D0%BA%D0%B0_%28%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29

Таким образом, семантически следующие конструкции эквивалентны (JS):
1) for(var i in [1,2,3]) { sum += 2*i }
2) [1,2,3].map(function(a) {return 2*a}).reduce(function(a, b) { return a+b }, 0)

Так же как и следуюшие (С++):
1) for (int i = 0; i < vec.size(); i++) { sum += i*2 }
2) for (auto i = vec.begin(); i != vec.end(); ++i) { sum += *i * 2 }
3) std::for_each(vec.begin(), vec.end(), [](int i) { sum += i*2 }

Однако, в С++, результирующий ассемблерный код будет одинаков (в релиз версии). Что в случае JS? Ээээ. Ну… В V8 уж точно нет. Но я сейчас не об этом (и да, я утрирую).

Так вот. Какая разница, сколько синтаксических фич у языка!? Главное, какая у языка семантика, то есть сколько различных смыслов можно описать на языке. И если у языка столько различных семантических фич, сколько, например, у С++, то он будет сложен, но и областей применения у него будет больше, чем, например, у JS.

Другой вопрос, на рассмотрение которого, у сожалению, формат комментария маловат — это как раз области применения. Я покручу у виска, если кто-либо всерьез предложит программировать микроконтроллеры на JS (такое уже было трижды на моей памяти), или будет парсить сайты (один раз, то есть производительность не важна) на чистом C. Кроме того, области применения постоянно возникают и исчезают. Кто десять лет назад задумывался о вычислениях на GPU? Но сейчас это реальность. И где язык, заточенный под GPU? Есть, конечно, попытки пришить собаке пятую ногу, например, С с новыми ключевыми словами и несовместимый ни с одним существующим компилятором, Фортран, С и С++ с новыми прагмами, но ни одного нового языка.

А теперь у меня вопрос к вам, автор. Как можно добавить поддержку GPU в Оберон, не усложняя его? Или она уже есть?

Самый простой язык это не оберон, а brainfuck — всего 4 оператора и ничего больше. И разумеется, на нем можно писать программы. Но нужно ли?
Фичи — это не просто какой-то «синтаксический сахар» (вообще странное словосочетание:) ), это нечто, дающее новые возможности.

Например, рефлексия. Она есть в обероне? А это необходимая фича для автоматического связывания кода программы с внешними данными (например сериализация в xml). Разумеется, это можно сделать вручную — не забыв аккуратно прописать для каждого поля каждой структуры процедуру чтения и процедуру записи. Все можно сделать вручную. Более того, любую программу можно написать на ассемблере и даже в машинных кодах вручную. Но нужно ли?

Или те же самые шаблоны и метапрограмминг. Да, это следующий уровень программирования, и конечно, он может быть проэмулирован вручную — аккуратным написанием тех же векторов, списков и алгоритмов для каждого типа. Но зачем, если есть удобный инструмент под названием «метапрограммирование»? То что он в С++ поехал не в ту степь — да, это нужно пофиксить (и ввести новые фичи, специально спроектированные для решения задач, для которых в С++ используют метапрограммирование на шаблонах), но зачем отказываться?

В той статье я не затронул многие вещи. Например, особенности добавления фич в современные языки. В большинстве случаев они добавляются бессистемно и, что самое печальное, они слабо связаны между собой. Вот это реально проблема. А количество фич — оно вполне разумно во всех существующих языках, я еще не встречал такого языка чтобы можно было запутаться в его синтаксисе. И стремиться их минимизировать вообще странно, это всего лишь инструменты — удобные инструменты для решения соответствующих задач; какой смысл например при создании чего-то (строительстве дома или там космического корабля) стремиться ограничить себя в инструментах???