Хотелось бы знать, как народ отнесся бы к появлению проекта по созданию Руccкой
ОС. Причём не только русской, но и всего русскоговорящего населения?
Присоеденились бы вы к такому проекту?
Ответ на
»сообщение 2418« (Lisp Hobbyist)
___________________________
Когда-то, много лет назад, когда я еще варился в тепличной академической среде, я тоже любил порассуждать о мейнстриме, который, вот ведь незадача, устроен совершенно неверно в целом и не хочет программировать "правильными" научными методами в частности.
Здесь у каждого свой опыт и своя оценка. Я лет 10 варился в академической среде, потом лет 5 в кустарном программном производстве (заказной софт, компьютерные игры), потом года 4 -- в промышленном программном производстве, в компании No.1 не только на постсоветском пространстве, но в Центральной и Восточной Европе. А там кроме мэйнстрима ничего и нет. Так что есть что и с чем сравнивать.
Раз уж мы начали навешивать друг другу ярлыки с привлечением психиатрии, предложу встречный вариант:
На кого же я тут навешиваю ярлыки? Вы мои слова принимаете на свой счет? Это исключительно Ваше восприятие. Я говорю о проблеме сложности в программировании, в мировом программировании. О проблеме избыточной сложности. О том, что это стало хронической болезнью. Что она коренится в выгодности самой сложности. И здесь далеко не оригинален.
Наверное, нам всем все же не стоит закрывать глаза на то, что сложность программного обеспечения выходит из-под контроля. Но почему теряется контроль? Давайте задумаемся. Только ли потому что сложные системы можно делать исключительно сложными инструментами? Неужели? Оставим в стороне Оберон. Лисп -- сложный инструмент? Си -- сложный инструмент? Значит, дело скорее в мозгах. В наработанных стереотипах. В том, что когда срочно нужен результат, когда нет времени обдумать, делают по накатанному. По стереотипам. А туда ли накатана дорожка? Кто ее накатывал? Какие он принимал решения, какие выбирал критерии и почему отбрасывал другие варианты?
Если эти стереотипы привели к потере контроля над сложностью, может быть, их стоит пересмотреть? Как они появились? Ведь отбрасывались важные варианты только потому, что сначала боролись за эффективность, за быструю прибыль (всё в угоду рынку). Когда мощности железа стали более чем избыточными (уже подчас не знают, чем их занять), пошли по пути не пересмотра стереотипов и возврата к тем вариантам, которые когда-то из-за нехватки мощностей отбросили, а по пути экстенсивности, наращивания мощи. Не надо думать. Железо все переварит. А то, что оно нередко работает на трухе, на прогнившем фундаменте, -- уже не заботит.
Если программист не в силах контролировать сложность своего инструмента, начиная от рабочего языка программирования с его тысячью темных закоулков, компилятора (достаточно сложной системы) с разными взбрыками и вообще всей системы программирования (еще одной сложной системы), то что говорить о результате, который доводится до кондиции преимущественно отладкой и тестированием? Эмпирикой.
Прошли те времена, когда люди сначала готовили всю документацию на сложную систему, а потом начинали ее создавать (речь, в частности, о тщательно изучаемой нами ОС MULTICS, предшественнице UNIX).
Сложность в почете. Вы регулярно взываете к Оберону. Оберон -- это просто действующая модель. Макет. С моей точки зрения, сама система Oberon -- лишь полигон идей, реализация которых выполнена весьма штрих-пунктирно. То же могу отнести и на счет BlackBox, хотя там зрелость реализации немного повыше. Но доделывать эту систему в моем понимании большого смысла не имеет (разве что чисто косметически). Надо делать свою, и строить ее основательно. Как известно, хороший инструмент сам по себе не возникнет. Он должен быть сбалансированным и практичным, а не просто набором распрекрасных возможностей на все случаи жизни.
Проверить сбалансированность и практичность с соблюдением принципа концептуальной экономии (по Хоару) можно только более объемлющим проектом, где инструмент максимально востребован. И проект новой ОС -- отличная возможность это сделать. При этом сам язык Оберон даже в своей нише (компактности и надежности) может быть переработан в сторону ужесточения требований и усиления дисциплины работы. Он, увы, не отвечает требованиям создания сложных асинхронных/параллельных систем с поддержкой взаимодействия не на уровне вызовов процедур, а на уровне языка. Значит, нужен не просто иной инструментарий, где нашли бы отражение в том числе и идеи школы Вирта (в качественно ином исполнении), но и другие языки. Опять-таки их надо не просто выдумывать, а проверять в бою. На той же новой ОС.
Простоту и сложность можно сбалансировать. Только для этого надо, как минимум, осознать, что сложность должна строиться из достаточно простых блоков, которые подчиняются реальному контролю корректности (верификации), а сами связи этих блоков, их взаимодействие также должно быть под контролем. Тогда наращивать сложность можно без потери над ней контроля.
Теперь о разрыве науки и производства.
Как показывает опыт, исследователи редко в состоянии довести свои идеи до продукта качественной реализации. Нередко они останавливаются на пол-пути, считая свою миссию завершенной. Они идеи сформулировали, показали миру, что идеи реализованы и работают. И достаточно. Что такое product management, им, как правило, неведомо.
В производстве другая проблема. Там могут довести продукт. Но на основе каких идей? Верно, тех, по которым есть минимум рисков (кадры, заказчики, сроки, ресурсы). Не последнюю роль является конъюнктурная обоснованность и модность тех или иных решений и инструментов. Экспериментальным разработкам очень редко находится место в современном программном промышленном производстве.
Какой вывод: проблему последней мили в доведении хороших идей до практики (от науки к производству) могут решить промежуточные образования. Собственно, это проблема не одной только нашей программной отрасли, просто сама отрасль потихоньку созревает до этого. Слишком еще молода.
Пока основную нагрузку на себя берут связки исследовательских подразделений компаний (крупных; мелкие редко могут себе позволить такую роскошь) с лабораториями при университетах. Но крупные компании во главу угла ставят что? Правильно: сохранение и усиление своего влияния на рынке. Что и дает необходимую прибыль. А для этого технологическое совершенство редко выстреливает. В результате ряд интересных совместных разработок (скажем, Стэнфордского университета и Альмаденского центра IBM) тихонько спускают на тормозах.
Советский Союз мог себе позволить роскошь содержать сильные научно-исследовательские институты (НИИ), работающими в связке с КБ (конструкторскими бюро), но их сила определялась конкретным заказом (космос, оборонка и др.), под который и выделялись ресурсы (и концентрировались отличные кадры). Ушло ресурсное обеспечение, снизилась востребованность, упала мотивация -- НИИ (и КБ) начали разваливаться и деградировать.
Можно ли формировать новый вид организаций (открытых центров и лабораторий, готовящих технологии и продукты), которые станут независимы в своем поиске технологического совершенства и которые в то же время в состоянии доводить программные продукты (речь о них) до высокого уровня зрелости реализации? Вполне. И речь не просто о стартапах.
Собственно, модель Open Research Programming, которуя я ранее излагал, дает необходимый фундамент для этого. Можно концентрировать интеллектуальный потенциал на направлениях решения серьезных, востребованных задач. Решать задачу последней мили (и даже вывода на рынок продуктов, минуя "заградотряды" монополистов). Результатом такой концентрации может быть не только и не столько сам конечный продукт (его бесплатность, открытость и высокое промышленное качество исполнения --– важнейшие принципы), сколько побочные вещи (кадры, технологии, другие продукты: взаимовыгодное сотрудничество с производством и наукой в решении многих "побочных" задач). Но концентрация интеллектуального потенциала должна строиться на сильной задаче (социальном и технологическом заказе) и на принципах взаимовыгодного сотрудничества всех вовлеченных в это людей, способного привнести необходимые ресурсы для ее решения. Когда финансы -- не основа мотивации, а лишь необходимое "топливо". Для "инвесторов" (речь не только о финансах) привлекательность подобных "промежуточных" организаций, связывающих науку и производство и способных выводить на орбиту качественные и серьезно проработанные вещи, достаточно высока.
Однако на всё нужно время.
Ответ на
»сообщение 2419« (Ка джа)
___________________________
Возможен ли вообще здоровый минимализм в отношении ФС? Ведь "сарай" получается немалый - структурированные документы в структурированной файловой системе... Одни механизмы... другие над первыми... или вместо первых... Кажется еще немного и в документы начнут включать не просто структуру, но и механизм, ибо в ФС не хватает подходящего механизма.
Давным-давно включают (например, макросы, соглашения о наименованиях и местах хранения файлов и бэкапов, об используемых форматах файлов и т.д.). Но только не программисты, а пользователи - потому что решаемые задачи сложные, а простенькая (даже простецкая или простоватая) файловая система ни в чем не помогает. "Здоровый" минимализм возможен в какой-то мере только по отношению к исполнимым файлам, а также к тем файлам с данными, к которым применяется только машинная обработка, например, в веб-сервисах.
Либо мы решаем проблемы пользователя... либо тот использует другую ОС (структурированные документы - уже реальность Windows, а ОС наподобие WinFS когда-нибудь тоже станет реальностью).
Мне тоже хотелось бы, чтобы "сарай" вышел поменьше, но только не за счет ограниченной функциональности, а за счет искусства архитекторов ОС.
ОС, конкурируящая с Windows, просто вынуждена иметь сопоставимый уровень сложности. Конечно, она может иметь и более изящные решения, но всё тех же сложных проблем.
Вы когда-нибудь разгребали завалы файлов, оставшиеся от уволившихся сотрудников? Задачка, похожая на расчистку авгиевых конюшен. При этом тратится много времени и остается неиспользованной масса ценной информации, а та, что используется, вызывает сомнения в актуальности. Всё потому, что неструктурированные файлы (мало напоминающие документы) лежат в анархическим образом структурированной файловой системе.
