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

Ответ на »сообщение 1801« (pepper)
___________________________
В этом примере в функциях нет локальных объектов с деструкторами, следовательно, дополнительный код генерировать не к чему. Таким топорным тестированием трудно что-то выявить. Нужно либо подбирать хороший тест с активным размещением объектов с деструкторами на стеке и затем дизассемблировать код, либо верить на слово аффтарам книжек типа Рихтера и Робинса...

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

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

P.S. По поводу искусственности теста - согласен. Но чего-то более реального предложить не могу.

Ответ на »сообщение 1814« (RBV)
___________________________
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#%_sec_2.1.4

:)

Ответ на »сообщение 1745« (info21)

(И скромно признаюсь, что "Purity" в заглавии доклада Гуткнехта на Дне Оберона в ЦЕРНе возникло по моему настоянию вместо Simplicity; "The Power of Simplicity" -- это на самом деле название достаточно известного не то худ. фильма, не то книги, и Гуткнехт хотел сыграть на этой аллюзии, тем более что в ETH давно и привычно говорят про simplicity; поскольку в ЦЕРНе я нес колоссальный репутационный риск при организации этого дня, то голову ломал над каждым словом в программе; в этом плане поговорка "простота хуже воровства" меня давно беспокоила.)

Сегодняшняя заметка на http://elementy.ru/blogs/users/spark/10851/ навела меня на такую мысль: наверное есть корреляция между противопоставлениями "чистые языки программирования vs нечистые" и "фундаментальные физические теориии vs эмпирические".

Ответ на »сообщение 1821« (Trurl)
___________________________
Вообще, термин "объектный подход" в последнее время применяют для обозначения "ООП по Кею", противопоставляя его термину "ООП", узурпированому мейнстримом.
Ну-дык, истинный (уже и так :о) ) объектный подход подразумевает и предусматривает существование особых структур данных в среде поддержки времени исполнения, а мейнстриму втюхивают за "ООП" в том числе и побочное следствие работы макросредств управления компиляцией...

Ответ на »сообщение 1815« (AVC)
___________________________
>>>Вот вопрос: в каком учебнике современный программист найдет сoвет, как ему выбрать "эпсилон"?
В любом учебнике по численным методам. ;-)

Ответ на »сообщение 1803« (Сергей Перовский)
___________________________
>>>Если рассматривать Оберон, как язык для обучения, то надо иметь в виду, что "неявная" реализация в нем ООП приведет к серьезным трудностям с пониманием объектного подхода.

Вообще, термин "объектный подход" в последнее время применяют для обозначения "ООП по Кею", противопоставляя его термину "ООП", узурпированому мейнстримом.
Наверное, как раз для облегчения обучения последнему в компилятор Оберона от ETH ввели синтаксические расширения

TYPE
Point = OBJECT (VisualObject)
  VAR pos: Coordinate;
  PROCEDURE Draw*;
  BEGIN
    MyGraph.Dot(pos.x, pos.y)
  END Draw;
END Point;

Ответ на »сообщение 1817« (RBV)
___________________________
Да и общая математическая подготовка должна быть на уровне.
Это - к вопросу "чего не хватает?" Всё-таки, вернулись к тому, с чего начали...
Безусловно, и вопрос выбора средств реализации растёт из того же места. "Лепилы" не будут "задумываться", а берут, что им первое на глаза положат. И даже если потом на что-то "иное" натыкаются, остаётся только "какое-то тупое недоумение" (с) МЖ

http://foto.mail.ru/mail/vladimir_sun/Havefun/i-12.jpg :о)

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

http://www.xsc.de/ - аналог есть и в Оберонах (ETH Oberon, расширение Oberon-X, если склероз мне не изменяет). Только в вашем случае это не поможет.

Спасибо!
Скачал исходники, так что может быть и поможет.
Или хотя бы научит. :)

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


Погрешность накапливается в численных методах однозначно. На то они и численные :). Тип "значение и погрешность" не подойдет. Алгебру для него устанете создавать. Есть более простое решение - интервальное исчисление, с проработанной теорией. Но производительность, конечно, упадет.

По оценке Кнута, всего в 2 раза.
См. т.2. ("Получисленные алгоритмы"), "Вильямс", 2000, с.278.

http://www.xsc.de/ - аналог есть и в Оберонах (ETH Oberon, расширение Oberon-X, если склероз мне не изменяет). Только в вашем случае это не поможет.

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