Главная » 2016 » Июнь » 20 » RB27. Пути восхождения к новой ОС
13:15
RB27. Пути восхождения к новой ОС
В ходе публичных и внутренних обсуждений не раз поднимались едва ли не центральные вопросы проекта: (1) Что из себя будет представлять новая ОС? и (2) Как мы будем решать эту задачу? Пытаться брать такую высоту, как новая ОС, штурмом с одного базового лагеря — наверное, не совсем правильно. А потому стоит искать разные точки начала восхождения, разные маршруты, разные аспекты, стараясь понять, как должна выглядеть в итоге новая ОС (внутри и снаружи), чтобы не оказаться просто технологически красивой игрушкой для развлечения публики. Сначала неплохо бы для себя решить вопрос: новая ОС — это действительно нечто новое или же переделка известных систем на новый лад? Вопрос простой и сложный одновременно. Для меня ответ очевидный, не раз его озвучивал — новое, иначе проект теряет смысл. Не переделка UNIX и не переделка Оберона (BlackBox, Bluebottle или чего еще). Нужно ли для этого нового сохранять возможность использования старых средств и наработок? — Почему нет? Надо знать цену вопроса. С другой стороны, революция — вещь, конечно, замечательная. Но три кита — ОС, язык программирования и СУБД — никто не отменял. Не думаю, что мы будем покушаться на эти фундаментальные вещи. Покушаться на их устройство? Вполне. На их взаимосвязь? Почему нет? Если есть фундаментальные вещи, неплохо бы понимать их нынешние пределы возможностей. Они выявляются по отношению к предметным областям и задачам, которые там стоят (в перспективе хотя бы на 5-7 лет) с учётом тенденций развития железа (что есть ограничение, которым трудно пренебречь). Значит, надо очертить предметные/проблемные области (а не одну область), куда бы хотели нацелить ОС в первую очередь (и во вторую, и в третью). Детально разобрать железо, которое там может применяться. Подумать над подходами новой ОС для этих задач. Собственно требования к ОС исходят из необходимости решения выявленных задач. При размышлении на тему, что из себя должна представлять будущая ОС, неплохо бы отталкиваться от того конкурентного преимущества, которое мы имеем перед другими группами. А не просто искать ниши, куда можно будет "e;приткнуться"e;. Наше конкурентное преимущество — во владении технологиями виртовской школы программирования (20 с лишним лет опыта только в этой области), понимании их недостатков, знании того, как они могут быть переработаны и использованы для достижения технологического совершенства в вопросах построения сложных программных систем. А операционная система — это как раз-таки сложная программная система, при построении которой не только можно, но и нужно использовать наше конкурентное преимущество. Виртовское направление вобрало в себя и творческое переосмысление ряда американских исследований, к которым сами американцы только теперь начинают обращаться и всерьёз изучать (как в случае Singularity и Cedar). Важно понимать, что в нашем проекте весьма велика роль языков программирования и их связки с ОС. Понимать, что контроль сложности можно обеспечить совокупностью средств и решений, среди которых языковой контроль, формальные модели и системная архитектура играют центральную роль. Если нивелируется это преимущество (языков и формальных методов), у нас останется только архитектура. Вряд на этом поле (даже с учётом глубокого изучения новых, а также пылящихся в архивах позабытых-позаброшенных идей) мы сможем иметь решающее преимущество. Нередко можно слышать, что простые языки и системы (как язык Оберон и система Oberon) – это не более чем академическая забава, что ИТ-индустрии (а заодно и науке с образованием) нужны мощные, современные и, разумеется, сложные вещи. Это один из ключевых вопросов, имеющих отношение к нашему проекту, поэтому остановлюсь на нём подробнее. Программисты в большинстве своём любят всё усложнять. Ведь как замечательно чувствовать себя интеллектуалом, разбирающимся в таких дебрях и нюансах, в которых простому смертному ничегошеньки не понять. Да и коллегам тоже. Это возвышает. Это проникает в сознание. Это стимулирует искать сложность там, где её и в помине нет. Сделать сначала одну полезную, но обязательно непростую вещь. Потом упереться в границы её возможностей и для устранения всплывших проблем сделать новую... потом опять то же самое, но на новом витке эволюции. Зачем пытаться обобщить, отрезать лишнее, выявить ядро? Когда? Во имя чего? Это нудно, тяжело, не возвышает над другими. И, главное, снимает зависимость других от тебя. Т.е. лишает тебя дивидендов. Сегодня и завтра. Паранойя сложности — как наркотик. Который точно нащупала ИТ-индустрия и ловко этим пользуется. Ей это позволяет не останавливать производство всё новых и новых "e;пилюль"e; для массового потребления (что пользователей, что разработчиков, что проектировщиков), постоянно извлекать прибыль, ставить в зависимость от себя. И всем хорошо. А мы говорим — простота... Пожалуй, в современном программировании, как нигде ещё, справедлива поговорка "e;простота хуже воровства"e;. В книге "e;Язык и ментальность"e; профессор В.В.Колесов (зав.кафедрой русского языка Санкт-Петербургского государственного университета) пишет по этому поводу: "e;Простой — по смыслу слова "e;открытый"e; навстречу всем влияниям и зависимый от обстоятельств жизни... Как толкует слово Владимир Даль, простой — "e;ничем не занятый, сам по себе, не сложный по натуре, но слишком прямой, чтобы сгибаться перед всяким"e;. Простые языки не сгибаются и – получают по полной программе. Чему удивляться, что простые вещи (Лисп, Форт, Пролог, Smalltalk, Оберон и др.) попирают ногами? Даже Си не миновала сия незавидная участь. Удивляться не стоит. Такова жизнь. Да, я говорю о проблеме сложности в программировании, в мировом программировании. О проблеме избыточной сложности. О том, что это стало хронической болезнью. Что она коренится в выгодности самой сложности. И здесь далеко не оригинален. Дейкстра, Хоар, Вирт столько раз об этом твердили миру, что вроде бы давно все это знают. Знают, но делают иначе. Наверное, нам всем всё же не стоит закрывать глаза на то, что сложность программного обеспечения выходит из-под контроля. Но почему теряется контроль? Давайте задумаемся. Только ли потому что сложные системы можно делать исключительно сложными инструментами? Неужели? Оставим в стороне Оберон. Лисп — сложный инструмент? Си — сложный инструмент? Значит, дело скорее в мозгах. В наработанных стереотипах. В том, что когда срочно нужен результат, когда нет времени обдумать, делают по накатанному. По стереотипам. А туда ли накатана дорожка? Кто её накатывал? Какие он принимал решения, какие выбирал критерии и почему отбрасывал другие варианты? Если эти стереотипы привели к потере контроля над сложностью, может быть, их стоит пересмотреть? Как они появились? Ведь отбрасывались важные варианты только потому, что сначала боролись за эффективность, за быструю прибыль (всё в угоду рынку). Когда мощности железа стали более чем избыточными (уже подчас не знают, чем их занять), пошли по пути не пересмотра стереотипов и возврата к тем вариантам, которые когда-то из-за нехватки мощностей отбросили, а по пути экстенсивности, наращивания мускулов. Не надо думать. Железо всё переварит. А то, что оно нередко работает на трухе, на прогнившем фундаменте, — уже не особо и заботит. Если программист не в силах контролировать сложность своего инструмента, начиная от рабочего языка программирования с его тысячью тёмных закоулков, компилятора (достаточно сложной системы) с разными "e;закидонами"e; и вообще всей системы программирования (ещё одной сложной системы), то что говорить о результате, который доводится до кондиции преимущественно отладкой и тестированием? То бишь эмпирикой. Прошли те времена, когда люди сначала готовили всю документацию на сложную систему, а потом начинали её создавать (речь, в частности, о тщательно изучаемой нами ОС MULTICS, предшественнице UNIX). Сложность нынче в почёте. Простота — в забвении. Но простота простоте рознь. Есть простота полена. А есть простота формулы Эйнштейна. К простоте второго рода ещё надо прийти. Потом её осознать, понять, как через неё раскрывается сложность. Простота и сложность – не взаимоисключающие вещи. Их можно сбалансировать. Только для этого надо, как минимум, осознать, что сложность должна строиться из достаточно простых блоков, которые подчиняются реальному контролю корректности (верификации), а сами связи этих блоков, их взаимодействие также должно быть под контролем. Тогда наращивать сложность можно без потери над ней контроля. О роли языков программирования. Достаточно распространена та точка зрения, что язык и инструментарий вторичны. Об этом говорят системные архитекторы, бизнес-аналитики, да и сами программисты, попавшие в атмосферу корпоративной среды. Они ставят во главу угла другие факторы: качество анализа предметной области, организацию взаимодействия внутри коллектива и т.д. По своему опыту работы (исследователя, программиста, бизнес-аналитика, менеджера крупных проектов) могу сказать, что организационные вопросы, дисциплина производства, аналитика, — вещи нужные. От качественно выстроенного процесса во многом зависит результат и нивелируются проблемы исполнителей и используемых ими инструментов. Но... многое, если не всё, решают как раз-таки люди и применяемые ими инструменты. Язык программирования — один из таких инструментов. Не самый последний по значимости, поскольку, как и в случае естественного языка, люди мыслят на близком им (родном) языке. Мыслят в его понятиях, переводя это в уме на другие языки. Стараются свести незнакомые вещи к понятным и привычным схемам (стереотипам). Сколькими бы языками программирования человек ни владел, у него есть один, любимый, привычный. Это не значит, что его роль с течением времени не займёт другой, но всё равно будет один эталон, по отношению к которому программист и станет всё выстраивать. Мне встречались программисты, которые могли с относительной легкостью переключать "e;контексты"e;, меняя базис привычного (эталонного для них) языка. Но это редкость, исключение, нежели норма. Проф. Вирт неоднократно подчёркивал, что воспринимает язык программирования исключительно как символику (нотацию), удобную для изложения мыслей в программировании. По всей видимости, проводя аналогии с символикой математики. И он недоумевает по поводу сильной привязанности программистов к языку. Должен признаться, что подобное восприятие, на мой взгляд, несколько идеалистично. И является такой же крайностью, как и другой полюс — возведение языка программирования в символ веры. Языки программирования стали в самом деле близки к религиозным течениям. Вокруг них формируются свои проповедники, свои последователи учения, свои верующие, свои прихожане, своя паства. Это особые культурные образования. Язык стал основой деления на субкультуры. Он ведёт к размежеванию. И это деструктивно. На мой взгляд, истина, как обычно лежит где-то посредине: язык важен для мышления, но он не должен возводиться в абсолют, а для этого необходимо создавать сбалансированные, устойчивые языковые образования (группы языков), которые позволяют уйти от привязки к конкретному языку (на чей аршин человек привык все мерить). Языковые образования будут устойчивы в том случае, если входящие в них языки близки к ортогональности (дополняют друг друга своими концепциями и средствами, лежат в разных понятийных плоскостях). Кроме того, должны быть созданы условия для комфортной работы в этих языках — их реализации (системы программирования) должны обеспечивать такой режим работы (совмещения разнородных по языкам программных блоков в одной системе). Иными словами, не идти по пути наращивания мощи языков, пытаясь в один язык впихнуть всё, что только можно, не идти по пути низкоуровневого взаимодействия реализаций языков (соглашения компиляторов, передача параметров и т.п.), не идти по пути "e;прокрустова ложа"e; — сведения всего к единой системе типов (классов), как в .NET, а формировать небольшие островки — языковые группы. Тогда базис будут формировать ортогональные языки, каждый из которых в своих границах хорошо продуман и сбалансирован. Хорошо продумана и сбалансирована сама группа, а также её реализация. Собственно эти мысли навели на идею т.н. привилегированных языков в проекте "e;Роса"e;. Кое-что из контуров изложено в заметке "e;RB23. О языках реализации в проекте новой ОС"e;. Поскольку речь идёт и о создании в рамках проекта нового языка (языков), опирающегося на принципы Оберона, но отличного от него, дадим новому языку некое название. В шутку и для определённости можно назвать Norebo (Oberon наоборот). В дополнение к Norebo устойчивую языковую группу могут образовать язык функционального программирования (пока здесь главный кандидат Haskell), а также сценарный язык (здесь основной кандидат Python). "e;Подтягивание"e; известных языков к новому, который будет центральным в реализации системы, — очень важный момент. Он не только позволит уйти от технологического изоляционизма, но и предложит качественную иную форму "e;гетерогенного"e; программирования, которую может эффективно применять не только коллектив, но и индивидуальные программисты. Инструмент должен в достаточной мере соответствовать задаче (её решению), и программист должен иметь выбор вариантов решения на разных (взаимодополняющих, ортогональных) языках, которые для него должны быть не посторонними. В этой схеме наверняка сохранится у программиста один, привычный, любимый язык (человек консервативен по своей природе), но при этом он будет иметь возможность оперировать дополнительными инструментами, которые лежат в плоскостях иных парадигм (подходов) программирования, с иными понятийными акцентами. Oberon — это просто действующая модель. Макет. С моей точки зрения, сама система Oberon — лишь полигон идей, реализация которых выполнена весьма штрих-пунктирно. То же могу отнести и на счет BlackBox, хотя там зрелость реализации немного повыше. Но доделывать эту систему в моём понимании большого смысла не имеет (разве что чисто косметически). Надо делать свою, и строить её основательно. Как известно, хороший инструмент сам по себе не возникнет. Он должен быть сбалансированным и практичным, а не просто набором распрекрасных возможностей на все случаи жизни. Проверить сбалансированность и практичность с соблюдением принципа концептуальной экономии (по Хоару) можно только более объемлющим проектом, где инструмент максимально востребован. И проект новой ОС — отличная возможность это сделать. При этом сам язык Оберон даже в своей нише (компактности и надёжности) может быть переработан в сторону ужесточения требований и усиления дисциплины работы. Он, увы, не отвечает требованиям создания сложных асинхронных/параллельных систем с поддержкой взаимодействия не на уровне вызовов процедур, а на уровне языка. Значит, нужен не просто иной инструментарий, где нашли бы отражение в том числе и идеи школы Вирта (в качественно ином исполнении), но и другие языки. Опять-таки их надо не просто выдумывать, а проверять в бою. На той же новой ОС. Теперь о разрыве науки и производства. И это тоже имеет непосредственное отношение к теме заметки – путям восхождения к новой ОС. Как показывает опыт, исследователи редко в состоянии довести свои идеи до продукта качественной реализации. Нередко они останавливаются на пол-пути, считая свою миссию завершённой. Они идеи сформулировали, показали миру, что идеи реализованы и работают. И достаточно. Что такое product management, им, как правило, неведомо. В производстве другая проблема. Там могут довести продукт. Но на основе каких идей? Верно, тех, по которым есть минимум рисков (кадры, заказчики, сроки, ресурсы). Не последнюю роль играет конъюнктурная обоснованность и модность тех или иных решений и инструментов. Экспериментальным разработкам очень редко находится место в современном программном промышленном производстве. Слишком велики риски. Какой вывод? Проблему последней мили в доведении хороших идей до практики (от науки к производству) могут решить промежуточные образования. Собственно, это проблема не одной только нашей программной отрасли, просто сама отрасль потихоньку созревает до этого. Слишком ещё молода. Пока основную нагрузку на себя берут связки исследовательских подразделений компаний (крупных; мелкие редко могут себе позволить такую роскошь) с лабораториями при университетах. Но крупные компании во главу угла ставят что? Правильно: сохранение и усиление своего влияния на рынке. Что и даёт необходимую прибыль. А для этого технологическое совершенство не только не полезно, а даже вредно, ибо может подорвать завоёванные позиции. В результате ряд интересных совместных разработок (скажем, Стэнфордского университета и Альмаденского центра IBM) тихонько спускают на тормозах. Как тут не вспомнить и компанию Borland, которая похоронила в своих недрах Turbo Modula-2 лишь бы она не подорвала рыночные позиции Turbo Pascal. Это привело к скандальному уходу из Borland соучредителя и вице-президента Нильса Йенсена вместе с возглавляемой им группой. В конечном итоге технологическое совершенство пало жертвой амбиций и финансовых интересов. Советский Союз мог себе позволить роскошь содержать сильные научно-исследовательские институты (НИИ), работающие в связке с КБ (конструкторскими бюро), но их сила определялась конкретным заказом (космос, оборонка и др.), под который и выделялись ресурсы (и концентрировались отличные кадры). Ушло ресурсное обеспечение, снизилась востребованность, упала мотивация — НИИ и КБ начали разваливаться и деградировать. Можно ли формировать новый вид организаций (открытых центров и лабораторий, готовящих технологии и продукты), которые станут независимы в своем поиске технологического совершенства и которые в то же время в состоянии доводить программные продукты до высокого уровня зрелости реализации? Вполне. И речь не просто о стартапах. Собственно, модель Open Research Programming, которуя я ранее излагал, даёт необходимый фундамент для этого. Можно относительно быстро концентрировать интеллектуальный потенциал на направлениях решения серьёзных, востребованных задач. Решать задачу последней мили (и даже вывода на рынок продуктов, минуя "e;заградотряды"e; монополистов). Результатом такой концентрации может быть не только и не столько сам базовый конечный продукт (его бесплатность, открытость и высокое промышленное качество исполнения — важнейшие принципы), сколько побочные вещи (кадры, технологии, другие продукты: взаимовыгодное сотрудничество с производством и наукой в решении многих побочных задач). Но концентрация интеллектуального потенциала должна строиться на сильной задаче (социальном и технологическом заказе) и на принципах взаимовыгодного сотрудничества всех вовлечённых в это людей, способного привнести необходимые ресурсы для её решения. Когда финансы — не основа мотивации, а лишь необходимое топливо. Для "e;инвесторов"e; (речь не только о финансах) привлекательность подобных промежуточных организаций, связывающих науку и производство и способных выводить на орбиту качественные и серьёзно проработанные вещи, достаточно высока. Однако на всё нужно время.
Просмотров: 24 | Добавил: AdnrNick | Рейтинг: 0.0/0
Всего комментариев: 0
avatar