Язык O/O++

O/O++ — язык высокого уровня, надстройка над C/C++.
Репозиторий проекта

История

Как известно, изначально программирование предполагало непосредственное введение двоичных машинных кодов, что было тем ещё удовольствием. Нет ничего удивительного, что человек предпочёл упростить себе задачу, введя сборочный язык — он же ассемблер — который давал набор текстовых команд, при компиляции однозначно превращавшихся в двоичный код. В целом компиляторры ассемблера были чуть сложнее простых текстовых процессоров, их задачей была лишь замена текста на набор нулей и единиц. Со временем, продолжая идти по тому же пути, ассемблер оброс такими возможностями, как определение переменных, типизация и автоматическое вычисление сдвигов и стал т.н. макроассемблером. Принципы были те же, только механизм перевода стал чуть умнее.

В какой-то момент код стал настолько сложным, что люди начали задавать себе логичный вопрос: а нельзя как-то всё то, что мы обычно делаем — структуры, массивы, стопка(stack) вызовов — встроить сразу в язык? Так начали появляться языки высокого уровня (ЯВУ). Языков этих очень много, регулярно умирают старые и появляются новые, чтобы снова умереть, но в целом базой для первых ЯВУ был именно перевод (трансляция) исходников на понятном языке (зачастую эдаком макроассемблере на стероидах, или макро-макроассемблере) в двоичный код. Одним из таких языков был пресловутый K&R C. Он снискал заслуженную славу, поскольку был достаточно высокоуровнев, давая структуры и функции в отличие от ассемблера, и одновременно оставался низкоуровневым языком, позволяя гибко работать с памятью, нежели паскаль или бейсик, выполняясь прямо на железе с миниумом абстракций, что позволяло именно бегать, а не ползать как языки с виртуальными машинами и исполняемыми средами. Чуть позже появилась стандартная библиотека, которая только усилила кроссплатформенность и окончательно закрепила C в качестве базового языка практически любой системы. Желающие также могут вспомнить про единый C ABI, одну из причин вечных шуточек «сишников» над фанатами «плюсов».

Тут надо заметить, что текстовая суть C (лёгшая и в основу UNIX-подхода) как макро-макроассемблера торчит прямо из него в виде препроцессора, без которого сам язык просто немыслим.

При всех своих плюсах (каламбур), голый C не имел очень важных инструментов, которые — внезапно! — начинают требоваться с ростом сложности проекта (где-то мы это уже слышали). Не было инструментов объектного программирования (структуры были круты, но слабоваты), не было обобщений, не было средств безопасности, даже мой любимый «чёрный ящик» был проблематичным, зато в наличии имелись бесчисленные способы отстрелить себе правую ногу до левого уха. Мы понимаем, что нативный язык нуждается в умном программисте и типовой скриптомакаке тут не место, но C на сложных задачах требовал от разработчика самому быть компьютером и держать всё в голове либо плодить костыли и страдать.

Поэтому нет ничего удивительного в возникновении C++ — языка, который я не могу полностью одобрять из-за страного пути развития, но не могу и не любить за способность совмещать высокие абстракции с близостью к железу. Несмотря на родство и совместимость с C, плюсы могут считаться языком сверхвысокого уровня вроде тех же java или C# и в этом плане Бьёрн (Бьярн?) Страуструп Беарне Строуструп молодец.

Это не значит, что C++ — идеал, проблем хватает. И в первую очередь больше всего донимает именно совместимость с C. Мелочи синтаксиса, имевшиеся в С (и перекочевавшие в него из предыдущих макро-языков довольно низкого уровня) вызывают оторопь у опытных программистов, меняющих язык, а новичкам и вовсе ломают жизнь. Изменить всё это сразу невозможно — уж очень много кода и библиотек написано, нельзя выкатить C/C++30 и сказать: «всё, конец бардаку, вот вам адекватный язык», потому что потом придётся много бегать, долго скрываться и регулярно менять личность.

Ситуация не стоит на месте и на делается множество попыток уничтожить C/C++. Есть армада языков со своими средами, упорно побеждающая в рекламе, но неспособная обойти накладные расходы. Есть нативные языки — от непонятного, медленного и вечно меняющегося Rust до логичного, но почему-то испорченного встроенной сборкой мусора D (Александреску, за что?). Количество велосипедов и колёс упорно растёт, но редкий продукт способен проехать сотню-другую метров. Все альтернативы выглядят как попытка сделать торт из отходов, и ситуация не улучшается. Абстракции текут, возможности сокращаются, ассемблерщики ржут и тычут копьями из палок с камнями.

Так не могло продолжаться вечно и пришло понимание: в сложившейся ситуации возможным решением может стать язык, который будет всего лишь макроязыком над C/C++, который сможет прозрачно превращаться в любимые нами си и плюсы и будет лишён проблем совместимости с существующим кодом. Действительно, зачем создавать язык с нуля, если уже есть готовый и мощный инструмент, требующий небольших доработок? И самое интересное, что будучи отточенным на отдельном трансляторе и доведённый до ума, он имеет шанс стать встроенной опцией в имеющихся компиляторах C/C++ — разве не хорошая цель?

Итак, на сцену выходит язык O/O++ — тот же самый C/C++, но с недостающими деталями

Принципы

  1. O/O++ — макроязык, надстройка над C/C++. Результат компиляции языка — правильный C/C++ код.
  2. O/O++ не создаёт ненужные абстракции.
  3. O/O++ призван решать проблемы синтаксиса и удобства.

Организация проекта

Проект состоит из двух частей — непосредственно файла спецификации olang.txt и папки chalkboard, где в виде .txt и .md файлов хранятся черновики отдельных предложений. Любой человек может внести своё предложение или исправление через запрос на принятие (pull request) или обращение любым удобным ему способом. После минимальной проверки на соответствие изменений целям проекта осуществляется их внесение в основной каталог — папку chalkboard. Возможен отказ, но не стоит отчаиваться — причина обязательно будет указана.

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

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

Спецификация (загружается отсюда)