Здравствуйте, VladD2, Вы писали:

К>>> супер, такие ОС суть светлое будущее!

Задумайтесь пожалуйста над вопросом: Что такое ФАЙЛ в объектно ориентированной операционной системе?
Файл — это персистентный объект, а файлменеджер (или файловая система) — это объектно ориентированная СУБД, в которой храняться такие персистентные объекты. Если на всю систему есть всего один единственный сборщик мусора, то пользователи этого персистентного объекта не должны сохранять его самостоятельно — это сделает за них ОО-СУБД. На сколько я знаю, в следующей версии MS Windows будет примерно такая "файловая" система. Так что такое светлое будущее, можно сказать, неотвратимо повсеместно наступит как только выйдет эта самая виндос, а пока аналоги этого есть в оберон-системах.

Здравствуйте, VladD2, Вы писали:

VD>Что такое "обычный Оберон"? И как он умудряется разделять файлы без блокировок? А так же читать их без открытия в ОС?

"обычный Оберон" — это такая операционная система Native Oberon, а не язык.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Трурль, Вы писали:

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

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

"Оберон", в данном контексте, обозначало не язык, а операционку, просто и язык и операционка носят одинаковое название.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Sergey J. A., Вы писали:

К>>>Ага, значит залочить файл в ОС Оберон мы изначально не сможем — супер, такие ОС суть светлое будущее!

SJA>>Именно это я и хотел сказать.

VD>Думаю — это был стеб.

Что именно было стёб ?
Я хотел сказать, что если

такие ОС суть светлое будущее

было сказано в виде сарказма, то я именно это и хотел сказать.

Здравствуйте, Трурль, Вы писали:

VD>>

VD>>        catch (IndexOutOfRangeException)
VD>>        { // Суда прийдем если args не содержит аргументов
VD>>            Console.WriteLine("Enter path to file, lease.");
VD>>        }
VD>>

Т>Обратите внимание на отсутствие логической связи между IndexOutOfRangeException и
Т>"если args не содержит аргументов".

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

VD>>

VD>>        catch (Exception ex)
VD>>        { // А сюда в случае любой ошибки. Так что если файла нет или еще что, 
VD>>            // то незабудем сказать об этом пользователю.
VD>>            Console.WriteLine(ex.Message);
VD>>        }
VD>>

Т>Если файла нет или еще что, то система сама скажет об этом пользователю.

Система сама ничего умного сазать к сожалению не всилах. ИИ еще не изобретен. По идее нужно было бы делать проверку количества аргументов переданных приложению и если что возбуждать исключение с осмысленным сообщением.

Однако исключения поймают и непредвиденную ошибку. Просто сообщение дудет не стольк внятным. Но система останется на плаву. А вот без исключений будет кирдык всему приложению (системе).

Здравствуйте, AndrewVK, Вы писали:

AVK>Чую курение над этой ситуацией приведет к тому что под сию замечательную ОС вместо классической ФС нужно будет подкладывать что то вроде WinFS.

Интересно как у объектов WinFS с IDisposable?

Здравствуйте, Курилка, Вы писали:

К>Каайф, однозадачность — это как раз то, что народу и надо

Скажем проще — верх прогресса. Ради этого нужно было выбросить из языка остатки разумного...

Здравствуйте, AVC, Вы писали:

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

Речь о том, что язык настолько примитивен, что вообще не имеет удобных средств контроля внешних ресуросов. Все нужно делать на морях if-ов. Т.е. как в старом добром С времен Керникана & Ричи.

С тех времен прошло 30 лет. И все языки используемые на практике давно обзавились средствами контроля ресурстов. В Шарпе, например, это конструкции:

try
{
}
catch
{
}
finally
{
}

для отлова ошибок и защиты ресурсов.
А так же:

