Ответ на »сообщение 2400« (Lisp Hobbyist)
___________________________


Никто не задумывался, почему такой простой и аккуратный язык почему-то практически не вышел за пределы университетов, а громадный и эклектичный Common Lisp используется в реальных сложных (хотя и немногочисленных) проектах? Лично мне все это сильно напоминает происходящее с Обероном. Я понимаю, что на чужих ошибках учиться сложно, но советую все же попробовать.

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

Зачем пытаться обобщить, отрезать лишнее, выявить ядро? Это нудно, тяжело, не возвышает над другими. И, главное, снимает зависимость других от тебя. Т.е. лишает тебя дивидендов. Сегодня и завтра.

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

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

А Вы говорите -- простота... Пожалуй, в современном программировании, как нигде еще, справедлива поговорка "простота хуже воровства".

В книге "Язык и ментальность" профессор В.В.Колесов (зав.кафедрой русского языка Санкт-Петербургского государственного университета) пишет по этому поводу: "Простой -- по смыслу слова "открытый" навстречу всем влияниям и зависимый от обстоятельств жизни... Как толкует слово  Владимир Даль, простой -- "ничем не занятый, сам по себе, не сложный по натуре, но слишком прямой, чтобы сгибаться перед всяким".

Так чему удивляться, что простые вещи (Лисп, Форт, Пролог, Smalltalk, Оберон и др.) попирают ногами? Удивляться не стоит. Такова жизнь.

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

Как я уже говорил (»сообщение 2188«, »сообщение 1966«, »сообщение 1689«), предполагается в дополнение к публичным форумам общего характера (как форум "Русская ОС" в Королевстве Delphi) открыть специализированные форумы, где можно будет напрямую с участниками проекта и другими заинтересованными лицами предметно обсуждать конкретные вопросы.

А можно сделать не иерархию, темы, подтемы..., а теги?

Стоит ли городить иерархию, в угоду кажущейся простоте выборки по разделу, если разделы еще будут сильно пересекаться? Кажется сейчас объемы текста позволяют просматривать его весь...

на »сообщение 2380«  (Руслан Богатырев)
Ответ на »сообщение 2378« (Ка джа)
___________________________

?Вопрос к мэтрам - существует ли более эффективная и гибкая модель?
Я имел ввиду и модель организации информации (файловая система, например). То, чем оперировать, а не только то, как отображать и "шевелить"... Вероятно существуют ФС неиерархического (девайс\каталог\подкаталог\файл) типа? Вообще... "Файл" - это вне сомнений?

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

Можно пофантазировать, если есть желание. Если не трогать 3D, в ОС можно таких столов (поверхностей) иметь немало и мешать засорять основную. Вытеснение на другие может осуществляться разными критериями фильтрации (по времени размещения и/или использования; по функциональному назначению; по ролевому назначению и т.д.). Манипулирование доступа к рабочим столам можно сделать достаточно простым и наглядным.
Не встречал такого удобства (знаком с вин, мак, линукс/включая упомянутые здесь)
Может кто подскажет? Хотя бы в теории.

Ответ на »сообщение 2395« (Илья Ермаков)
___________________________

Заявлялось нечто иное:
"Нужно стремиться делать такие формальные системы (в частности, ЯП), которые поддаются такому же краткому и ёмкому описанию, как Оберон Н. Вирта".

Дело-то в том, что пока что я так и не увидел "краткого и емкого описания Оберона". :-) То, что нам предъявляют в качестве такого описания (Oberon Report и даже Oberon Report + Oakwood guidelines) на деле содержит достаточно большие упущения (одну из причин, по которой я так считаю, я уже не раз упоминал, остальные пока в резерве для будущих флеймов :-). Для личного использования сойдет, не спорю, а вот как базис, на котором будут пытаться построить вокруг языка инфраструктуру промышленного масштаба --- вызовет серьезные проблемы.

А если такого описания нет, к чему стремиться-то?

Кстати, раз уж в этой дискуссии упомянули Scheme... Никто не задумывался, почему такой простой и аккуратный язык почему-то практически не вышел за пределы университетов, а громадный и эклектичный Common Lisp используется в реальных сложных (хотя и немногочисленных) проектах? Лично мне все это сильно напоминает происходящее с Обероном. Я понимаю, что на чужих ошибках учиться сложно, но советую все же попробовать.

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

Я предлагаю эти бессмысленные нападки на несчастные 16 страниц прекратить.

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

Прекратить? Да пожалуйста, хоть сразу после этого сообщения, раз уж это настолько кого-то ранит.

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

А штурманы должны вести прокладку по пачке "Беломора". :-)

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

Некоторые пояснения к »сообщение 2398«.

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

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

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

Организация тематических форумов по новой ОС "Роса"

