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

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


Золотые слова. Еще бы и ресурсы у разработчиков для этого нашлись.

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

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

Насчет библиотек и системы программирования -- это уже зона прагматики языка. Давайте все же будем различать синтаксис, семантику и прагматику. Евгений Зуев поднял достаточно интересный вопрос в отношении простоты и сложности, которая воплощается у языка программирования в форме (синтаксисе) и содержании (семантике).

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

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

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

Вирт в Обероне шел простым и понятным путем. Сначала выбирается область применения инструмента (цели): системное программирование применительно к разработке операционной системы Oberon (однопользовательская ОС класса Developer's OS), в которой главными требованиями являются динамическая расширяемость (extensible programming) при изолированности (герметичности) системы типов. Затем используется принцип концептуальной экономии (по Хоару): Вирт брал сбалансированный набор базовых сущностей и их отношений (связей, правил -- моделью была классическая Модула-2) и удалял из языка (синтаксиса и семантики) те вещи, которые не разрушали исходные цели (целеполагание). Другими словами, искал ту грань, за которой система (в данном случае язык Оберон) будет оптимизирована по критерию концептуальной экономии и не рассыпется. На мой взгляд, этой цели он добился. Для реализации системы Oberon язык Оберон выглядит близким к идеалу.

Теперь посмотрим на C++. Цели, которые ставил перед собой Страуструп, существенно отличались от целей, поставленных Виртом преде языком Оберон. Страуструп хотел с одной стороны воплотить идеи своего любимого языка (Симулы-67), оставаясь на основе синтаксиса (и семантики!) Си. Т.е. обеспечить преемственность. И в этом плане с Виртом они не сильно расходятся (преемственность по синтаксису и семантике у Оберона с Модулой-2 даже куда выше, чем у Си и C++). А вот с другой -- он хотел создать самодостаточный язык, который может практически все. Поиск пресловутого философского камня.

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

Тем, кто интересуется этой проблематикой, очень рекомендую внимательно перечитать (под призмой того, что я здесь пояснил) книгу Страуструпа "Дизайн и эволюция C++" (1994; пер. на русский язык -- 2006). Я вообще рассматриваю эту книгу как замечательное пособие нам, участникам проекта "Роса" (где будут создаваться НОВЫЕ языки). Прежде всего в отношении того, как НЕ НАДО наступать на чужие грабли.

Вот цитата из этой книги (с. 113-114), характеризующая процесс принятия решения в C++, когда вместо приоритета технологического совершенства во главу угла ставится удобство для нынешних программистов (потакание стереотипам): "Пришлось принять правило C о том, что глобальные имена по умолчанию видимы в других единицах трансляции. Просто не было поддержки для правила, более жестко ограничивающего область видимости имен. Это означало, что в C++, как и в C, не будет механизма для выражения модульности на уровне выше класса или файла. Это послужило причиной многих жалоб, пока комитет ANSI/ISO не принял пространства имен в качестве механизма, позволяющего избежать непреднамеренного совмещения имен. Однако Дуг Макилрой и другие возражали, что C-программисты не оценят язык, где каждый объект и функцию, которые должны быть доступны из другой единицы трансляции, придется явно объявлять таковыми. Возможно, в то время они были правы и уберегли меня от серьезной ошибки."

А вот ключевой момент, отличающий подходы Вирта и Страуструпа. Он заключен в следующей цитате. См. с.276. Привожу слова Страуструпа: “Множественное наследование виделось как первое существенное расширение C++. Некоторые опытные пользователи C++ считали, что это ненужное усложнение, которое повлечет за собой поток новых средств. Например, на самой первой конференции по C++ в Санта-Фе Том Каргилл сорвал аплодисменты, высказав забавное, но не очень реалистичное предложение: каждый, кто предлагает включить в C++ новое средство, должен сказать, какое из старых средств, равных по сложности новому, следует исключить. Мне такой подход нравится, но я все же не могу утверждать, что C++ стал бы лучше, не будь в нем множественного наследования, или что C++ образца 1985 г. лучше C++ 1993 г. Веселье продолжил Джим Уолдо. Он продолжил мысль Тома, высказав следующую идею: обязать предлагающих новые средства пожертвовать... свою почку. Это, по мнению Джима, заставит каждого не один раз подумать, прежде чем вносить предложение, причем даже лишенные инстинкта самосохранения не смогут внести более двух предложений”.

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

P.S. В качестве иллюстрации к своей пространной реплике хотел бы напомнить слова великого немецкого философа Имманула Канта, которые нам стоит помнить: "Кто отказался от излишеств, тот избавился от лишений".

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

Семантика от греческого  semantikos «обозначающий» - отображение внешнего мира.
То, что семантика и синтаксис связаны следует из давнишнего факта признания семантического
компонента частью грамматики. Перевод подстрочником приводит к смешным ситуациям.
Хороший перевод строится на основе семантических сетей.

Представление моделей в виде семантической сети графом также давно распространено.
И только частный случай такой сети - иерархическая, древовидная.
Тем не менее, с упорством, достойным лучшего применения её считают панацеей в информатике.
>>> отображения программного модуля в виде дерева
причём "дерево" жирным! (вот она, отрыжка наследования в ООП!)

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

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

И ещё частное замечание. На блок-схеме условный оператор обозначался ромбом с ветвлением.
Хотя, кроме входных данных для манипуляции, есть ещё вход - условие.
Оно где-то вычисляется и правильнее было бы обозначать условный оператор четырёхполюсником.

Ответ на »сообщение 2903« (Гарин)
___________________________

2) Запретят хорошие и открытые продукты, которые "не-российские". Например, BlackBox for Windows. На Руси ведь всегда из одной крайности в другую бросаются;
Linux тоже не российский. :) Но если говорить о его российской сборке, то такая есть и у BlackBox. :)

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

