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

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

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

Довольно критическая статья Евгения Зуева "Синтаксис и семантика, простота и сложность" , где он прошёлся по Страуструпу и Вирту:

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

Я, кстати, вовсе не считаю, что кто-то из них безусловно прав, и не принадлежу ни к какому "лагерю".

по С++:

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

по Оберону:

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

и даже по Хаскеллу: :о))

И благодарите Бога, что мы говорим сейчас о "нормальных" языках: попытайтесь хотя бы отделить синтаксис от семантики, скажем, в языке Haskell...

Я, правда, не совсем понял, что именно он тут имел в виду...
Попытка отделения семантики Хаскелла от его синтаксиса была вполне успешно произведена как минимум один раз, автором языка Liskell (статически-типизированный диалект Лиспа, Хаскеллевская семантика под синтаксисом Лиспа)...
Или "отделить синтаксис от семантики" - не то же самое, что "отделить семантику от синтаксиса"???

Ещё он грозится когда-нибудь сделать свой собственный супер-пупер язык Цеппелин... :о)

ЗЫ. Ну вот, получилась почти полная копия сообщения Трурля на РСДНе... 8-о

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

Ну если Вы практикуете превращение ошибок физического мира в ASSERT'ы, то меня это не удивляет. А что такое ASSERT в ББ если не исключение с семантикой прерывания? ;)

Смотря как реализовать. Ран-тайм того же BlackBox может правиться в этом плане. Ежели это кому нужно.

Что есть ASSERT? Возбуждение (генерирование) исключения. При выполнении условия. Т.е. условное генерирование. Само исключение можно считать даже типизированным, поскольку есть две формы в Компонентном Паскале: ASSERT(x) и ASSERT(x,n), где x -- условие, а n -- целая константа. Целую константу можно попилить на номер модуль и относительный номер исключения в модуле. Вот уже есть четкая идентификация исключения (тип). Идем дальше. Где блок контроля? Запросто можно провести по границе ближайшей процедуры (метода). Значит, с границей проблем нет. Где обработка? Сейчас все сваливается в ран-тайм (как я понимаю) и там тихо выпадает в осадок с небольшим шумом. Можно ли подвесить обработчики исключений, управление которым будет передавать ран-тайм после перехвата генерирования? Вполне. Могут ли это обработчики "садануть" по блокам контроля, например, перезапустить соотв. процедуры? Почему нет? Смотря как написать обработчики. Можно ли влетать при обработке на середину процедуры? Сделайте "желобок" в виде ветвления и организуйте флажок ветвления. Управление попадет куда нужно. Ну а если процедуру еще оформляете в виде автомата (в смысле конечного) -- с этим еще проще.

Вывод: достаточно генерировать исключение и четко идентифицировать его. Ран-тайм языка его перехватывает и переадресует специальному ассоциатору, который и принимает решение в соответствии с имеющейся у него стратегией обработки, которую можно менять даже динамически (но сильно не зарываясь). Нужна регистрация обработчиков "прерываний" ("навешивание" обработчиков). Но в общем это не сильно отличается от обработки прерываний. Только здесь это программные прерывания. И они совсем не обязаны быть реакцией на ошибки. Они могут быть аналогом EXIT (RETURN) только с четким указанием "состояния" (идентификатором исключения). Что это означает? Что можно вводить состояния и оперировать переходом из одного в другое с помощью нелинейного управления, то бишь программных исключений.

А как верифицировать логику? Конечными автоматами и/или сетями Петри. Всего и делов.

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


Да не так уж много где встречаются эти параметры ошибок... При выстраивании слоёв абстракции в повседневной работе (даже в системных задачах) с ними уже не сталкиваешься, и IF res =... писать приходится далеко не каждые полчаса...


Ну если Вы практикуете превращение ошибок физического мира в ASSERT'ы, то меня это не удивляет. А что такое ASSERT в ББ если не исключение с семантикой прерывания? ;) Только без шансов обработать и затипизировать. Для целей моделирования и прототипирования такой подход вполне работоспособен (сам ББ по этому поводу не парится - или вообще игнорирует результаты вызова WinAPI или отправляет их в ASSERT). Ну свалится текущая команда и хрен с ней, подправим и будем работать дальше. Быстро, эффективно, а главное вообще не надо думать об обработке "нечастых" ошибок. Только для программ из реального мира такой подход уже не работает.


(Вспомнился дурдом COM-интерфейсов, где этот IF res.. по-хорошему нужно писать практически после каждого вызова метода).


Вообще белые люди использовали средства автоматического генерирования оберток для COM-интерфейсов, которые превращали HRESULT в исключения.


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


Ну и что? Я тоже не предлагаю исключения как панацею.

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

В параллельных системах тоже есть понятие стэка. Только этих стэков много. Зачем вводить противопоставление и почему для обработки ошибок в рамках одного стэка надо отказываится от семантики завершения - мне непонятно.

