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

E>>>Да, опыт внушает.
E>>>Но, имхо, как раз фраза Страуструпа к тебе и относится, т.к. твой большой опыт не позволяет тебе увидеть, что он (опыт) всего лишь маленькая капля в море.
AVC>>(голосом кота Матроскина) Я еще и СУБД писал...
E>Я тоже. И сейчас пишу.
E>И еще раз, еще более уверенно в своей правоте, повторю, что слова Страуструпа к тебе и относятся.

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

AVC>>ИМХО, никакой иной "пользы", кроме того, что это все это проделано неявно для программиста, не видно.

E>Именно в этом задача и состояла -- нужно было повысить уровень абстракции.

AVC>>Такая "неявность" скорее вредна, чем полезна (пример с неявным (!) преобразованием во float через bool я уже приводил).
AVC>>Чем хуже тривиальное get(a, i, j)? Только тем, что несколько иначе выглядит? Так ведь это и хорошо!

E>Нет, это плохо. Такая запись гораздо длинее и черевата ошибками (как, например, заметить, где i и j случайно поменяли местами). А в получившемся варианте использовалась стандартная математическая запись.

Интересно, а что помешает поменять местами i и j, например, в выражении

a[j][i]

?

E>И именно эта запись позволила корректно и быстро записать выражения аппроксимации (треугольниками и прямоугольниками) при вычислении начального значения матрицы (этим занимался не я, но те, кто это делал сказали мне спасибо), а формулы там трехэтажные были. А мне такая запись позволила легко реализовать три или четыре метода решения СЛАУ в поисках того метода, который бы давал решение за приемлимое время (вообще в этой задаче метод итераций сходился медлено, методы Гауса и квадратного корня нельзя было применять из-за особенности матрицы, пришлось использовать метод Халецкого).

AVC>>В противном случае программист может быть просто обманут, думая, что и правда имеет дело с массивом.

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

E>Или ты считаешь, что операционнки с виртуальной памятью тебя обманывают, неявно вытесняя старые страницы на диск и подкачивая их по необходимости?

Когда все это тормозит (что обыкновенно), то я и правда начинаю сердиться.

AVC>>>>А насчет вычислений: никуда Вам от них не деться. Даже индекс в массиве Вам приходится вычислять.
AVC>>>>А там где вычисления — там и потенциальные ошибки.
E>>>Никогда не сталкивался с потерей точности или ошибками вычислений при вычислении целочисленных индексов из целочисленных же значений.
AVC>>И за границы массива никогда не выходили?!
E>Выход за границы массива и потеря точности при вычислениях -- это совершенно разные вещи. В первом случае я получаю абсолютно точное значение, просто из-за моей ошибки оно оказывается не в том диапазоне. А реальная потеря точности, это когда в правильном выражении получается неправильный результат из-за ограничений платформы. Например: c/(a-b). Если a != b, то это выражение корректно и в математическом смысле всегда дает корректный результат. Но, если a и b являются вещественными числами, то корректность выражения начнет зависеть от величины (a-b). Если это довольно близкие значения, то их разность окажется слишком маленьким числом из-за чего c/(a-b) не сможет быть представлена.
E>Еще один пример неявной потрери точности обсуждался в форуме по C++.

Обратите внимание: я говорил об ошибках в вычислениях, а Вы — о потере точности.
ИМХО, Вы слишком сузили тему.

AVC>>>>А так программисты вынуждены были искать, где пожертвовать надежностью.
E>>>Так ведь это обычные условия. В реальной жизни всегда чего-нибудь не хватает.

AVC>>Одно дело, когда "чего-нибудь не хватает" в офисном приложении.
AVC>>Другое дело — в аэрокосмической, ядерной или военной областях.
AVC>>Я бы на Вашем месте не был настроен столь философски.

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

