Язык без компилятора это просто никому не нужная абстракция. Вы вероятно в понятие «язык» включаете и базовые возможности (собственно язык в моем понимании), и стандартную библиотеку. Я же намеренно разделяю эти понятия, потому что это реально разные вещи.
Какие корпорации? Давайте отделим техническую дискуссию от всех этих теорий заговора, здесь им не место. Рефлексия — это естественный механизм получения метаинформации от компилятора. Если поддержки компилятора нет — то и рефлексии нет, и НИКАКАЯ библиотека не способна извлечь информацию, которой у нее нет и быть не может, пока компилятор ее не предоставит. Неужели это так сложно понять?
Если делать генерацию кода как следует, то все будет ОК. Просто до сих пор нормально никто не сделал, делали тупо «в лоб». Как минимум, при генерации кода обязательно должна создаваться метаинформация о связи генерирующего и сгенерированного кода, и активно использоваться при отладке и даже при редактировании кода.
Ответил выше: простота языка — это перекладывание проблем на плечи пользователей, все чего нет в языке им придется допиливать вручную. Все равно придется, только вместо единой реализации в языке будет 100500 кривых реализаций «на местах».
Потому что нужно писать — и компиляторы, и документацию — как следует, а не как попало. Простота языка — это перекладывание проблем на плечи пользователей, все чего нет в языке им придется допиливать вручную. А сложность языка — это результат того, что во-первых, не все бывает сразу ясно (когда создавался С++ многие вещи были еще неочевидны, в Java и C# их учли), во-вторых — страх сломать «обратную совместимость». Сейчас уже более-менее все очевидно по фичам, ну и делать нужно с нуля, а не издеваться над С++.
Нет, не думаю. Просто некоторые старые языки — такие например как Smalltalk — могут содержать немало интересных идей, поэтому иногда здесь появляются статьи, и мы их с удовольствием читаем…
Я считаю, что компилятор соответствует языку (иначе это уже компилятор другого языка, пусть и очень похожего). То что в жизни компиляторы не всегда соответствуют стандартам языков — это вообще говоря проблема, а не нормальное явление. Сами посудите: вот переходите вы на новый компилятор — а программа не компилируется или не так работает. Оно вам надо?
В общем, такого категорически не должно быть. Поэтому лучше, чтобы все фичи были официально задокументированы в стандарте языка, и — что не менее важно — чтобы не было никаких фич, не описанных в стандарте.
Как обычно — то что встроено непосредственно в язык и поддерживается компилятором. Например, операторы if/else. Для сравнения, операторы консольного ввода/вывода (всякие printf, println, WriteLine) — это библиотечные возможности, компилятор о них не знает.
Boost это некоммерческая разработка. GСС тоже (в gcc можно посмотреть например gcc.gnu.org/onlinedocs/gcc/C-Extensions.html и gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Extensions.html — тоже много интересного). Языки D и Nim тоже некоммерческие. Go — продукт Гугла, но истоки в системе Plan9 и ее языках Alef и Limbo. Rust — продукт Мозиллы, но они для себя разрабатывают, и продукт полностью открытый. Нет, я не склонен увязывать сюда коммерцию, сейчас вообще почти все языки и IDE бесплатные.
По рефлексии — если компилятору известно чуть больше, это уже языковая фича. Конкретные применения этой фичи (например запись в xml, json, binary) — это действительно должно быть в библиотеках, но если в компиляторе нет ничего для базовой поддержки — то остаются только нагромождения костылей (как это и есть в С++). Одна маленькая фича в компиляторе позволит выкинуть множество неестественных и ненадежных нагромождений в библиотечном и прикладном коде. В этом и смысл языковых фич.
О балансе — в С++ нарушением баланса (ИМХО конечно) являются не сами шаблоны, а метапрограммирование на них. А сами шаблоны вполне сбалансированы. По изначальному замыслу предполагалось, что шаблоны будут вот для таких конструкций
template<class T, int N>
struct Array
{
T data[N];
};
а не для написания полноценных парсеров времени компиляции (boost.spirit) или compile-time коллекций типов и операций над ними (boost.mpl). Но то, что эти библиотеки появились, и что ими, несмотря на сложности, пользуются — признак того, что соответствующие возможности реально востребованы.
Как рефлексия может работать в компонентах, если от компилятора требуется например связать объект с его строковым именем (которое известно только на этапе компиляции) и предоставить эту информацию другим частям программы? Тут или рефлексия, или ручками прописывать — других вариантов нет.
Шаблоны при правильной реализации никакой связи с кодом не лишают. Даже обычный оператор присваивания — это шаблон, потому что в конечном итоге для целых чисел вызывается один набор ассемблерных команд, для float — другой, а для строк вообще третий. Вы же не утверждаете что оператор присваивания лишает вас связи с кодом?
«Никто не знает, насколько та или иная фича нужна в языке» — почему же, практикующие программисты знают. Я приводил в пример Буст — это все не с потолка придумано, а для решения конкретных задач. Другое дело, что идеологически многое там — не полноценные фичи, а мегакостыли на костылях… Могу еще из своей жизни привести пример: я регулярно и достаточно давно заношу в evernote разные идеи по языковым фичам, возникающие из реальной практики. Таких записей сотни…
А у меня есть подозрение, что Overengineering как-то связан с нехваткой полноценных языковых фич и с неполнотой/несовершенством стандартных библиотек. Люди, закладывая универсальность в свои программы, раз за разом пишут по сути некие околобиблиотечные/околофреймворковые вещи, которые по уму должны быть как-то реализованы стандартно, чтобы их не писать, а просто брать и пользоваться… Надо будет подумать над этим.
О, олдскульный сайтик на народе… они еще существуют:) Когда-то давно во времена диалапа я по крупицам собирал интересную информацию с таких вот страничек…
Самый простой язык это не оберон, а brainfuck — всего 4 оператора и ничего больше. И разумеется, на нем можно писать программы. Но нужно ли?
Фичи — это не просто какой-то «синтаксический сахар» (вообще странное словосочетание:) ), это нечто, дающее новые возможности.
Например, рефлексия. Она есть в обероне? А это необходимая фича для автоматического связывания кода программы с внешними данными (например сериализация в xml). Разумеется, это можно сделать вручную — не забыв аккуратно прописать для каждого поля каждой структуры процедуру чтения и процедуру записи. Все можно сделать вручную. Более того, любую программу можно написать на ассемблере и даже в машинных кодах вручную. Но нужно ли?
Или те же самые шаблоны и метапрограмминг. Да, это следующий уровень программирования, и конечно, он может быть проэмулирован вручную — аккуратным написанием тех же векторов, списков и алгоритмов для каждого типа. Но зачем, если есть удобный инструмент под названием «метапрограммирование»? То что он в С++ поехал не в ту степь — да, это нужно пофиксить (и ввести новые фичи, специально спроектированные для решения задач, для которых в С++ используют метапрограммирование на шаблонах), но зачем отказываться?
В той статье я не затронул многие вещи. Например, особенности добавления фич в современные языки. В большинстве случаев они добавляются бессистемно и, что самое печальное, они слабо связаны между собой. Вот это реально проблема. А количество фич — оно вполне разумно во всех существующих языках, я еще не встречал такого языка чтобы можно было запутаться в его синтаксисе. И стремиться их минимизировать вообще странно, это всего лишь инструменты — удобные инструменты для решения соответствующих задач; какой смысл например при создании чего-то (строительстве дома или там космического корабля) стремиться ограничить себя в инструментах???
Согласен полностью. У меня среди evernote-заметок, где я храню различые идеи по языкам программирования, немаленький раздел посвящен IDE; при проектировании языка учитываю связку с IDE (в частности, синтаксис языка должен строиться таким образом, чтобы было удобно работать автокомпилиту, построителю деревьев классов и прочим инструментам IDE, которые должны работать «на лету»); я даже указываю специальные рекомендации к IDE, к организации проектов и т.п., что обычно в язык не входит. А одна из первых вещей с чего я начал эксперименты со своим компилятором (форком D) — это написал простейшую IDE на Qt и делаю визуализатор AST (а затем будут визуализаторы всех преобразований внутри компилятора, вплоть до кодогенератора). То есть не только пользоваться компилятором, но даже разрарабывать его без графического интерфейса неудобно.
В общем, такого категорически не должно быть. Поэтому лучше, чтобы все фичи были официально задокументированы в стандарте языка, и — что не менее важно — чтобы не было никаких фич, не описанных в стандарте.
По рефлексии — если компилятору известно чуть больше, это уже языковая фича. Конкретные применения этой фичи (например запись в xml, json, binary) — это действительно должно быть в библиотеках, но если в компиляторе нет ничего для базовой поддержки — то остаются только нагромождения костылей (как это и есть в С++). Одна маленькая фича в компиляторе позволит выкинуть множество неестественных и ненадежных нагромождений в библиотечном и прикладном коде. В этом и смысл языковых фич.
О балансе — в С++ нарушением баланса (ИМХО конечно) являются не сами шаблоны, а метапрограммирование на них. А сами шаблоны вполне сбалансированы. По изначальному замыслу предполагалось, что шаблоны будут вот для таких конструкций
а не для написания полноценных парсеров времени компиляции (boost.spirit) или compile-time коллекций типов и операций над ними (boost.mpl). Но то, что эти библиотеки появились, и что ими, несмотря на сложности, пользуются — признак того, что соответствующие возможности реально востребованы.
Шаблоны при правильной реализации никакой связи с кодом не лишают. Даже обычный оператор присваивания — это шаблон, потому что в конечном итоге для целых чисел вызывается один набор ассемблерных команд, для float — другой, а для строк вообще третий. Вы же не утверждаете что оператор присваивания лишает вас связи с кодом?
«Никто не знает, насколько та или иная фича нужна в языке» — почему же, практикующие программисты знают. Я приводил в пример Буст — это все не с потолка придумано, а для решения конкретных задач. Другое дело, что идеологически многое там — не полноценные фичи, а мегакостыли на костылях… Могу еще из своей жизни привести пример: я регулярно и достаточно давно заношу в evernote разные идеи по языковым фичам, возникающие из реальной практики. Таких записей сотни…
Фичи — это не просто какой-то «синтаксический сахар» (вообще странное словосочетание:) ), это нечто, дающее новые возможности.
Например, рефлексия. Она есть в обероне? А это необходимая фича для автоматического связывания кода программы с внешними данными (например сериализация в xml). Разумеется, это можно сделать вручную — не забыв аккуратно прописать для каждого поля каждой структуры процедуру чтения и процедуру записи. Все можно сделать вручную. Более того, любую программу можно написать на ассемблере и даже в машинных кодах вручную. Но нужно ли?
Или те же самые шаблоны и метапрограмминг. Да, это следующий уровень программирования, и конечно, он может быть проэмулирован вручную — аккуратным написанием тех же векторов, списков и алгоритмов для каждого типа. Но зачем, если есть удобный инструмент под названием «метапрограммирование»? То что он в С++ поехал не в ту степь — да, это нужно пофиксить (и ввести новые фичи, специально спроектированные для решения задач, для которых в С++ используют метапрограммирование на шаблонах), но зачем отказываться?
В той статье я не затронул многие вещи. Например, особенности добавления фич в современные языки. В большинстве случаев они добавляются бессистемно и, что самое печальное, они слабо связаны между собой. Вот это реально проблема. А количество фич — оно вполне разумно во всех существующих языках, я еще не встречал такого языка чтобы можно было запутаться в его синтаксисе. И стремиться их минимизировать вообще странно, это всего лишь инструменты — удобные инструменты для решения соответствующих задач; какой смысл например при создании чего-то (строительстве дома или там космического корабля) стремиться ограничить себя в инструментах???