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

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

>>>Господа! Давайте перечислять все известные нам задачи и решать, что для
>>>них легче, рекурсия или итерация? Очень будет продуктивное обсуждение.  :)

Артем, я только смысл Вашего поста не понял :)
Вы записали такой же рекурсивный алгоритм, что и я, только на другом языке. В чем смысл этого примера? Я говорил о трудности решения задачи БЕЗ ИСПОЛЬЗОВАНИЯ РЕКУРСИИ! А с рекурсией и так все ясно!

Ответ на »сообщение 728« (SJ)
___________________________
Вывод: не надо придавать слишком большое значение словам. ООП может быть, а такого слова, как КЛАСС может и не быть. Слова - это вторично, главное - это смысл, который мы им даем. Поэтому спорить о словах - дело безнадежное. Можно говорить об объектном программировании и при этом не произносить такие слова, как ОБЪЕКТ и КЛАСС, потому что сущности, которые они выражают, можно определить и без них.
Ну, вы знаете, есть же какие-то устоявшиеся общепринятые определения. А если где-то чего-то не так называется, то мы тутама придем к полнейшему релятивизму.

Ответ на »сообщение 727« (SJ)
___________________________
Господа! Давайте перечислять все известные нам задачи и решать, что для них легче, рекурсия или итерация? Очень будет продуктивное обсуждение.  :)

...
var n : Integer;
procedure Move_Disks (n : Byte; Source, Dest, Tmp : Char);
begin
    if n = 1 then
      Writeln('Переставить диск номер 1 со столбика ', Source, ' на столбик ', Dest)
    else begin
      Move_Disks ( n-1, Source, Tmp, Dest );
      Writeln('Переставить диск номер ', n:1, ' со столбика ', Source, ' на столбик ', Dest);
      Move_Disks ( n-1, Tmp, Dest, Source);
    end
end;
begin
  Write('Введите число дисков: ');
  Readln(n);
  Writeln;
  Writeln('Последовательность инструкций для решения задачи:');
  Writeln;
  Move_Disks (n, 'A', 'C', 'B')
end.

>>>Существуют языки программирования, для которых
>>>верное утверждение: Если X - класс, то X - тип;
>>>неверное утверждение: Если X - тип, то X - класс.

Согласен.
Но я, правда, хотел сказать немножко о другом.
Язык Оберон-2 поддерживает цели и средства ООП? Можно ли в нем реализовать абстракцию, полиморфизм, инкапсуляцию?
Да, и еще раз Да!
Используется ли в этом языке слово КЛАСС?
Нет!
Вывод: не надо придавать слишком большое значение словам. ООП может быть, а такого слова, как КЛАСС может и не быть. Слова - это вторично, главное - это смысл, который мы им даем. Поэтому спорить о словах - дело безнадежное. Можно говорить об объектном программировании и при этом не произносить такие слова, как ОБЪЕКТ и КЛАСС, потому что сущности, которые они выражают, можно определить и без них.

>>>Дело в том, что для одних алгоритмов рекурсивный алгоритм легче, а для
>>>других – труднее.

Думаю - это просто аксиома, с которой никто не спорит :)))
Добавлю только следующее. И итерационный метод для одних задач легче, а других труднее. А для некоторых настолько труден, что о нем лучше и не думать.
Вот, например, как с помощью рекурсии решается знаменитая задача Люка о Ханойских башнях на языке Haskell.

module Hanoj where
main = han 64 1 2 3
han 1 x y z = print [ ("Диск с башни ", x, " переместить на ", y) ]
han n x y z = do
  han (n-1) x z y
  han 1 x y z
  han (n-1) z y x

Запускать main для 64 дисков не советую - ждать придется долго :).
Так вот, к чему это я? Попробуйте переписать алгоритм Люка без рекурсии. Я бы не взялся :).

Ответ на »сообщение 725« (SJ)
___________________________
Существуют языки программирования, для которых
  верное утверждение: Если X - класс, то X - тип;
  неверное утверждение: Если X - тип, то X - класс.

В том числе и в Дельфи.

>>>А Вы кстати не в курсе, что тип и класс в общем случае совсем не
>>>одно и то же?

Будьте добры четко и ясно определить разницу этих понятий. А то, похоже, в информационных ресурсах наступила полная путаница. Все источники, как сговорились, связывают эти два понятия вместе.
Например:
1) Класс - это абстрактный тип данных, поставляемый с возможно частичной реализацией.
http://www.intuit.ru/department/se/oopbases/7/
2) Класс - это абстрактный тип данных, который обладает свойством наследования.
http://www.geocities.com/CapeCanaveral/Hall/2334/articles/art1/art1.html
3) What is an abstract data type? Well, a data type is what we have just presented in chapter Chapter 17: in Python, as in many object-oriented language, it is a class.
http://www.pasteur.fr/formation/infobio/python/ch18s03.html

В общем все, как сговорились, считают, что класс это абстрактный тип данных с определенными свойствами. Или наоборот: абстрактный тип данных с определенными свойствами можно называть классом. Так кто же прав?

