В начале 2008, с подачи депутатов госдумы, в интернете возникло обсуждение необходимости создания национальной ОС. Возникла инициативная группа под руководством Руслана Богатырева (все делфисты должны его помнить, он много писал про Паскаль), для проектирования российской ОС Роса. Я обменялся с Русланом несколькими письмами, где попытался высказать некоторые свои мысли. к сожалению, проект заглох, как объяснял Руслан в силу внутренних организационных противоречий, и сегодня я не знаю в каком он состоянии, но решил попытаться возобновить дискуссию, опубликовав часть нашей переписки.
Руслан в своем блоге в посте № 30 рассказывал о теории метасистем Турчина. Мне кажется, что она может послужить отличным инструментом при проектировании и ОС и языков программирования. Насколько я понял, одним из ключевых ее моментов является понятие метасистемного перехода, происходящего при качественном скачке в уровне сложности некоторой системы. Возможно тогда рассмотреть эволюцию компьютеров, ОС и языков программирования с точки зрения наличия таких метапереходов.
Для наглядности проведем аналогию компьютерных систем с живыми, тем более что такой аналогией пользуются многие, да и создание программ более похоже на селекцию животных, чем проектирование автомобиля. Тогда имеющиеся аппаратные ресурсы ЭВМ будут представлять, скажем, первичный био-бульон, в котором зарождается жизнь программ. Первые программы в машинных кодах и на ассемблере будут выступать как первые одноклеточные организмы. Их возможности ограничены произведением элементарных вычислительных операций и манипулированием ячейками памяти, т.е. «одноклеточные» берут из окружающей среды «аминокислоты» и т.п.
С ростом сложности таких «одноклеточных» возникает первый метапереход. Программы начинают писать на высокоуровневых языках, т.е. инструментах, которые скрывают множество элементарных операций под оболочкой языковых конструкций. Это возникновение «многоклеточных организмов». Аппаратура же начинает абстрагироваться под операционными системами. Т.е. «питательная среда» для программ тоже усложняется, это уже не прямые команды ЦПУ или операции с ячейками памяти, а запросы к ОС на выделение памяти или производство тригонометрических вычислений. Итак, первый метапереход — возникновение императивных языков и ОС, скрывающих мелкие детали устройства аппаратуры, но все еще требующих точного и детального описания выполняемых действий. Т.е. хоть языки и усложнились, они всё ещё требуют оперирования с «мелкими» сущностями вроде областей памяти.
Почему я выделяю только императивные языки. По моему мнению, возникновение функционального и логического программирования, это новый метапереход в уровне языка. В функциональных языках программа оперирует уже не столько областями памяти и вычислительными операциями, сколько состояниями системы и действиями по его изменению. А в логических языках от нас «скрываются» и вычисления. Т.е. на мой взгляд, функциональные языки должны были в результате метаперехода сменить императивные, а их в свою очередь сменили бы логические. Но метапереход возможен только при готовности к нему всей системы, а аппаратные возможности и организация ОС к этому не готовы.
Как в любой сложной системе, в программировании выделятся разные уровни управления, ведущие к разным метапереходам. Если функциональный и логический методы можно рассматривать как метапереход в организации процесса работы программы, то тогда возникновение структурного программирования было метапереходом в организации подсистем и их взаимодействии. Модульное и объектное программирование это следующий переход в организации подсистем. Причем, с такой точки зрения, они практически равноценны. Хотя, может быть, можно принять объектный подход за очередной метапереход, т.к. он добавил новый механизм наращивания сложности подсистем — наследование. Но тут вопрос осложняется тем, что хотя наследование позволяет увеличить многоуровниевость системы, организовать больше подсистем, оно не добавляет нового уровня управления возникающими подсистемами. Т.е., грубо говоря, на уровне программы конструкция «Сущность.Метод()» не изменяется, и нам нет разницы что скрыто под этой сущностью — модуль, родительский объект или потомок.
Скорее уж, на роль метаперехода может претендовать не наследование, а полиморфизм. Он позволяет упростить управление программой, т.к. позволяет сократить число конструкций осуществляющих диспетчеризацию вызовов конкретных методов. Причём, если учитывать внутреннюю конструкцию полиморфизма, более всего для этого подходит именно динамический полиморфизм в стиле SmallTalk. Здесь уместно упомянуть интересный вариант предложенный доктором профессором А.И. Легаловым из Сибирского федерального университета (я эту идею увидел именно у него). Он предложил строить полиморфизм не на от объекта, а от метода. Т.е., в его варианте, получилась конструкция «Метод.Сущность()».
Почему мне кажется такой подход более перспективным? Число возможных сущностей может быть неограниченно большим. Нашу фантазию по созданию различных программных объектов ограничивает только наша возможность держать такую систему под контролем. А введение новых сущностей в систему, если они не вписываются в наследование и не проходят типовой контроль, потребует добавления новых конструкций управления. Число же разумных действий над объектами гораздо меньше и разработав некоторую схему управления её можно будет применять ко всем сущностям, имеющимся и вновь создаваемым.
Теперь отвлечемся на время от наших организмов-программ и вернемся к среде обитания ОС. Организовав первичный бульон аминокислот из ячеек памяти и ресурсов процессоров в некое подобие растительности в виде наборов API, операционные системы задержались на этом уровне надолго. Единственным значительным метапереходом можно назвать только возникновение UNIX-вой унификации представления всех ресурсов как файлов и сведению множества действий операционной системы к операциям чтения-записи. Именно наличие такого метаперехода в управлении ресурсами компьютера и послужило стимулом популярности UNIX модели. И именно отсутствие качественных различий в организации и управлении не позволяет говорить о преимуществах Linux перед Windows это системы однотипные.
Однако, развитие объектной модели в языках программирования должно было привести к новому метапереходу в ОС представлению ее сервисов в виде набора объектов. Именно потребность такого перехода для приведения в соответствие уровня организации языков программирования и организации ОС, привела к возникновению проектов типа архитектуры OpenDoc от Apple или системы BeOS. Фактически, успех платформ Java и .NET обусловлен именно наличием качественно скачка в организации представлению всех ресурсов среды в виде набора высокоуровневых объектов. Т.е. можно сказать что во флоре API появилась фауна объектов. Получилась интересная картинка, «программы-организмы» (сложные организмы созданные на ОО-языках, т.е. состоящие из сложных подсистем «мозга», «желудка», «конечностей» и т.д.) пытаются выжить и функционировать среди других организмов других программ и ресурсов ОС. Животный мир во всем великолепии и разнообразии.
Сделаем еще один «параллельный» взгляд. Если в управлении сложностью языков программирования и устройства ОС осуществлялись метапереходы, то в борьбе с количественной стороной, т.е. с числом документов, программ, версий исходников и т.п., был только один общий метапереход изобретение иерархической файловой системы. К сожалению, программы вроде системы контроля версий не вышли за пределы узкого круга профессионалов. И попытки Microsoft создать систему хранения на основе базы данных это именно проблески метаперехода в управлении количеством информационных единиц.
И так, что у нас получается?
Вот какие мы выделили метапереходы:
А теперь, позволю себе наглость сформулировать такую теорему:
Успех новой системы возможен только при наличии в ней нового метаперехода по сравнению со старой системой!
А вот за счет каких качеств будет осуществлен такой переход, требует дополнительного и длительного размышления…
Еще раз вернувшись к теории Турчина, вспомним, что метапереход характеризуется упрощением управления в усложнившейся системе. В некоторой степени это перекликается с идеями Стаффорда Бира об организации кибернетической системы в которой каждый предыдущий уровень служит для выделения из общего потока данных лишь ключевых параметров с целью снижения информационной нагрузки на последующий уровень. Т.е., главный стимул развития — борьба со сложностью! А метапереход — успешное решение в этой борьбе. Значит, для определения целей развития нужно выделить уровни сложности которые требуется упростить для получения нового качества разрабатываемой системы.
Исходя из этих соображений, позволю себе смелость сформулировать следующие тезисы.
Сложность ОС (ядро):
Сложность языка программирования:
Сложность ОС (интерфейс пользователя):
Уф, вот так вот в первом приближении… Очень даже может быть, что я что-то упустил, но тут без взгляда со стороны трудно обойтись.
Может быть, кому-то поднятые вопросы интересны и он захочет продолжить обсуждение?
Руслан в своем блоге в посте № 30 рассказывал о теории метасистем Турчина. Мне кажется, что она может послужить отличным инструментом при проектировании и ОС и языков программирования. Насколько я понял, одним из ключевых ее моментов является понятие метасистемного перехода, происходящего при качественном скачке в уровне сложности некоторой системы. Возможно тогда рассмотреть эволюцию компьютеров, ОС и языков программирования с точки зрения наличия таких метапереходов.
Для наглядности проведем аналогию компьютерных систем с живыми, тем более что такой аналогией пользуются многие, да и создание программ более похоже на селекцию животных, чем проектирование автомобиля. Тогда имеющиеся аппаратные ресурсы ЭВМ будут представлять, скажем, первичный био-бульон, в котором зарождается жизнь программ. Первые программы в машинных кодах и на ассемблере будут выступать как первые одноклеточные организмы. Их возможности ограничены произведением элементарных вычислительных операций и манипулированием ячейками памяти, т.е. «одноклеточные» берут из окружающей среды «аминокислоты» и т.п.
С ростом сложности таких «одноклеточных» возникает первый метапереход. Программы начинают писать на высокоуровневых языках, т.е. инструментах, которые скрывают множество элементарных операций под оболочкой языковых конструкций. Это возникновение «многоклеточных организмов». Аппаратура же начинает абстрагироваться под операционными системами. Т.е. «питательная среда» для программ тоже усложняется, это уже не прямые команды ЦПУ или операции с ячейками памяти, а запросы к ОС на выделение памяти или производство тригонометрических вычислений. Итак, первый метапереход — возникновение императивных языков и ОС, скрывающих мелкие детали устройства аппаратуры, но все еще требующих точного и детального описания выполняемых действий. Т.е. хоть языки и усложнились, они всё ещё требуют оперирования с «мелкими» сущностями вроде областей памяти.
Почему я выделяю только императивные языки. По моему мнению, возникновение функционального и логического программирования, это новый метапереход в уровне языка. В функциональных языках программа оперирует уже не столько областями памяти и вычислительными операциями, сколько состояниями системы и действиями по его изменению. А в логических языках от нас «скрываются» и вычисления. Т.е. на мой взгляд, функциональные языки должны были в результате метаперехода сменить императивные, а их в свою очередь сменили бы логические. Но метапереход возможен только при готовности к нему всей системы, а аппаратные возможности и организация ОС к этому не готовы.
Как в любой сложной системе, в программировании выделятся разные уровни управления, ведущие к разным метапереходам. Если функциональный и логический методы можно рассматривать как метапереход в организации процесса работы программы, то тогда возникновение структурного программирования было метапереходом в организации подсистем и их взаимодействии. Модульное и объектное программирование это следующий переход в организации подсистем. Причем, с такой точки зрения, они практически равноценны. Хотя, может быть, можно принять объектный подход за очередной метапереход, т.к. он добавил новый механизм наращивания сложности подсистем — наследование. Но тут вопрос осложняется тем, что хотя наследование позволяет увеличить многоуровниевость системы, организовать больше подсистем, оно не добавляет нового уровня управления возникающими подсистемами. Т.е., грубо говоря, на уровне программы конструкция «Сущность.Метод()» не изменяется, и нам нет разницы что скрыто под этой сущностью — модуль, родительский объект или потомок.
Скорее уж, на роль метаперехода может претендовать не наследование, а полиморфизм. Он позволяет упростить управление программой, т.к. позволяет сократить число конструкций осуществляющих диспетчеризацию вызовов конкретных методов. Причём, если учитывать внутреннюю конструкцию полиморфизма, более всего для этого подходит именно динамический полиморфизм в стиле SmallTalk. Здесь уместно упомянуть интересный вариант предложенный доктором профессором А.И. Легаловым из Сибирского федерального университета (я эту идею увидел именно у него). Он предложил строить полиморфизм не на от объекта, а от метода. Т.е., в его варианте, получилась конструкция «Метод.Сущность()».
Почему мне кажется такой подход более перспективным? Число возможных сущностей может быть неограниченно большим. Нашу фантазию по созданию различных программных объектов ограничивает только наша возможность держать такую систему под контролем. А введение новых сущностей в систему, если они не вписываются в наследование и не проходят типовой контроль, потребует добавления новых конструкций управления. Число же разумных действий над объектами гораздо меньше и разработав некоторую схему управления её можно будет применять ко всем сущностям, имеющимся и вновь создаваемым.
Теперь отвлечемся на время от наших организмов-программ и вернемся к среде обитания ОС. Организовав первичный бульон аминокислот из ячеек памяти и ресурсов процессоров в некое подобие растительности в виде наборов API, операционные системы задержались на этом уровне надолго. Единственным значительным метапереходом можно назвать только возникновение UNIX-вой унификации представления всех ресурсов как файлов и сведению множества действий операционной системы к операциям чтения-записи. Именно наличие такого метаперехода в управлении ресурсами компьютера и послужило стимулом популярности UNIX модели. И именно отсутствие качественных различий в организации и управлении не позволяет говорить о преимуществах Linux перед Windows это системы однотипные.
Однако, развитие объектной модели в языках программирования должно было привести к новому метапереходу в ОС представлению ее сервисов в виде набора объектов. Именно потребность такого перехода для приведения в соответствие уровня организации языков программирования и организации ОС, привела к возникновению проектов типа архитектуры OpenDoc от Apple или системы BeOS. Фактически, успех платформ Java и .NET обусловлен именно наличием качественно скачка в организации представлению всех ресурсов среды в виде набора высокоуровневых объектов. Т.е. можно сказать что во флоре API появилась фауна объектов. Получилась интересная картинка, «программы-организмы» (сложные организмы созданные на ОО-языках, т.е. состоящие из сложных подсистем «мозга», «желудка», «конечностей» и т.д.) пытаются выжить и функционировать среди других организмов других программ и ресурсов ОС. Животный мир во всем великолепии и разнообразии.
Сделаем еще один «параллельный» взгляд. Если в управлении сложностью языков программирования и устройства ОС осуществлялись метапереходы, то в борьбе с количественной стороной, т.е. с числом документов, программ, версий исходников и т.п., был только один общий метапереход изобретение иерархической файловой системы. К сожалению, программы вроде системы контроля версий не вышли за пределы узкого круга профессионалов. И попытки Microsoft создать систему хранения на основе базы данных это именно проблески метаперехода в управлении количеством информационных единиц.
И так, что у нас получается?
Вот какие мы выделили метапереходы:
- Языки (управление работой ЭВМ): императивные функциональные логические.
- Языки (управление сложностью программы): структурное программирование модульно-объектное.
- ОС: наборы API наборы объектов.
А теперь, позволю себе наглость сформулировать такую теорему:
Успех новой системы возможен только при наличии в ней нового метаперехода по сравнению со старой системой!
А вот за счет каких качеств будет осуществлен такой переход, требует дополнительного и длительного размышления…
Еще раз вернувшись к теории Турчина, вспомним, что метапереход характеризуется упрощением управления в усложнившейся системе. В некоторой степени это перекликается с идеями Стаффорда Бира об организации кибернетической системы в которой каждый предыдущий уровень служит для выделения из общего потока данных лишь ключевых параметров с целью снижения информационной нагрузки на последующий уровень. Т.е., главный стимул развития — борьба со сложностью! А метапереход — успешное решение в этой борьбе. Значит, для определения целей развития нужно выделить уровни сложности которые требуется упростить для получения нового качества разрабатываемой системы.
Исходя из этих соображений, позволю себе смелость сформулировать следующие тезисы.
Сложность ОС (ядро):
- Абстрагирование от аппаратной платформы для упрощения переноса на разное оборудование.
- Эффективное распределение и использование имеющихся ресурсов (память, время процессора и т.п.). Возможно, в условиях динамического изменения этих ресурсов.
- Организация выполнения и взаимодействия процессов. Параллельная работа на одном процессоре или распараллеливание на нескольких. Взаимодействие параллельно работающего оборудования. Распределение процессов по узлам сети.
- Организация разделяемых библиотек.
- Контроль версий используемых библиотек. Возможно, совместное использование библиотек разных версий.
- Динамическая перезагрузка работающих модулей.
- Обработка программных и аппаратных ошибок.
- Предоставление минимально необходимого набора прикладных интерфейсов, вписывающегося в единую парадигму использования (как например сделано в OS Plan 9).
Сложность языка программирования:
- Организация вычислений. Сюда входят выражения, управление потоком управления, параллельное выполнение, обработка исключений и т.д. Т.е. исключительно «счетные» аспекты работы. Так же сюда относится типизация, как средство облегчить получение более оптимизированного под платформу кода.
- Повторное использование кода, с точки зрения определения (т.е. как в программе оформляется такой код). Это функции и процедуры, модули и объекты, наследование, шаблоны, пространства имен и т.п. А так же типизация, как инструмент обеспечения согласованности интерфейсов. Т.е. все механизмы, которые позволяют вместо многократного повторения одних и тех же инструкций в разных местах программы, вынести их в одно место и записать однократно.
- Повторное использование кода, с точки зрения реализации (т.е. ран-тайм механизмы вызова такого кода). Здесь вызов процедур, передача сообщений и с другой стороны, передача данных в такой код (т.е. передача фактических параметров в процедуру или передача данных другому процессу, возможно работающему на другом узле). А так же — полиморфизм, как механизм применения единственного алгоритма к разным данным.
- Описание используемых типов и структур данных. С одной стороны — это «структурирование» памяти. А с другой — реализация эффективных механизмов доступа в идеале — единообразных, т.е. обеспечение полиморфизма работы с данными.
Сложность ОС (интерфейс пользователя):
- Модель организации хранения данных. Была одной из первых задач решаемых ОС. В первую очередь это файловые системы в перспективе движущиеся к некоему подобию СУБД.
- Совершенно не решенная в современных ОС, но на мой взгляд крайне актуальная проблема многоверсионности пользовательских данных и отслеживание истории и взаимосвязи их изменений. Например интеграция в ОС систем типа «Линия жизни».
- Механизмы взаимодействия пользователя с ОС. От командной строки до графических интерфейсов. Если рассматривать этот аспект в рамках парадигмы «Модель — вид — контроллер», то все «out-потоки» — это «вид», а все «in-потоки» — это «контроллер». В идеале ОС должна сама адаптировать программу под используемую связку «вид — контроллер», т.е. одна и та же программа может работать в текстовом терминале, на полно-размерном мониторе ПК или на дисплее смартфона.
Уф, вот так вот в первом приближении… Очень даже может быть, что я что-то упустил, но тут без взгляда со стороны трудно обойтись.
Может быть, кому-то поднятые вопросы интересны и он захочет продолжить обсуждение?