using (ResourceHolderType var = new ResourceHolderType())
{
    // использование ресурса
} // автоматическое освобождение ресусрвов.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Задумайтесь пожалуйста над вопросом: Что такое ФАЙЛ в объектно ориентированной операционной системе?
СГ>Файл — это персистентный объект, а файлменеджер (или файловая система) — это объектно ориентированная СУБД, в которой храняться такие персистентные объекты. Если на всю систему есть всего один единственный сборщик мусора, то пользователи этого персистентного объекта не должны сохранять его самостоятельно — это сделает за них ОО-СУБД. На сколько я знаю, в следующей версии MS Windows будет примерно такая "файловая" система. Так что такое светлое будущее, можно сказать, неотвратимо повсеместно наступит как только выйдет эта самая виндос, а пока аналоги этого есть в оберон-системах.

Замечательно, раз мы заговорили о СУБД.
Не закрывать файл — это то же самое, что не завершать транзакцию. Начали, поковырялись в базе и... и пожалуй, всё (© Мексиканские Негодяи).
После какого количества таких упражнений сервер нас пошлёт? Скольких клиентов сервер пошлёт до того, как пошлёт нас?

Я уже говорил как-то, что идея сборки мусора, реализованная только на уровне примитивов ОС — однозначно, недостаточна.
Логическую уборку всё равно должен совершать разработчик: завершать транзакции, отпускать монопольно занятые физические устройства (например, ком-порт).

Здравствуйте, Сергей Губанов, Вы писали:

СГ>"Оберон", в данном контексте, обозначало не язык, а операционку, просто и язык и операционка носят одинаковое название.

Фиговое оправдание. Тут все же обсуждается язык. Более того в школы ты БлэкБокс толкаеш. Так что не нужно переключаться.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Kh_Oleg, Вы писали:

K_O>>Говоря по-русски: чтобы предотвратить разбухание кода вводится частичная специализация для того случая, когда std::vector специализируется указателем. Оптимизация, так сказать.

VD>СтлПорт рассчитан на компиляцию на самых разных компиляторах. Для VC 7+ и Intel C++ подобная фигня не нужна.
Ну прям-таки! Во-первых, эта фишка появилась только в пятой версии, которая вышла совсем недавно, во-вторых, она работает только на тех компиляторах, которые поддерживают частичную специализацию. Не многие компиляторы помимо вышеназванных умеют такое.

Ну и в-третьих. Разговор начался с разбухания кода и утверждения, что линкер может это мержить. То, что линкер умный — это хорошо. Но беда в том, что он тормозной! И под "разбуханием кода" не всегда понимается размер конечного экзешника (к счастью, прошли времена 640Kb ОЗУ), а размер объектников, которые достаются линкеру в наследство от компилятора. Из-за этого "умному" линкеру предстоит масса дурной работы, что существенно замедляет время ликновки.

А в-четвретых, не всем выпала такая удача писать только под винду. Приходится и на Иксах работать. Размер экзешников на винде и на солярке, собранных из одних и тех же исходников отличается в четыре раза! Так что, разбухание кода — не миф, далеко не миф.

Здравствуйте, Sergey J. A., Вы писали:

SJA>Да ну ? Трурль заявил, что Оберон такая система, где закрывать файлы не нужно. Затем поправился и сказал, "Я имел ввиду обычный Оберон, там файлы не блокируются". Так всё же — файлы нельзя блокировать или нельзя незакрывать ?
В Обероне нельзя блокировать, а в Блэкбоксе нельзя незакрывать заблокированные.

Прошу прощения за отсутствие: проблемы с выходом в Интернет.
Много уже «напостили», всем ответить уже вряд ли удастся, да, может быть, уже и нет необходимости.
Поэтому попытаюсь подвести итог форума, как он мне видится.
Цель, которую я себе ставил (обсудить принципы построения Оберон-систем: раздельная компиляция, отказ от понятия монолитной (stand-alone) программы, расширяемость системы, использование единого адресного пространства и «сборщика мусора», жесткий контроль типа), я выполнить не смог. Тому есть две причины: собственная слабая «подкованность» в Обероне, а также нетерпимость критиков.

Надо отметить, что критики действительно нашли несколько сомнительных мест в Обероне.
Павел Кузнецов указал, что нет возможности использовать статический контроль типа в контейнерах.
Кодт обратил внимание на отсутствие стандарта Оберона.
Это все, увы, верно.