Относительно стеков в параллельном программировании имеет смысл посмотреть статью признанного мэтра этого направления -- Пер Бринч Хансена (ученика Петера Наура). Статья "Efficient parallel recursion" (1995). См. http://brinch-hansen.net/papers/1995c.pdf

Он ее, как и ряд других очень полезных материалов (для тех, кто интересуется мультипрограммированием вообще и параллельными вещами в частности) выложил на своем сайте http://brinch-hansen.net

Ответ на »сообщение 5129« (Jack Of Shadows)
___________________________

Самый полный и мощный механизм который я видел, реализован в лиспе. Называется condition system. Это более общий подход нежели обработка исключений. Исключения строятся на нем как частный случай.
Разница заключается в том что в condition system можно не только ошибки обрабатывать но и стратегии решения менять. Так например в исключениях, программа теряет контекст во время исключения, то есть "вылетает" на верхний уровень, в котором исключение было поймано, и обратно вернуться не может.

Весьма близко к этому.

Сравните сами с тем, что раньше писал в этом форуме. Ниже идут выдержки с указанием сообщений.


»сообщение 4340«
То, что я здесь описал -- принципиально иная идея. На уровне исходного текста на Обероне кроме ASSERT вообще ничего нет. Реакция вынесена не просто за пределы языка программирования, а за исходные тексты Оберон-модулей! А это дает весьма интересное следствие -- при обработке исключений обработчик не может оперировать сущностями языка, в котором возникло исключение!

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

»сообщение 4351«
Добавлю. Все это прозрачным образом отображается на конечные автоматы и сети Петри. С возможностями соответствующего анализа (задача достижимости состояний) на формальном уровне.

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

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

... Почему Вирт упорно считает Record более "фундаментальным" понятием, чем Object, а не частным случаем, мне никак не понять.

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

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

Ответ на »сообщение 5128« (Руслан Богатырев)
___________________________
Как ветеран движения в поддержку полноценной обработки исключений,
Насколько полноценной ? :))
Самый полный и мощный механизм который я видел, реализован в лиспе. Называется condition system. Это более общий подход нежели обработка исключений. Исключения строятся на нем как частный случай.
Разница заключается в том что в condition system можно не только ошибки обрабатывать но и стратегии решения менять. Так например в исключениях, программа теряет контекст во время исключения, то есть "вылетает" на верхний уровень, в котором исключение было поймано, и обратно вернуться не может.

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

Я правда не знаю насколько это применимо к такому нефункциональному языку как оберон.
Тут уж вам решать.

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

Я явно оговорил, что сейчас речь идет исключительно об обработке ошибок физического мира. Не надо сюда припутывать косяки C++. Модель исключений замечательно себя зарекомендовала не только в этом языке.

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

Только в Оберонах это лишнее. Вот в новом языке для системы "Роса" -- совсем другое дело. Там за его присутствие поборюсь.

Некоторые контуры давал. См. »сообщение 4333« и в том районе (выше и ниже по течению).

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

Ответ на »сообщение 5120« (Илья Ермаков)
___________________________
Про это уже сто раз говорили.
1) Никто не заставляет вызывающий код контролировать коды ошибок (только не надо опять начинать песню про культуру программирования и про идельных пограммистов). Исключения дают гарантию, что кривой код (не обработавший ошибку) не будет косячить дальше с фиг знает какими данными.
2) Протаскивание ошибок через параметры замусоривает код и добавляет уровни вложенности в if/else. Простая и наглядная запись f1(f2(f3()))) превращается в мусор.
3) Если какой-то компонент стал сигнализировать об ошибке, то не надо менять кучу интерфейсов, которые раньше не сигнализировали об ошибке.

Да не так уж много где встречаются эти параметры ошибок... При выстраивании слоёв абстракции в повседневной работе (даже в системных задачах) с ними уже не сталкиваешься, и IF res =... писать приходится далеко не каждые полчаса... (Вспомнился дурдом COM-интерфейсов, где этот IF res.. по-хорошему нужно писать практически после каждого вызова метода).


Мне кажется, что эта идея не жизнеспособна, потому что границы ее применения слишком размыты. Если какому то компонениту нужно делегировать стратегию обработки определенных ситуаций, то это проблема рещается стандартными средствами. Зачем приплетать сюда постусловия и нагружать их дополнительной семантикой - мне непонятно. Стремление не вводить нормальный механизм исключений и идти своим путем?
"Проблема решается стандартными средствами" - о том и речь. Поймите правильно, я тут не свой метод обработки исключений проталкиваю, я просто привожу пример реальной ситуации, не столь редкой, которая связана с обработкой особых ситуаций, в которой спец. механизм для обработки этих ситуаций показал свою беспомощность...
Это к вопросу о том, что нужно уметь критически анализировать "модные" механизмы и выделять границы их применимости. Например, так же с границами применимости ООП...