Свой язык и компилятор
(01) Первый блин лучше комом, чем никак!

Здравствуйте, дорогие подписчики!

Оказывается, не так просто выпускать рассылки, как я думал :). Проблемы, конечно, не технические. Необходимо собрать свои разрозненные мысли воедино и более-менее вменяемо изложить их в письменной форме. А сочинения я последний раз писал очень давно :). Пока мысли путаются в голове, они кажутся очень привлекательными и порою даже гениальными :). Но стоит попытаться их озвучить или изложить письменно, так они как тараканы при включении света разбегаются в разные стороны и прячутся по щелям, как будто их и не было. Иногда чувствую себя как та собака, которая всё понимает, но сказать ничего не может, кроме «Гав! Гав!». А в остальное время нет даже понимания :). Потихоньку выковыривая «тараканов» из их щелей и внимательно рассматривая, начинаешь понимать их «тараканью» сущность. Хотя надежда найти среди них парочку золотых (или хотя бы серебряных) меня всё ещё не покидает :).

Ну вот, пожаловался на тяжесть творческих мук, и сразу стало легче :). Итак, ЧТО же мы всё-таки будем здесь делать и ЗАЧЕМ?

На второй вопрос предлагаю ответить вам самостоятельно. Ведь зачем-то же вы подписались?! Наиболее интересные ответы я размещу в рассылке. Возможно, это поможет определиться остальным. Не забудьте, прислать свой ответ мне. А то публиковать будет нечего :). Свой ответ я тоже опубликую.

Кстати, ответ на первый вопрос вам тоже придётся давать самим :). Не могу же я решать за вас, что и как вам делать!

А теперь перейдём к тем «тараканам», которых мне удалось наковырять.

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

Хотелось бы, конечно, создать супер-пупер-универсальный язык, который удобно было бы использовать для решения любых задач программирования. Но в результате может получиться трудно реализуемый и неудобный монстр. Попробуем исходить из реалий сегодняшнего дня и собственных возможностей. А реалии на сегодня таковы, что основная масса процессоров в существующих компьютерных системах ориентирована на исполнение арифметических операций и управляющих команд. Для программирования таких систем, по моему глубокому убеждению (или заблуждению :)), наиболее подходящими были и пока остаются так называемые императивные языки. Это С/С++, Ада, все языки Вирта от Паскаля до Оберона и им подобные. Ассемблер я опускаю, т.к. он изначально аппаратно зависим.

Конечно, существует масса задач, для описания и решения которых придуманы гораздо более удобные и универсальные языки. Например, язык запросов к базам данных SQL, функциональные и логические языки. Надо сказать, что функциональные языки — это очень интересная и набирающая обороты область. Но я в них пока не силен :(.

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

Какие же требования выдвинем к будущему языку? Они, скорее всего, будут вытекать из тех областей применения, на которые он (язык) прежде всего будет ориентирован. Естественно, я жду ваших пожеланий и предложений, дорогие подписчики. Вы же подписались на эту рассылку не только для чтения, я надеюсь?

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

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

Об идеологии будущего языка. Здесь мне более близки идеи Вирта (Паскаль, Модула, Оберон), нежели создателей С/С++. Возможно это потому, что одним из первых изученных мною языков программирования был Паскаль, а сейчас я больше использую Delphi, который последнее время начинает вызывать у меня неприятные ощущения в собственной глупости :). C++ — это вообще для меня как высшая математика для аборигена. Но я не могу назвать себя безусловным поклонником Виртовских концепций. Мне не всё нравится в Обероне. В то же время есть вещи в С/С++, которые мне нравятся. А Vladimir Los ещё навёл меня на Смолток. Почитав немного про Смолток, я был поражён той объектно-ориентированной концепцией, которую он представляет. Ведь она гораздо ближе к естественному миру и гораздо гибче, чем классы в C++ и Delphi. Но, как известно, за всё приходится платить. Я так и не понял, как можно организовать быструю посылку и обработку сообщений в Смолтоке, если каждый раз приходится осуществлять поиск метода по его имени. Эмулируя «естественность» объектов на «неестественной» последовательной машине, мы катастрофически теряем производительность. Ведь в естественном мире все объекты функционируют (живут) одновременно! А в компьютере «жизнь» моделей объектов похожа на стоп-кадр. Причём с каждым кадром мельчайшие изменения происходят не во всей «картинке», а только в одном объекте. И приходится ждать, пока изменения последовательно пройдут по всем объектам, чтобы перейти к следующему «кадру». Сами понимаете, что ни о какой динамичности картины в целом не приходиться даже мечтать. Вот если бы мы создали компьютер, который мог бы обеспечить одновременное функционирование бесчисленного количества «объектов» и такого же количества их составляющих, то мы приравнялись бы к богам… :o

Да уж. После таких рассуждений понимаешь, насколько мы ещё далеки от Творца. Но с чего-то же надо начинать путь к нему?!

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

ООП. Куда же без него родимого?! :) Однако тема эта слишком обширна и достойна отдельного выпуска рассылки. К тому же, в связи с моим недавним беглым знакомством со Смолтоком, мне необходимо переосмыслить концепции ООП. Каковы вообще нужны уровни абстракции объектов? Прошу высказываться.