Была и другая критика. Говорили, что нет исключений, многопоточности, нельзя блокировать файлы. Эта критика тоже важна, но менее значима, т.к. все это легко реализуется в Оберон?системе в случае необходимости, и есть такие реализации. Для этого не требуется расширения базового языка. Поэтому сейчас не буду на этом сосредотачиваться, отмечу только, что примерные способы реализации уже были приведены в издававшихся у нас книгах Вирта «Программирование на языке Модула-2» и «Алгоритмы и структуры данных».

Поэтому сейчас хочу обсудить существенную критику и пояснить, что же меня заинтересовало в Обероне.
Действительно, я не знаю в Обероне средства, аналогичного template Си++, и это «не есть хорошо». Такая же проблема была (раньше?) и в Java. (Что, впрочем, неудивительно, т.к. перенеслась она туда прямиком из Оберона.) Я даже на досуге попытался придумать такое минимальное уточнение языка, чтобы позволить компилятору отслеживать помещение в контейнеры «нежелательных» объектов. Но никто все же мне не объяснил, а что такого уж «страшного» может случиться, почему потребуется «длительная отладка»? Ведь в Обероне невозможно получить доступ к данным, несанкционированный системой контроля типов. (Попробуйте!)
Что касается отсутствия стандарта Оберона, то это просто беда какая-то с виртовскими языками… Стандарт на Паскаль был поспешным, на Модулу-2 – запоздал, а на Оберон – его и вовсе нет. И ведь что интересно, встречались разработчики компиляторов Оберона-2 еще в 1993 году, выработали «дубовые требования» (Oakwood guidelines), а где стандарт? Возможно, в языке есть какие?то не решаемые проблемы, но до этого мы на форуме не добрались, т.к. критика была настроена бескомпромиссно и выражалась, в основном, в виде вопросов, а как на Обероне сделать xxx, готовая принять только решения проблем, «изоморфные» их любимым языкам. Но если языки полностью «изоморфны», зачем их два?

Теперь о том, что меня привлекло в Обероне. Так вышло, что в последнее время мне приходится делать системы программирования для «самопальных» процессоров нашей «фирмы». И требования у меня получаются во многом противоположными критикам: компилятор должен быть как можно меньше и надежнее, отладка программ должна отнимать как можно меньше времени и сил, самое дорогостоящее – это память.
И вот я увидел, что Оберон мог быть стать хорошим решением для данного случая. Кроме того (это уже личное), Оберон (как техническое решение) очень красив.
Смотрите сами компилятор, написанный Виртом, занимал всего 45K и работал как часы.
А главное – надежность.
Ведь что самое опасное в языках вроде Си и Си++? Как раз то, что является очень красивым синтаксическим решением: адресная арифметика (т.е. то, как в Си используется указатель).
Указатель в Си может указывать не только на объект кучи, а куда угодно. Следовательно, «сборщик мусора» вряд ли удастся реализовать без «больших потрясений».
Инициализация указателя безопасным значением не гарантируется компилятором.
Указатель может указывать на элементы массива, что затрудняет контроль индексов.
Явное приведение типов указателей в Си очень распространенно и может служить источником самых непредсказуемых «глюков».
Только часть всех «глюков» может быть обнаружена операционной системой, ведь указатель может быть неправильно использован и в пределах адресного пространства процесса.
Короче, меня в Си не устраивает концепция указателя.
Вспоминается один мой знакомый программист. Он начинал программировать на Паскале и никак не мог понять, что же такое «указатель». А когда перешел на Си, то обрадовался: да ведь это просто адрес памяти, ничего больше! Как вы думаете, надо ли этому радоваться?

Что же касается сторонников языков: Java и C#, то им вообще «пинать» Оберон – грех. Ведь с начала 1994 года Sun все время консультировалась у ETH, приобрела лицензию на виртовский Оберон, упросила Франца читать лекции. Ведь многие свойства ваших любимых языков перенесены из Оберона. Как же можно после этого так злобствовать?

Здравствуйте, AVC, Вы писали:

