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

Задача та же (система уравнений размерности >= 100К, коэффициенты -- полиномы, всю арифметику делать точно, метод Гаусса, подобные члены, сортировки ... все как положено).


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

Ответ на »сообщение 1874« (Сергей Перовский)
___________________________
И теперь умение программировать стоит в одном ряду с умением читать, писать, водить машину, пользоваться лифтом
Ну очень вы ошибаетесь :))

Ответ на »сообщение 1858« (Jean)
___________________________
>>>А есть, к примеру, Дейкстра. Который, будучи по основной профессии физиком, гордо написал о своем роде занятий "программист" (кажется, еще в 1957 году).
В те годы программирование было смесью науки и искусства.
И "программист" звучало гордо.
Дейкстра - один из тех, чьими трудами программирование стало общедоступным ремеслом.
И теперь умение программировать стоит в одном ряду с умением читать, писать, водить машину, пользоваться лифтом.
И "программист" перестало звучать гордо :)

Ответ на »сообщение 1870« (Снегурочка)
___________________________

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

FLORA
La volpe lascia il pelo,
Non abbandona il vizio.

GERMONT
Che dici? Ah, ferma!


Гуглить умеем. Гут. Зачет.
Теперь бы со смыслом разобратца, чтобы к месту циритовать...

Ответ на »сообщение 1869« (Снегурочка)
___________________________

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

А в чистоту можно напихать столько всего, что от простоты останется одно воспоминание.

ПМСМ, типичное словоблудие.

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

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


Ща разберемся с пониманием.

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

На другом конце -- pepper с бэйсиком. Предполагаем, что pepper точно знает задачу и методы (метод Гаусса и полиномиальная алгебра -- оне и в Африке... вся игра на программно-архитектурных вещах).

pepper, неужели Вы серьезно думаете, что в этой ситуации Вы сумеете кого-то чем-то впечатлить?

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

FLORA
La volpe lascia il pelo,
Non abbandona il vizio.

GERMONT
Che dici? Ah, ferma!

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

Если чистота -- ничего наносного, то что может добавить отдельная "простота"?

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

Термин Хоара - conceptual economy - применительно к Оберону мне видится более точным, нежели purity, simplicity и integrity. Не все так чисто, не все так просто, не все так целостно, но концептуально экономично.

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

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

А следует ли из этого, что ООП пригодно для большинства простых систем? А если нет, то почему языки полностью "погружают" в ООП, как, например, Java?

Что касается понимания областей применимости ООП на заре его появления, то не скажу за Нигаарда и Дала, которые действительно в основном работали с имитационным моделированием, но по Хоару это не совсем так (цитирую по работе Record Handling из Летней школы NATO 1966):

Фундаментальная особенность нашего понимания мира заключается в том, что мы систематизируем свой жизненный опыт, представляя его в виде отдельных понятий или объектов (столы и стулья, банковские займы и алгебраические выражения, многочлены и люди, транзисторы и треугольники и т.п.), и наше мышление, язык и действия основываются на обозначении, описании и манипуляциях с этими объектами, с каждым в отдельности или в связи с другими объектами. Если мы хотим решить задачу на компьютере, то часто нужно построить в нем модель того аспекта реального или воображаемого мира, к которому будет применяться алгоритм решения задачи. В такой модели каждый объект исследования должен быть представлен некоторой величиной, которая "доступна" программе и может быть использована ею в процессе работы. Назовем такую величину записью (record). Каждый объект, представленный в запоминающем устройстве компьютера в виде записи, будет обладать одним или более атрибутами (attributes), с которыми и приходится иметь дело при решении задачи. Обычно эти свойства выражаются простыми значениями соответствующего типа. <...>

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

Если программа выполнялась уже в течение некоторого времени, то может случиться так, что требуется сегмент расширения, а единственные доступные сегменты находятся в опасной близости к магазинной памяти. При подобных обстоятельствах целесообразно воспользоваться процедурой автоматического собирания свободных участков памяти, подобной той, которая описана Маккарти (1960).<...>

В реальных условиях часто разбивают класс объектов на несколько взаимно исключающих подклассов (subclasses). Например, класс позвоночных можно разбить на такие подклассы, как млекопитающие, пресмыкающиеся, птицы и рыбы...
Класс записей (record class), который разбивается на подклассы, называется составным; класс или подкласс, который не является составным, называется простым. Ссылочные переменные могут, согласно их описаниям, указывать на все записи составного класса или же их область действия может быть ограничена каким-то одним определенным подклассом.<...>

Если областью действия ссылочной переменной является, согласно ее описанию, составной класс, то программист может пожелать на некотором этапе выполнения программы определить, какому из возможных подклассов фактически принадлежит запись, на которую ссылается в настоящее время эта переменная. Этого можно достигнуть с помощью специальной конструкции, называемой различитель класса записи (record-class discriminator). <...>

Расширение определения знаков операций для действий над ссылками на записи новых типов называют перегрузкой (overloading). Впервые идея перегрузки была предложена Дж.Маккарти...

Как видно из этого текста, 40 с лишним лет назад Хоар достаточно подробно описал идеи ООП, при этом ни о каком ограничении сферой имитационного моделирования речи не идет. Хоар еще указал в своей работе такие языки обработки "ООП"-записей, как Lisp, Simula I и PL/I.

Вирт в Паскале интерпретировал идеи Хоара через указатели, записи и вариантные записи. Спустя полтора десятка лет после Паскаля он пришел к выводу, что это надобно делать через type extension с запретом вариантных записей (лобовой реализации составных классов). В остальном и автоматическая сборка мусора, и наследование, и полиморфизм (без явного использования этих терминов) были Хоаром озвучены. Было это до появления Simula 67.

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

Т.е. вот так:

PROCEDURE Reci(x: REAL): REAL; (*0 < x < 2*)
  VAR y, c: REAL;
BEGIN y := 1.0; c := 1.0 – x;
  WHILE c > e DO
    (* y*x = 1-c, 0 < |c| < 1 *)
    y := y * (1.0+c); c := c*c
  END
  (* (1-e)/x <= y < 1/x *) RETURN y
END Reci

PROCEDURE Sqrt(x: REAL): REAL; (*0 < x < 2*)
  VAR y, c: REAL;
BEGIN y := x; c := 1.0 – x;
  WHILE c > e DO
    (*y2 = x*(1-c), c >= 0*)
    y := y * (1.0 + 0.5*c);
    c := c * c * (0.75 + 0.25*c)
  END ;
  RETURN y (*x*(1-e) <= y2 < x*)
END Sqrt