Ответ на »сообщение 2500« (Сергей Прохоренко)
___________________________


А для системных программистов, как и для офисных работников, нужна версионность, бэкапы, синхронизация, поиск по атрибутам, упорядоченность по проектам, авторство, безопасное переименование, связывание с другими документами (тот же импорт модулей в оберонах) и т.п., что свойственно документу, а не файлу.

Ячейки машинной памяти могут адресоваться напрямую (адресами и указателями), а могут опосредованно (ссылками с контролем сборщика мусора). Таким образом, есть низкоуровневые указатели (нетрассируемые, бесконтрольные) и высокоуровневые (трассируемые, под контролем).

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

Ряд языков стимулирует к работе и с теми, и с другими (Modula-3). Есть такие, которые допускают работу только с низкоуровневым представлением (Си). Есть такие, которые работают только с высокоуровневым (Оберон).

Думаю, аналогия указателей (адресов) и ссылок -- с файлами и документами здесь понятна. Делать можно и так, и эдак.

Файл -- столь же фундаментальное понятие, как адресуемая ячейка памяти. Если делать систему прозрачной для программистов, то надо давать доступ к низкоуровневому представлению. Доступ этот может обеспечиваться как в специальных резервациях ("саркофагах"), так и путем  явного отключения контроля с предъявлением мандата (когда позарез потребовалось залезть на нижний уровень). Система должна быть устойчивой к дураку (который, увы, встречается и среди сисадминов), но допускать возможность разобрать себя до винтика. Только в отношении этой возможности требуется выстроить грамотный заслон ("опломбировать"). Кто решит отключить штатный режим (автопилота) и перейти на аварийный (ручное управление), должен отдавать себе в этом отчет и иметь необходимые полномочия. Более того, его действия все равно будут (по возможности, разумеется) идти под контролем.

Судя по оживлённости дискуссии по вопросам электронного документооборота, пора заводить отдельную Interest group  по ЭД внутри проекта "Роса" :)

Ответ на »сообщение 2498« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2496« (Сергей Перовский)
___________________________

Как файловая система скрыла от пользователя сектора, кластеры и т.д., так пора скрыть от пользователя файловую систему.

О каком пользователи мы говорим? Системный программист, прикладной программист -- то же пользователи ОС. Для какой роли что открывать (какие уровни абстракции, какие сущности ОС и их атрибуты) -- непростой вопрос.

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

Думаю, очевидно, что для ряда задач (прежде всего, программистам) нужно будет работать напрямую с сущностью под именем "файл" (поименованной последовательности байтов). Так какова здесь Ваша точка зрения?

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

А для системных программистов, как и для офисных работников, нужна версионность, бэкапы, синхронизация, поиск по атрибутам, упорядоченность по проектам, авторство, безопасное переименование, связывание с другими документами (тот же импорт модулей в оберонах) и т.п., что свойственно документу, а не файлу.

Ответ на »сообщение 2497« (Руслан Богатырев)
___________________________


Если Вы считаете, что в отношении инструментария для новых языков мы будем делать так же по-спартански, как в BlackBox, то попробую разуверить -- будет не так.


Признаю'. Была такая мысль: группа аскетичных ортодоксов BlackBox'а слепит что-нибудь, чтоб только работало, а потом всем придется бриться их топором. Они всех будут убеждать, что их топор самый удобный. Тогда приложений к ОС точно не видать. Хорошо, что ошибся.

Ответ на »сообщение 2496« (Сергей Перовский)
___________________________

Как файловая система скрыла от пользователя сектора, кластеры и т.д., так пора скрыть от пользователя файловую систему.

О каком пользователи мы говорим? Системный программист, прикладной программист -- то же пользователи ОС. Для какой роли что открывать (какие уровни абстракции, какие сущности ОС и их атрибуты) -- непростой вопрос.

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

Думаю, очевидно, что для ряда задач (прежде всего, программистам) нужно будет работать напрямую с сущностью под именем "файл" (поименованной последовательности байтов). Так какова здесь Ваша точка зрения?

Ответ на »сообщение 2495« (Сергей Прохоренко)
___________________________

Разве любимые вами микроскопические языки достигли впечатляющей популярности или еще каких-нибудь реальных успехов (за исключением JavaScript, любимого школьниками-вирусописателями за простоту освоения)?

Достигли. Скажу только об одном. Это язык Си.

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

Возможно. Кто из нас не заблуждался? :)

Если бы Вы в действительности программировали на PL/I, то Вы бы так о нем не отзывались.

Было дело. Программировал. Но немного и только для изучения возможностей. На PL/I создавалась MULTICS, которая меня весьма и весьма интересует. Так что упреки не по адресу. А насчет моделей: "все впихнуть в один" -- "разнести по нескольким". На то они и модели. Каждая по своему полезна. Нет идеала. Но если первый путь ("мультипарадигматичности" языка, насыщения его до предела) является доминирующим в развитии языков, то второй путь -- ортогональных групп мало изучен. Потому и интересен.

Вы же не возражаете, например, на сочетание низкоуровневых и высокоуровневых средств в языке, позволяющее отказаться от использования ассемблера?

Возражаю.

Про кашу и отсутствие контроля компилятора - это на Вашей совести и на совести потенциальных криворуких разработчиков языка.