AVC>Надо отметить, что критики действительно нашли несколько сомнительных мест в Обероне.
AVC>Павел Кузнецов указал, что нет возможности использовать статический контроль типа в контейнерах.
AVC>Кодт обратил внимание на отсутствие стандарта Оберона.
AVC>Это все, увы, верно.

AVC>Была и другая критика. Говорили, что нет исключений, многопоточности, нельзя блокировать файлы. Эта критика тоже важна, но менее значима, т.к. все это легко реализуется в Оберон?системе в случае необходимости, и есть такие реализации. Для этого не требуется расширения базового языка. Поэтому сейчас не буду на этом сосредотачиваться, отмечу только, что примерные способы реализации уже были приведены в издававшихся у нас книгах Вирта «Программирование на языке Модула-2» и «Алгоритмы и структуры данных».
Посмотрел описание Zoonon, есть там исключения, синхронизация. здесь

AVC>Что же касается сторонников языков: Java и C#, то им вообще «пинать» Оберон – грех. Ведь с начала 1994 года Sun все время консультировалась у ETH, приобрела лицензию на виртовский Оберон, упросила Франца читать лекции. Ведь многие свойства ваших любимых языков перенесены из Оберона. Как же можно после этого так злобствовать?
Если бы я встретил этот язык в 1994 году, я бы наверно ему подивился бы. Но сейчас, на примере Zoonan, мне кажется что Оберон языки в роли догоняющего. С 90-х годов появилось достаточно много более современных языков. Правда для большинство из них в 45кБ никак не уместятся. Для процессоров, с такими ограничениями, возможно и нужны такие старые языки как С, Forth или (может быть) Oberon.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Если бы я встретил этот язык в 1994 году, я бы наверно ему подивился бы.

А если бы еще в 80-х, когда он появился?

GZ>Но сейчас, на примере Zoonan, мне кажется что Оберон языки в роли догоняющего. С 90-х годов появилось достаточно много более современных языков. Правда для большинство из них в 45кБ никак не уместятся. Для процессоров, с такими ограничениями, возможно и нужны такие старые языки как С, Forth или (может быть) Oberon.

Я, в основном, с этой "кочки" (ограничения имеют значение) и смотрю.
Компилятор Оберона проще компилятора Си, а возможности и надежность значительно выше.
Что же касается Zonnon, то, по первому впечатлению, просто в язык добавили то, что раньше опционально реализовывалось в модулях Оберон-систем.
И язык сразу стал "современным", "не хуже, чем у людей".
Но, imho, для решения задач, подобных моим, "базовый" Оберон проще и перспективнее.

Здравствуйте, GlebZ, Вы писали:

GZ>Если бы я встретил этот язык в 1994 году, я бы наверно ему подивился бы. Но сейчас, на примере Zoonan, мне кажется что Оберон языки в роли догоняющего. С 90-х годов появилось достаточно много более современных языков. Правда для большинство из них в 45кБ никак не уместятся. Для процессоров, с такими ограничениями, возможно и нужны такие старые языки как С, Forth или (может быть) Oberon.

Споры между сторонниками "больших" и "маленьких" языков ведутся с давних пор. И добавление новых конструкций одни встречают с восторгом, а другие с раздражением. PL/1 одни называли "окончательным решением всех проблем", а другие "рожденственской ёлкой, на которой каждый может себе найти пряник или хлопушку".
Кстати, многим оберонщикам Zoonon решительно не нравится.

Здравствуйте, AVC, Вы писали:

AVC>Я, в основном, с этой "кочки" (ограничения имеют значение) и смотрю.
AVC>Компилятор Оберона проще компилятора Си, а возможности и надежность значительно выше.
Насчет того что проще, еще вопрос. Давным давно обсуждался вопрос, что такое С: высокоуровневый язык или очень продвинутый оптимизированный макроассемблер. Это было еще до С++. Если убрать реализацию стандартных библиотек, то простота компилятора еще вопрос. Ну а про надежность, абсолютно согласен на 200%.
AVC>Что же касается Zonnon, то, по первому впечатлению, просто в язык добавили то, что раньше опционально реализовывалось в модулях Оберон-систем.
AVC>И язык сразу стал "современным", "не хуже, чем у людей".
У меня простым просмотром описаний, тоже сложилось такое зрение. Если многим Оберонщикам не нравится Zoonan, прекрасно это понимаю. Основная причуда и идеология Oberona было конечно понятие модуля. В zoonan все эти средства расплываются и подменяются. Язык стал очень походить на остальные. Людям такой отход от идеалогии должен быть действительно обиден.
AVC>Но, imho, для решения задач, подобных моим, "базовый" Оберон проще и перспективнее.
Реализация сборки мусора при таком маленьком компайлере, по моему вещь очень продвинутая. К сожалению, после определенного момента, реализации языков перестали обращать внимание на подобную компактность. Правда, кажется, были достаточно компактные реализации Java.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

