Язык интересный, как раз читаю неспеша документацию, отмечаю интересные моменты (как положительные так и отрицательные). Фич никогда много не бывает, но вот синтаксис на отступах мне категорически не нравится — слишком это неочевидно, где N пробелов а где N+1… Там еще подобная вещь есть — приоритет операций в зависимости от количества пробелов перед символами операций, ИМХО вообще безобразие. Также мне не понравилась система приоритетов операций, странные операции специально для беззнаковых чисел. До метапрограммирования еще не добрался Как я понимаю, в данной статье нет примеров обращения к API компилятора, а это самое «особенное» в Nim.
ОК, я так понимаю это происходит внутри одного модуля. Тогда да, эта функциональность частично пересекается с рефлексией. Таким образом, компилятор все-же сохраняет где-то строковые имена модулей и функций, это и есть языковая поддержка о необходимости которой я говорю.
Речь идет не о деталях реализации, а о четком разграничении функциональности между слоями этой реализации — что делается в компиляторе, а что в стандартной библиотеке.
Язык без компилятора это просто никому не нужная абстракция. Вы вероятно в понятие «язык» включаете и базовые возможности (собственно язык в моем понимании), и стандартную библиотеку. Я же намеренно разделяю эти понятия, потому что это реально разные вещи.
Какие корпорации? Давайте отделим техническую дискуссию от всех этих теорий заговора, здесь им не место. Рефлексия — это естественный механизм получения метаинформации от компилятора. Если поддержки компилятора нет — то и рефлексии нет, и НИКАКАЯ библиотека не способна извлечь информацию, которой у нее нет и быть не может, пока компилятор ее не предоставит. Неужели это так сложно понять?
Если делать генерацию кода как следует, то все будет ОК. Просто до сих пор нормально никто не сделал, делали тупо «в лоб». Как минимум, при генерации кода обязательно должна создаваться метаинформация о связи генерирующего и сгенерированного кода, и активно использоваться при отладке и даже при редактировании кода.
Ответил выше: простота языка — это перекладывание проблем на плечи пользователей, все чего нет в языке им придется допиливать вручную. Все равно придется, только вместо единой реализации в языке будет 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). Но то, что эти библиотеки появились, и что ими, несмотря на сложности, пользуются — признак того, что соответствующие возможности реально востребованы.
Что вы имеете в виду? Получение ссылки на процедуру во время выполнения программы по динамической строке с именем?
В общем, такого категорически не должно быть. Поэтому лучше, чтобы все фичи были официально задокументированы в стандарте языка, и — что не менее важно — чтобы не было никаких фич, не описанных в стандарте.
По рефлексии — если компилятору известно чуть больше, это уже языковая фича. Конкретные применения этой фичи (например запись в xml, json, binary) — это действительно должно быть в библиотеках, но если в компиляторе нет ничего для базовой поддержки — то остаются только нагромождения костылей (как это и есть в С++). Одна маленькая фича в компиляторе позволит выкинуть множество неестественных и ненадежных нагромождений в библиотечном и прикладном коде. В этом и смысл языковых фич.
О балансе — в С++ нарушением баланса (ИМХО конечно) являются не сами шаблоны, а метапрограммирование на них. А сами шаблоны вполне сбалансированы. По изначальному замыслу предполагалось, что шаблоны будут вот для таких конструкций
а не для написания полноценных парсеров времени компиляции (boost.spirit) или compile-time коллекций типов и операций над ними (boost.mpl). Но то, что эти библиотеки появились, и что ими, несмотря на сложности, пользуются — признак того, что соответствующие возможности реально востребованы.