... семантика может оказаться недостаточно сложной для решаемых задач (Обероны). Выход все-таки видится в том, чтобы семантика была адекватна сложности задач (одна из предпосылок C++), но при этом усилия были направлены на упрощение синтаксиса (традиции Оберонов).

Про недостаточную сложность надо еще доказать.
Особенно ввиду путаницы насчет семантики -- семантика ортогональной сочетаемости без ограничений -- как Вы сей пункт учитываете? К примеру.

Прежде чем  псевдомудрость типа "и ты прав, и ты тоже" являть, надо бы со смыслом мудрых слов вроде семантики разобраться.

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

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

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

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

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

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

Что-то мы с Вами "кто - про Фому, а кто - про Ерему". Говорим о совершенно разных вещах. Я - о способах ускорения работы файловой системы. Вы - об автоматической подстройке приложений под пользователя. Вещь это, безусловно, нужная, но я говорил совершенно о другом.

Ответ на »сообщение 2901« (Yo-Yo)
___________________________

FYI.
"Синтаксис и семантика, простота и сложность" (Е. Зуев - автор русского С++ компилятора) http://zouev.blogspot.com/2007/09/blog-post.html

Разумеется, семантика языка программирования (кстати, в совокупности с библиотеками и системой программирования) по своему уровню сложности должна соответствовать решаемым задачам. Но из этого вовсе не следует, что сложная семантика не может быть выражена достаточно простым синтаксисом. Конечно, если не прикладывать необходимых творческих усилий, таланта, опыта то при сложной семантике синтаксис будет запутанным, непрозрачным и противоречивым (C++). И наоборот, если экономия усилий сочетается с требованием простоты синтаксиса, то семантика может оказаться недостаточно сложной для решаемых задач (Обероны). Выход все-таки видится в том, чтобы семантика была адекватна сложности задач (одна из предпосылок C++), но при этом усилия были направлены на упрощение синтаксиса (традиции Оберонов).

Ответ на »сообщение 2902« (Как слышно? Приём!)
___________________________

Ответ на »сообщение 2901« (Yo-Yo)
___________________________
Оберону ввиду его простоты не хватает надстройки.
Примечателен комментарий.
Только я бы сказал не "отображать программы в виде дерева", а в виде графа.


Думаю, что кроме низкоуровневого отображения программного модуля в виде дерева, должно быть и высокоуровневое представление программируемой модели как совокупности внешней среды и подсистем. Причем графически это может быть несколько разных типовых представлений, поддерживаемых системой программирования:
1. как общий гипертекстовый список подсистем, их элементов
2. как дерево зависимых или влияющих подсистем (и элементов) для указанной подсистемы (элемента),
3. как гипертекстовая матрица, описывающая зависмость одних подсистем от других
4. как граф, соответствующий матрице, указанной в пункте 3.
... другие пока не приходят в голову, но вполне возможны

Хочу подчеркнуть, что структура программы (компилируемые модули, области видимости имен, объекты) и структура модели (подсистемы, элементы) вообще говоря не обязаны совпадать. При разработке сверху вниз следует начинать со структуры модели, на которую затем накладывать структуру программы. Нынешние системы программирования (включая UML) вообще не описывают структуру модели, которая остается в текстовой документации без какой-либо связи с программным кодом.

Смотрели новости, господа?
Господин министр по ИКТ (не помню, как его зовут) встречался с "российскими программистами" и озвучил новую политику в области информатизации. В сюжете была показана российская школа с детишками, осваивающими Linux "российской сборки". И прозвучала мысль: "Даешь открытое российское ПО в учреждения образования!". Похоже, что мечты о "российском ПО" уже овладели кое-кем в "коридорах власти".
Боюсь только двух вещей:
1) Вся идея сведется только к одному: заменить в российских школах и вузах Windows на Linux;
2) Запретят хорошие и открытые продукты, которые "не-российские". Например, BlackBox for Windows. На Руси ведь всегда из одной крайности в другую бросаются;
В общем боюсь одной вечной российской проблемы - дураков. Хотелось бы, что б поскорей старых дураков на новых поменяли. Пока они успеют "развернуться" можно будет поработать спокойно :)