Ответ на »сообщение 723« (hugi)
___________________________
hugi, не обижайтесь, но это обсусоливание целей и средств  надо заканчивать. Вы всё равно друг другу ничего не докажете. С тем, что целью ООП является борьба со сложностью, никто не спорит. Но то же самое мы можем сказать и о ФП. Даже не так. Цель и того и другого – это написание работающих программ. Средства немного разные, даже не средства, а реализации. Если средствами называть инкапсуляцию, полиморфизм и.т.д. – то, Jack тут прав, в ФЯ они тоже есть, но реализованы по-другому. Вот в чем он не прав, так это в огульном охаивании, как он говорит, императивщины, да и собственно ООП. Jack пел тут осанну рекурсии и говорил, что это естественный образ мышления. А вы посмотрите на алгоритм умножения матриц на Хаскеле - http://dada.perl.it/shootout/matrix.ghc.html - несколько сложновато. Императивная (итеративная)  версия более очевидная. Мало того, странные результаты выполнения - http://dada.perl.it/shootout/ghc.html - *Test Implemented but not measured (timeout or error).
Я не хочу сказать, что функциональное умножение матриц невозможно. Я не буду становиться «анти-Jack of Shadows» и утверждать, что рекурсия – это отстой. Дело в том, что для одних алгоритмов рекурсивный алгоритм легче, а для других – труднее. И, кстати, на Дельфи и на C# (и т.д. и т.п.) мы можем выбирать между рекурсией и итерацией. (Со всей болтовней насчет переполнения стека, я надеюсь, мы закончили уже до этого). А на чистых ФЯ нам придется извращаться. Про Лисп я промолчу, дабы в очередной раз не прослыть провокатором  :)  Опытный и талантливый программист напишет чудесные программы и на Лиспе, и на VB.Net.  А вот охаивание какой-либо одной технологии и приписывание магических качеств другой – это уже, извините, к программированию не относится.

P.S. Кстати, постоянные утверждения Jack of Shadow  о том, что ООП-программисты не пользуются рекурсией – тоже чистейшей воды демагогия. Мне что тут, считать, сколько раз за прошлую неделю я использовал рекурсию (да еще и в сочетании с наследованием)? 

Ответ на »сообщение 707« (Jack Of Shadows)
___________________________
Вы настойчиво продолжаете подменять понятия! В книге Буча Вы не нашли подтверждения своей гипотезе, теперь пытаетесь вывернуться. Даже неприятно как-то, честное слово!
Что мол ООП это инкапсуляция, полиморфизм и наследование.
Это ложь! Этой формуле учат во всех институтах, но у Буча она в таком виде не фигурирует!
В одной фразе перечислены 2 цели и одно средство достижения этих целей (наследование).
То есть, следуя Вашей логике инкапсуляция и полиморфизм достигаются при помощь наследования?! Здорово сказано!
Немудрено запутаться.
Вот Вы и запутались!
Я думаю если бы эти гуру творили сегодня, имея за плечами опыт более чем 30 лет ООП, то фраза эта выглядела бы по другому.
ООП это инкапсуляция, полиморфизм и абстракция.
Читайте Буча, дорогой зановооткрыватель велосипеда!
Но когда вы пытаетесь формализовать эту вашу идею "борьбы со сложностью" то она выливается в ряд концепций - абстракция, инкапсуляция, полиморфизм. То есть абстракция, инкапсуляция, полиморфизм - это и есть "борьба со сложностью" сказанная формальным языком.
Все перечисленные Вами термины -- лишь орудия "мировой революции", средства борьбы со сложностью.
После чего вы садитесь и думаете, каким механизмом реализовать эти три концепции.
Инкапуляцию можно реализовать модульностью. А можно и классами.
Полиморфизм (переопределение функций) тоже не нуждается в ООП. Он присутствует практически во всех языках отдельно.
Абстракцию можно реализовать наследованием. А можно и higher order functions и closures.
Я не понимаю! Из того, что базовые концепции ООП нужно как-то реализовывать, Вы заключаете, что это ЦЕЛИ ООП?! Потрясающе!!!
Все они гоняются за одними и теми же целями - абстракция, инкапсуляция, полиморфизм.
Все они положили эти СРЕДСТВА в основу своих языков!
Эти термины совсем не то что вы под этим понимаете.
Все эти термины специфичны для ООП. Некоторые из них, насколько я знаю, введены Кеем (по крайней мере superclass).
В конце концов в хаскеле тоже есть термин type  classes , что совсем не означает что в хаскеле есть классы.
Да кто бы спорил! Но в цитате фигурировали "конкретные" классы из ООП.
Речь идет о иерархии типов. Термином class в теории рипов обозначают тип.
Да что Вы говорите! А я думал в теории типов тип обозначают термином "type". А Вы кстати не в курсе, что тип и класс в общем случае совсем не одно и то же?
Вас вводят в заблуждение "знакомые" слова.
Всё, сказанное Вами, говорит как раз об обратном!