AVC>>Но, кажется, отсюда мы с Вами делаем разные выводы. Вы говорите, что так было, так есть, так будет (или нет?). А я говорю, что, если не хватает ресурсов для нормального (защищенного и типо-безопасного) программирования, лучше вообще не браться за подобные проекты.

E>В любой проблеме скрыта возможность ((С) американская поговорка).

Угу. Особенно для американцев. И особенно — в чужих проблемах.

E>Так может тогда прогресс вообще остановить?

А что такое прогресс?

E>>>Это не дурдом, это особенность.
AVC>>Я, наверное, эту Вашу фразу на стенку повешу.
AVC>>Насколько здесь выразительнее сформулирована старая мысль "это не баг, это фича".
E>Буду рад. Только авторство укажи

Обязательно!

E>На самом деле "в каждом закуточке свои заморочки". Глупо утверждать, что С++ -- это идеальный язык программирования. Но он реальный язык, с реальными возможностями и проблемами. И здесь можно либо просто оказаться от использования C++ (тогда не понятно, зачем на него наезжать), либо учитывать его особенности в работе и получать предсказуемые результаты, либо занять позицию страуса, а потом громко кричать: "Настоящие программисты на C++ не программируют!".
E>Конечно не программируют, они на нем думают, а потом просто свои мысли записывают. И все.

E>Да, а твой пример наглядно показал, насколько нужно больше написать, чтобы сделать то, что в C++ вообще не занимает времени. Более того, твой код LocalSearch во-первых, жестко привязан к типу массива и искомого элемента и, во-вторых, жестко привязан к внутренностям GlobalProc. Поэтому тебе придется переписывать LocalSearch для GlobalProcReal (там где будут использоваться вещественные значения) и придется переписывать, если в GlobalProc нужно будет сделать поиск по еще одному массивчику b другой размерности.
E>А теперь сравни это все с std::find_if

В данном случае Ваша критика несправедлива.
Вложенная процедура играет здесь ту же роль, что и блок в Си++ (собственно, и является блоком), только более выразительно.
Что касается зависимости LocalSearch от типа.
Во-первых, в данном частном случае я мог не использовать параметр (x: INTEGER), тогда в теле LocalSearch не было бы упоминания о типе. Я сделал это только для наглядности, чтобы проиллюстрировать прием.
Во-вторых, в Си++ зависимость от типа никак не меньше.
Говоря о find_if, Вы запамятовали упомянуть о некоторых деталях.
Во-первых, использование find_if предполагает использование итератора, причем привязанного как к типу элемента, так и к типу контейнера. Что-то вроде:

list<elem_type>::iterator i = find_if(l.begin(), l.end(), cond(v));
if (i != l.end()) { ... }

Во-вторых, Вы почему-то ничего не сказали о таких мелочах, как написании класса предиката, наследовании от unary_function или binary_function и т.д.
В-третьих, сколько всей этой ерунды надо помнить...

E>Кстати, есть ли для Modula и Oberon стандарт? ANSI или ISO?

Для Модулы-2 есть стандарт ISO (уже давно).
Именно поэтому в аэрокосмической сфере применяются в основном Ада и Модула-2 — языки, имеющие стандарты ISO.

AVC>>Знаете, это достаточно забавно, но среди Си++программистов достаточно много людей с художественными (но, к сожалению, не математическими) наклонностями!
E>Так может это и хорошо? Например, я часто видел, что у людей с ярковыраженным математическим мышлением довольно плохо с неординарными идеями.

О художественных способностях Си++программистов я упомянул с симпатией.
Мне нравится в них это качество. Другие их качества ине нравятся гораздо меньше.
И вообще... Про нас, математиков, все говорят, что мы сухари (х/ф "17 мгновений весны").
Вся математика — просто скукотища какая-то... Ни одной неординарной идеи!
А, впрочем, может — сверим неординарность мышления?
Вот у меня на RSDN ник AVC. Все просто и ординарно — это инициалы: имя, отчество и фамилия.
А как насчет eao? Ну, наверное, — ничего похожего...