Заканчиваю "треп" на "философские" темы! :))))
Артем, hugi и др.!
Помогите разобраться с конкретным вопросом.
В большинстве "динамических" языков (скриптовых и функциональных), например, в Haskell, PHP, Python, Ruby (и т.д.) реализован абстрактный тип данных МАССИВ. С "внешней" точки зрения этот тип данных очень похож на список, даже синтаксис во всех языках почти одинаковый!
Для массива, как я понимаю, главное это доступ к элементам по индексу. В классическом массиве быстрота доступа достигается путем расположения элементов в смежных ячейках памяти - адрес любого элемента просто вычисляется по его индексу. Но в "классическом" списке все наоборот - элементы выделяются в произвольных областях динамической памяти (heap) и быстрый произвольный доступ к элементу невозможен, даже в 2-направленном списке.
Я попробовал в Haskell создать массив более менее приличного размера: матрицу 500 Х 500 = 250000 элементов. На создание Hugs "убил" минуты 2-3! Явно похоже на создание списка - на выделение одного куска памяти для классического array столько времени потратить нельзя. Но при обращении к элементам не заметил разницы между обращением к a!(1,1) и a!(500,500). Значит что-то в "массиве-списке" ускоряет обращение по индексу. Что именно? Расположение элементов в списке в смежных полях памяти (как в "классическом" Array) или другие методы?
Вот конкретный вопрос, без "философии" :). Кто знает ответ?

Ответ на »сообщение 869« (SJ)
___________________________
Не смешите меня. Ни С++, ни Delphi чистыми ООП-языками не являются.
Вы невнимательно прочитали:
Что мы и наблюдаем в чистых (не смешаных, как C++ и Delphi) ООП-языках.

>>>Не смешите меня. Ни С++, ни Delphi чистыми ООП-языками не являются
Сорри! Не заметил скобки :(

to hugi
>>>Связанные логически данные являются объектом в концептуальном смысле :),
>>>но не обязательно являются объектом в смысле ООП.

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

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

OK! Тем более, что говорили мы, как выяснилось, о совершенно разных вещах :)

to Артем

>>>Тогда уважаемый программист и питерский бомж эквивалентны

Смейтесь, но это действительно так. Их биологическую эквивалентность любой врач подтвердит :)

>>>Оставьте Вселенную в покое. Речь идет о конкретных реализациях. Если уж
>>>говорить о теории ООП, то в идеале в ней все типы являются классами, а
>>>экземпляры типов – объектами. Что мы и наблюдаем в чистых (не смешаных,
>>>как C++ и Delphi) ООП-языках.

Не смешите меня. Ни С++, ни Delphi чистыми ООП-языками не являются. На эту тему не хочу распространяться - поговорите с любым программистом на тему "объектной чистоты" языка С++. Тут и об обыкновенной "чистоте" никто даже не думает говорить, а Вы об "объектной"...
Хотите конкретику - пожалуйста. В объектно-ориентированном языке Oberon-2 есть тип данных REAL, который не является классом в смысле ООП, а следовательно, и переменные этого типа не являются объектами в смысле ООП.
В рамках этой конкретики Вы согласны, что понятия "данные" и "объект" не являются синонимами друг друга?

>>>Не смешите меня – у вас, что, есть формула для преобразования одного в
>>>другое? Это что, так просто? :)

Пора бы знать, что в программировании две программы (алгоритма) считаются эквивалентными в том случае, когда они реализуют вычисление одной и  той же функции. Иначе говоря, на одном и том же множестве определения функции дают одно и то же множество значений при любых условиях. Эквивалентность понимается, конечно, только в семантическом смысле слова. По синтаксической форме и даже по системе команд процессора (!) они могут отличаться очень существенно.
Я могу удивить Вас еще больше: все ныне существующие компьютеры СЕМАНТИЧЕСКИ ЭКВИВАЛЕНТНЫ (как бомж и программист в Вашем примере). Любую программу, написанную в системе команд и языков одного компьютера, можно переписать для любого другого. И никто никаких "формул преобразования" не требует - просто математики еще в прошлом веке доказали эквивалентность всех машин Тьюринга, которыми, собственно, и являются любые существующие в мире процессоры.