Как я уже говорил (»сообщение 2188«, »сообщение 1966«, »сообщение 1689«), предполагается в дополнение к публичным форумам общего характера (как форум "Русская ОС" в Королевстве Delphi) открыть специализированные форумы, где можно будет напрямую с участниками проекта и другими заинтересованными лицами предметно обсуждать конкретные вопросы.

Для этого будут открыты форумы на OberonCore.ru. Сейчас мы думаем над тем, как это лучше сделать. Изложу предлагаемую к обсуждению модель: структура двухуровневая (темы и подтемы). Ветки (подтемы) имеют линейную структуру (как здесь).

Обычно ОС рассматривают с трех сторон (аспектов):
1. Как среду общения пользователя с компьютером (взгляд снаружи, со стороны потребителя).
2. Как систему распределения ресурсов (взгляд изнутри, со стороны системного администратора).
3. Как абстрактную (виртуальную) машину (взгляд сбоку, со стороны программиста).

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

Чем-то напоминает известную тройку MVC (model-view-controller).

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

В связи с ролевым подходом к обсуждению видится такой набор тем:

1. Области применения ОС
2. Универсальное использование
3. Целевое использование
4. Прикладное программирование
5. Системное программирование
6. Администрирование ОС
7. Архитектура ОС
8. Процессорные архитектуры
9. Взаимодействие с другими системами (ОС, приложениями, файлами и др.)
10. Общие замечания и пожелания

Хотелось бы узнать разные точки зрения (замечания, комментарии и др.) на подобную модель общения.

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

Более краткое описание наверное можно сделать только для Scheme.

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

Ответ на »сообщение 2394«

Откинув все лишнее из Oakwood guidelines останется от силы пару страниц. Если это вся проблема описания языка Оберон и единственная вина Вирта, то по сравнению с описаниями других языков программирования это очень близко к идеалу.

Напомню что С++ до сих пор стандартизируют, сотни страниц, каждый стандарт увеличивается в двое. Читать могут это дело только настоящие гуру, после этого опять "наступают на грабли" и лезут в стандарт.

Даже новые версии компилятора gcc не компилируют старый код. Я предлагаю эти бессмысленные нападки на несчастные 16 страниц прекратить. Хотите пусть будет 18, можно даже размер шрифта увеличить - будет 20. Сути это не меняет. Описание краткое, но достаточно полное хотя бы для того, что бы сесть новичку, почитать и начать пользоваться.

Более краткое описание наверное можно сделать только для Scheme.

Ответ на »сообщение 2394« (Lisp Hobbyist)
___________________________
Прошу прощения, я невнимательно читал, позднее увидел...
Однако, следя за дискуссией, я никак в толк не возьму - что Вы хотите доказать?
Что заявление "нужно стремится описывать языки так же кратко, как это сделал Вирт" неверно?
Так в такой форме заявления нигде и не делались. Заявлялось нечто иное:
"Нужно стремиться делать такие формальные системы (в частности, ЯП), которые поддаются такому же краткому и ёмкому описанию, как Оберон Н. Вирта".
И это - "две большие разницы" (С)
Потому что все ваши замечания ничего не меняют для второго утверждения.
Ну, уточним мы все "подводные камни" донельзя, будет описание языка вместо 16 иметь... да пусть даже 40 страниц.
Что это меняет? Для сравнения с Явой, С# и т.п. Которые В ПРИНЦИПЕ не могли бы быть описаны с такой же степенью точности на таком количестве страниц. И сколько подводных камней встретилось при реализации Явы по несколькосотлистовым описаниям - Excelsior тоже могут порассказать. Особенно в сравнении со своим опытом реализации Оберона.

Ответ на »сообщение 2393« (Илья Ермаков)
___________________________


>>> Так уж получилось, что в очередной раз был помянут миф о достаточности "16-страничного описания" (тоже, кстати, здесь не в тему)... Nothing personal.


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

А мое сообщение полностью Вы читали? Там был уже приведен конкретный пример, что некто взял да и реализовал транслятор Оберона, приняв проектные решения, прямо противоположные "правильным", описанным в Oakwood guidelines. Тем и измеряется качество определения языка, что оно не позволяет таких вольностей.

Ответ на »сообщение 2382« (Lisp Hobbyist)
___________________________

Ответ на »сообщение 2367« (Руслан Богатырев)
___________________________
Так уж получилось, что в очередной раз был помянут миф о достаточности "16-страничного описания" (тоже, кстати, здесь не в тему)... Nothing personal.

Если практика показывает, что его достаточно, и неоднозначности понимания реально нигде не возникало (или приведите обратный пример, если Вам известны такие проблемы), то почему нужно утверждать обратное?
Потому, что оаквудцы решили выдать более подробное и разжёванное описание?