Разумеется, на моей совести, как, впрочем и все остальные мои высказывания. Если язык достаточно объемный (масштаба ISO C++), если он вбирает в себя средства нескольких парадигм, втискивая их в рамки одного своего синтаксиса (что уже само по себе насилие -- синтаксис и семантика взаимосвязаны), то в итоге разработчики будут использовать свои рабочие подмножества такого языка. Эти подмножества они держат обычно в голове. Сколько разработчиков, столько и неформальных подмножеств. С течением времени эти подмножества еще и меняют свои очертания. О каком контроле выхода за рабочее подмножество (микроязык) можно говорить? Все остается на совести программиста. Это тоже подход. По нему индустрия и топает. Ну так и в чем проблемы? Пусть себе топает дальше на здоровье.

Вторую часть сообщения и ссылку, Вы, похоже, не читали, так как были обижены за "красивую" схему ортогональных языков. А зря.

Не обижаюсь. На что? Скажу больше -- стараюсь из любой, даже самой казалось бы никчемной реплики извлечь рациональное зерно. Ваше сообщение (если Вы так хотите обратить на него мое внимание) -- читал. Свое мнение по поводу перекоса в сторону средств разработки уже не раз высказывал -- это не законы (в отличие от языка), а плавающая их трактовка. У них нет четкой спецификации. Это скорее эргономика. Можно сделать много красивого и удобного (как в случае ряда систем для Java и C#), только проблемы языка при этом останутся. Просто скроются под толщей замечательных кнопочек и диаграмм.

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

Ответ на »сообщение 2467« (Ка джа)
___________________________
Потому что, скажем, над большим юридическим документом вероятно работают целые группы параллельно.
На толстых научных книгах можно прочесть: "под общей редакцией ...".
Для всей книги автор известен, хотя состоит она из ссылок на тексты, написанные другими людьми. Механизм составных документов снимает эту проблему.

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

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

Ответ на »сообщение 2490« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2488« (Сергей Прохоренко)
___________________________

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

Подобная прямолинейность (если не сказать наивность) и привела к рождению на свет Алгол-68, PL/I, C++. Не стоит наступать на грабли тех "алхимиков", которые столько лет безуспешно искали "философский камень".

Вкратце изложил свой взгляд в заметке: "RB27. Пути восхождения к новой ОС" -- http://rbogatyrev.livejournal.com/2007/08/31/

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


Откуда такой поучающий тон мудреца, никогда не совершающего ошибок? Разве любимые вами микроскопические языки достигли впечатляющей популярности или еще каких-нибудь реальных успехов (за исключением JavaScript, любимого школьниками-вирусописателями за простоту освоения)?

Вы просто катитесь в русле общепринятых заблуждений, созданных недобросовестной конкуренцией. Если бы Вы в действительности программировали на PL/I, то Вы бы так о нем не отзывались. Кстати, я не заметил в PL/I вкраплений функциональной или скриптовой парадигмы. И почитателей у него гораздо больше, чем у всех оберонов, хаскелей и питонов вместе взятых (обероны мне тоже нравятся, но однобокость в них сильно чувствуется).

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

Про кашу и отсутствие контроля компилятора - это на Вашей совести и на совести потенциальных криворуких разработчиков языка.

Вторую часть сообщения и ссылку, Вы, похоже, не читали, так как были обижены за "красивую" схему ортогональных языков. А зря.

Ответ на »сообщение 2492« (Сергей Перовский)
___________________________

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

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

Хотел бы обратить особое внимание на следующий момент. Мы планируем, что новая ОС будет со всеми исходными текстами, в общественном достоянии (public domain) и бесплатной. Но при этом подразумеваем наличии коммерческих разработок для этой ОС.

Это еще одна из причин, почему проект ведется столь открыто: мы проводим публичные консультации через форумы с теми, кто в будущем может стать не только пользователем, но и разработчиком (прежде всего, прикладных систем). Поэтому готовы создавать полезные подъездные пути с учетом требований/пожеланий для будущих разработок.

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

Другими словами -- СЭД и связанные с ним вопросы нам интересны. И мы готовы тщательно проработать фундамент ОС для грамотного решения и этих задач.

Ответ на »сообщение 2491« (12)
___________________________

Что касается экспериментов (работ) над Norebo, то прежде обсуждать отдельные средства языка хотелось бы иметь о нем общее представление. Будет ли для этого достаточно сообщения на evroprog.ru?

На EuroProg не будет обратной связи. Это просто место публикации более-менее дозревших материалов. С учетом важности нового языка (а также схемы привилегированных языков) мы откроем соответствующий форум на OberonCore. Многие вещи уже обсуждались разными участниками последние два года на нескольких ветках по Оберону здесь, в Королевстве Delphi. Но там были очень дальние подступы к реальным идеям.

В двух словах, язык объединит в себе отточенное ядро (на базе классического Оберона) и надстройку для решения задач программной инженерии (архитектурного толка). Как только проф. Вирт опубликует уточненный вариант классического Оберона в нынешней трактовке 2007 г. (Оберон-07), мы сможем сказать что-то более конкретно. В частности, представить разбор Оберон-07 сквозь призму нашего проекта. Эта работа планируется.