Модульность. Мне очень нравится идея разбивки программы на чёткие самодостаточные модули с их раздельной компиляцией или хотя бы предварительной обработкой для последующей быстрой компиляции на лету. Это очень удобно. Особенно если обеспечить возможность независимой загрузки, выгрузки и перекомпиляции этих модулей (например, как в Оберон-системах). Здесь Vladimir Los опять правильно мне подсказал, что «Заслуга Вирта в чётком осознании, что развивать надо СИСТЕМУ программирования (постепенно интегрируя её в ОСь), а не отделно язык». Я полностью с этим согласен. Но Системы у меня пока нет :). Возможно, и до неё дорасту когда-нибудь, когда пойму как это всё должно функционировать в распределённых системах.

Обобщённое программирование. Оно помогает реализовать принцип «Один раз пишем — много раз используем». Любые средства, которые помогают значительно облегчить нелёгкий труд программиста без катастрофического падения скорости компиляции и эффективности конечной программы, обязательно должны быть нами рассмотрены. Эта тема также достойна отдельного выпуска. Прошу направлять мне свои соображения.

Макросы. Не знаю, относятся ли макросы к обобщённому программированию, но мне не нравятся макросы, основанные на подмене текста программы и требующие препроцессора. Использование таких макросов приводит к деформации языка и затруднению чтения и понимания кода, хотя и даёт большой простор для гибкости. Но, если каждый из нас начнёт придумывать и использовать свои собственные синонимы к общеупотребительным словам, то общение и взаимопонимание будет сильно затруднено, если вообще возможно. Помните, из-за чего развалилась Вавилонская Башня?

Исключения. Механизм обработки исключений чем-то похож на механизм транзакций в базах данных, обеспечивающий целостность данных при грамотном использовании. Дебаты о необходимости механизма обработки исключений в языках программирования идут постоянно. В Обероне его нет, а в С++, Java и Delphi есть. В большом проекте, состоящем из множества частей и модулей ошибки, скорее всего, неизбежны. Выловить их все без промышленной эксплуатации проекта очень тяжело. А в промышленной эксплуатации очень важна стабильность работы системы даже при выходе из строя какого?то модуля. Конечно, неприятно увидеть окно ошибки, например, в той же среде Delphi, выскочившее по неизвестной для меня причине, но это всё равно лучше чем, если бы Delphi завершила свою работу по этой ошибке, не сохранив мой проект. Ещё лучше, если бы таких неприятностей в Delphi не было вообще. Но это как раз от меня не зависит :). В общем, механизму исключений быть, но не в первой версии нашего языка :). Компилятор может обойтись и без него. Хочется всё же иметь возможность полностью или частично отказываться от этого механизма в угоду скорости.

Автоматическая сборка мусора. Её необходимость и эффективность спорны. Опять в одних языках она есть и даже является неотъемлемой частью системы (Оберон), в других языках такой механизм отсутствует (Delphi), но присутствует механизм исключений, позволяющий корректно освобождать память, если память программиста напомнит ему об этом :). Существуют также языки, в которых присутствуют оба эти механизма (Java). Автоматическая сборка мусора освобождает программиста от рутинной работы по освобождению памяти, сокращая тем самым исходный код программы со всеми вытекающими положительными последствиями. К тому же, на мой взгляд, автоматическая сборка мусора могла бы несколько улучшить скорость работы пользовательских приложений на современных компьютерах за счёт того, что работа по освобождению памяти от мусора откладывается на момент простоя процессора. Естественно, за автоматическую сборку мусора мы расплачиваемся более медленной процедурой сборки мусора и повышенными требованиями к объёму памяти из-за откладывания процедуры её освобождения. Но если сборка мусора будет происходить только во время простоя процессора, то это не беда. Соответственно, в критических приложениях, загружающих процессор и память под 100%, мы уже вряд ли сможем воспользоваться автоматической сборкой мусора из-за её медлительности. Но думаю, что основная масса пользовательских приложений к критическим не относится. Однако, проблема ещё и в том, что я просто не знаю, как эффективно реализовать автоматическую сборку мусора. Поэтому пока отложим её «до выяснения»… :) Компилятор может обойтись без неё. Если у кого-то есть информация по эффективным алгоритмам сборки мусора (в программах :)), очень прошу со мною поделиться.

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

Многозадачность. Она начинает входить в нашу жизнь и в обычные домашние компьютеры уже сейчас и даже на аппаратном уровне. В моём компьютере, правда, пока только один процессор :). А у вас? Отложим многозадачность до лучших времён :).

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

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

ПОСЛЕСЛОВИЕ

Ура! Первый выпуск рассылки выпущен! :) В нём мы начали говорить о «тараканах» и будущих возможностях нашего языка. Очень многое осталось «за кадром», ещё больше я забыл или никогда не знал :) (прошу напомнить и просветить). Но мы ведь только начали!

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

В следующем выпуске мы начнём обсуждать базовые типы нашего языка. Мы, правда, ещё не обсудили главные концепции. Но их можно обсуждать бесконечно. И мы будем продолжать их обсуждать :) параллельно с описанием синтаксиса. Что-то (возможно, всё) потом будет пересматриваться.

Кстати, посоветуйте, пожалуйста, где можно открыть форум для нашей рассылки? Многие вопросы было бы проще обсуждать в форуме. Желательна поддержка форумом NNTP-протокола, чтобы можно было его читать оффлайн. Cписки рассылки (вроде Yahoo Groups) не люблю. В крайнем случае, конечно, можно воспользоваться услугами talk.mail.ru.

Жду ваших писем... :)