Logo

20 ноября 2013 г.

Тезисы к семинару на Embedded Meetup #2

Вводная

Бизнес-план Гордона Мура изменил направление и теперь по-другому влияет на развитие технологий. На одном из выступлений докладчик Intel назвал закон Мура бизнес-планом Мура, а потом продемонстрировал график, на котором монотонный рост вычислительной мощности преломляется в момент появления первого двухъядерного процессора, после чего фактическое увеличение быстродействия ПО отстает от номинальной производительности процессоров: программы не могут использовать возможности железа, график делится надвое.

Кроме того, есть множество технологий, появившихся еще в 70-е годы XX века, но так и не нашедших воплощения на системном уровне. Было много попыток разработать объектно-ориентированную ОС, но все они так и остались в лабораториях. Почему? Неужели по-прежнему не хватает вычислительной мощности? А кто помнит слова Алана Кея: "Создавая ООП, я не имел в виду C++"?

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

Что предлагаю я: массовое функциональное программирование

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

Сегодняшняя популяризация ФП-языков вроде Haskell и Erlang показывает, что интерес к направлению есть, но на мой взгляд, он недостаточен. Чтобы ФП стало массовым, оно должно повернуть лицом к рядовому программисту, стать менее камерным, элитарным и запутанным. Эта проблема может быть решена созданием инструментов, позволяющих решать задачи в той же системе ценностей, что и сейчас, но используя ФП. А начать нужно с языка, с нацеленного на замену императивного программирования функциональным, вплоть до преподавания ФП в школе. В силу возраста уже не все помнят, но когда-то преподавание информатики и программирования в школе тоже было из области сказок, но усилиями профессора Вирта и академика Ершова было превращено в реальность. Новый язык вполне может повторить успех Паскаля, только уже с ФП.

Что предлагаю я: фрактальная ОС

Зачем вообще нужно ООП на уровне ОС? Что под ним понимается? Удивительно, но до сих пор нет четкого термина. Даже больше, мои исследования показали, что у системных программистов есть какой-то другой взгляд на ООП, отличающийся от общепринятого. Поэтому я предлагаю простое и емкое определение объектно-ориентированной ОС: "ОС, позволяющая создавать программы наследованием". То есть, взяли "Блокнот", унаследовали, добавили нужное и получили WordPad; опять унаследовали, опять добавили и получили Word.

Вопрос к скептикам: как вы получаете список файлов? Вызываете FindFirst с маской, а потом много раз FindNext, получая файлы по одному. Есть ли простой способ узнать количество файлов в каталоге? Это в 2013-то году? Если же в ОС будет некий стандартизированный набор контейнеров, получение списка файлов — это получение объекта "список", заполненного объектами "файл". Получение количества файлов в списке также не составляет труда.

На самом деле нечто похожее пытались реализовать еще Microsoft в 1993-1999 годах в рамках проекта под кодовым названием Cairo. Именно для будущей объектно-ориентированной ОС была создана модель COM, потоки NTFS и многое другое. Но Cairo был закрыт, а его наработки частично вошли в то, что мы знаем под именем Windows 2000. Позже ситуация повторилась с так называемыми WinFS и WinFX, разрабатывавшимися в рамках Longhorn, но не вошедшими в состав Windows Vista, а позже выпущенными отдельными продуктами. Почему так?

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

Согласно моим выводам, проблема хрупкого базового класса может быть решена только одним способом — отказом от исходных текстов в пользу обратимого байт-кода. Программирование при этом будет больше похоже на работу с базой данных: вытащил функцию, перевел в текстовый вид, исправил, вкомпилировал обратно. Ядро системы при этом само отслеживает зависимости по наследованию, агрегации, полиморфизму, позднему связыванию и т. п.

Таким образом, разработка нового языка решает не только проблему массового ФП и параллелизма, но и хрупкого базового класса, давая тем самым технологическую основу для создания фрактальной ОС.

Как плюс такая ОС обеспечит многовложенную структуру данных, дав недостающую третью координату — глубину, что и станет основой для создания логически трехмерного пользовальского интерфейса — ZUI. Возьмите любой труд по ZUI — наличие структуры данных там ненавязчиво подразумевается, хоть может и не упоминяться явно. Моя главная книга по ZUI — последняя книга Джефа Раскина, где он еще называет интерфейс Zoom World... Как понимаю, термин ZUI устоялся уже после смерти Раскина.

Что предлагаю я: суперкомпиляция

В ходе проектирования также выяснилось, что генерация конкретного кода из более общего с учетом условий вызова называется суперкомпиляцией (metacompilation или supervising compilation в западных источниках). По-научному такая кодогенерация еще зовется генератором тождественных преобразований. Идея суперкомпиляции и сам термин были придуманы в Советском Союзе и разрабатывались Валентином Турчиным в языке Рефал. В Рефале, как я понял, используется частный случай суперкомпиляции, ориентированный больше на обработку строк. Возможно, что приемы суперкомпиляции уже применялись к языку общего назначения, но мне такие примеры неизвестны. Слышал только, что-то похожее есть в Java-машине HotSpot, но подробно не изучал.

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

Суперкомпилятор позволит избавиться от проблемы недостаточной производительности JIT, на что жалуются пользователи JVM и .NET. При этом качественный JIT на движке суперкомпилятора создать можно, а вот наоборот — нет. Разрабатываемый язык специально затачивается под суперкомпиляцию, переводя многие знакомые программистам вещи, реализованные в обычных языках "в лоб", на логический, понятийный уровень.

Заключение: что сейчас

Проект прошел стадию проектирования и постепенно реализуется в коде. Поскольку проект технологический и с большой долей нововведений, сделана ставка на технологическое лидерство. Технологический лидер может быть только self-hosted (не знаю русского термина), поэтому использование инструментов других технологических лидеров по возможности сводится к минимуму. Воспользовался чужим инструментом для чего-то серьезного? Всю жизнь будешь молиться на разработчиков этого инструмента: как бы багов не занесли, функциональность не ухудшили да поддержку не прекратили, чего доброго. Несмотря на небольшой срок реализации проекта в коде, тезис уже не раз получил подтверждение на практике (тут я могу ввернуть что-то нехорошее про исходники "Фантома").

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

После CoreLite будет реализован вики-процессор — компилятор вики-разметки, разработанной в рамках проекта. Вики-процессор позволит сделать сайт с документацией, работающий поверх SVN. Кроме того, библиотека вики-процессора будет использована и в компиляторе, поскольку вики-разметка встроена в язык программирования — в нем есть понятия вики-текста (форматированный текст) и вики-комментариев. Вики-разметка имеет строгий синтаксис и подразумевает леворекурсивный разбор, поэтому на ней также будет отрабатываться и эта часть будущего компилятора.

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

(вопросы)

Комментариев нет :

Отправить комментарий

Выбрав в выпадающем списке пункт «Имя/URL», можно оставить комментарий от своего имени без предварительной регистрации.