AVC>>Компилятор Оберона проще компилятора Си, а возможности и надежность значительно выше.
GZ>Насчет того что проще, еще вопрос. Давным давно обсуждался вопрос, что такое С: высокоуровневый язык или очень продвинутый оптимизированный макроассемблер. Это было еще до С++. Если убрать реализацию стандартных библиотек, то простота компилятора еще вопрос. Ну а про надежность, абсолютно согласен на 200%.

Сейчас я в целом согласен с Виртом: Си не является высокоуровневым языком (по-моему, Си на это и не претендовал).
Я допускаю, что во многом моя точка зрения определяется весьма специфическими потребностями (делать надежные автономные программные системы минимальными силами). Здесь Оберон, imho, не оставляет Си никаких шансов. Сейчас, как только кончится "запарка" с тестированием процессора, я собираюсь представить по этому поводу доклад нашему руководству, с рассмотрением плюсов и минусов разных подходов. С разработчиками процессора я уже разговаривал. Они проявили значительный интерес к принципам Оберона.
Что же касается библиотек, то ведь опять же реализовывать их приходится мне самому, что только увеличивает объем моей работы. В случае же с Обероном мы сможем наращивать систему коллективными усилиями (программируя уже на самом Обероне), вводя новые модули по мере необходимости.
Ну и, само собой, — надежность!

GZ>У меня простым просмотром описаний, тоже сложилось такое зрение. Если многим Оберонщикам не нравится Zoonan, прекрасно это понимаю. Основная причуда и идеология Oberona было конечно понятие модуля. В zoonan все эти средства расплываются и подменяются. Язык стал очень походить на остальные. Людям такой отход от идеологии должен быть действительно обиден.

Лично мне нравится Оберон-2, как он сформулирован авторами языка — Виртом и Мессенбоком (кстати, второй из них создал Coco/R; вопреки некоторым утверждениям, на C# его просто заимствовали), а также стандартом de facto Оберона-2 — Oakwood guidelines.
Оберон-2 изучить очень легко. (Я без всяких проблем написал несколько программ, пока еще учебных. Причем некоторые — в первый же день знакомства с Обероном.)
Компилятор Оберона-2 можно создать в одиночку. А компилятор Zonnan?

GZ>Реализация сборки мусора при таком маленьком компайлере, по моему вещь очень продвинутая. К сожалению, после определенного момента, реализации языков перестали обращать внимание на подобную компактность.

И это жаль!
Я не против существования "больших" языков, но обязательно должны быть и альтернативные "маленькие" языки.

Здравствуйте, GlebZ, Вы писали:

GZ>Посмотрел описание Zoonon, есть там исключения, синхронизация. здесь

1) Как только его не обзывали Zoonon, Zoonan..., а правильно Zonnon.
2) Официальная страница у него вот такая: http://www.zonnon.ethz.ch/ (а не блюботлевая)
3) Разработка Zonnon осуществляется на деньги Microsoft, а, как известно, кто платит, тот и заказывает музыку. От оригинального оберона, в Zonnon разьве только правильный (единственно верный) синтаксис и остался. На сколько лично я понял, нигде кроме как под .NET этого Zonnon больше не будет (впрочем это же справедливо и для C#).

AVC,

> как только кончится "запарка" с тестированием процессора, я собираюсь представить по этому поводу доклад нашему руководству, с рассмотрением плюсов и минусов разных подходов.

Было бы очень интересно подобный доклад почитать.