Ответ на »сообщение 865« (гость)
___________________________


Кто-нибудь ещё помнит курс матанализа? А именно - ряды, в которых поледующий член можно выразить через предыдущие, например тот же факториал.
Во всех вузовских учебниках и справочниках такие ряды (в т.ч., кстати, и факториал) обозначаются практически всегда рекурсивно - как Xi+1=f(Xi).

Ну да: гармоничесий ряд - 1+1/2+1/3+...1/n+..., степенной, ряд Тейлора, ряд Фурье - где же рекурсия?

Вдогонку:
В высшей степени интересно посмотреть, как многоуважаемые джинны напишут итеративным, а не рекурсивным, способом формулы для обычных полиномо Чебышева.  :)))

Ответ на »сообщение 865« (гость)
___________________________
То, что такую нотацию предпочитают люди, для которых работа с абстрактными понятиями - образ жизни, о чём-нибудь, да говорит.

Еше бы. Ведь точки в выражении (1..n) без рекурсии ФОРМАЛИЗОВАТЬ не получится.
А математики неформального языка не понимают и не признают.

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

Кто-нибудь ещё помнит курс матанализа? А именно - ряды, в которых поледующий член можно выразить через предыдущие, например тот же факториал.
Во всех вузовских учебниках и справочниках такие ряды (в т.ч., кстати, и факториал) обозначаются практически всегда рекурсивно - как Xi+1=f(Xi).

То, что такую нотацию предпочитают люди, для которых работа с абстрактными понятиями - образ жизни, о чём-нибудь, да говорит.

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

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

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

<Number> ::= <Number><Digit>|<Digit>

формально правильна, но разбор такой грамматики - вещь неприятная. А с итеративным определением подобных проблем не возникает.

В общем, всё сводится к спору, что итерацию можно, конечно, заменить рекурсией, только вот стоит ли? По-моему, нет: итерация понятнее, легче реализуется и быстрее работает.

Ответ на »сообщение 861« (Geniepro)
___________________________
Closures это не только доступ к локальным переменным своего контекста.
Это также инкапсулирование. Как например private поле класса инкапсулировано в обьекте класса, и методы  этого класса могут менять значение этого поля и считывать его много раз.
Так и closures это функция которая может "закрывать" собой локальную переменную. Но эта переменная не уничтожается когда функция отрабатывает.

Я приводил пример в »сообщение 113«

(let ((counter 0))
  (defun new-id () (incf counter))
  (defun reset-id () (setq counter 0)))

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

Точно также как private поле класса и методы, работающие с этим полем.

Отсюда и вопрос, на кой ляд в ООП closures ? Они там как собаке боковой карман.
Свои адекватные средства есть, а привнесенные подвисают в воздухе без поддержки остальных функциональных средств.
Если переносить механизмы ФП в ООП язык, то только всем скопом.
Тогда хотя бы у программистов появляестя выбор - либо ООП парадигма, либо ФП.

Понятно что и Sun и MS делают это под давлением обстоятельств, спустя рукава, со скрежетом.
Так например заявленные closures в java 7 будет еще только через 2 года.
Явно не торопятся.

Да только плевать уже. Раз практические задачи из области web разработки попали в диапазон лиспа, окамла, python и ruby, то программисты не будут ждать черт те знает сколько лет.
Когда мне понадобилось работать с web я перешел на java. И работал на нем несколько лет.
Теперь я ухожу в лисп, потому что у меня появилась такая возможность, и что там Sun собирается по чайной ложечке в 10 лет добавлять в java мне честно говоря до лампочки.
На наших северах до сих пор стоит JDK 1.4 . И апгрейдить до 5 или уже скоро выходящей 6, я не собираюсь.
Для меня java застыла на 1.4, также как и дельфи застыл на 7.0

Назад пути нет.