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

Но это вовсе не значит, что такое печальное положение сохраняется и сегодня...

А я и не утверждала подобного. Просто сказала, что он "слегка" недооценил своего детища. Серьезно, без стеба.

Вы считаете, что "смерть Кащея" уже наступила? Интересно, и кто же по-вашему заменил Лисп?

Что Вы! Просто указала, где заветная игла в яйце. К Лиспу отношусь уважительно. Но - не панацея. Не Айс! В толк не возьму, почему одним языкам надо утверждаться за счет других? Мирно жить не получается?

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

В мае 1961 г. Маккарти писал ("A Basis for a Mathematical Theory of Computation") относительно главного направления - разработки универсального языка программирования:

We believe that this goal has been written off prematurely by a number of people. Our opinion of the present situation is that ALGOL is on the right track but mainly lacks the ability to describe different kinds of data, that COBOL is a step up a blind alley on account of its orientation towards English which is not well suited to the formal description of procedures, and that UNCOL is an exercise in group wishful thinking.

Т.е. Алгол (читай, Оберон) - то, что надо.

Причем это спустя год после публикации в Communications of the ACM своей главной работы по Лиспу: Recursive Functions of Symbolic Expressions and Their Computation by Machine. Part 1 (часть 2 так и не была написана) и два года спустя после первой реализации Лиспа. Видать, недооценил перспектив своего детища. А зря. Язык науниверсальнейший и наинепобедимейший!

Ключевое слово - "present situation". Т.е. Маккарти отдавал себе отчёт в том, что в конце 50х-начале 60х годов использование Лиспа нерационально - слишком большие требования к тогдашним скудным вычислительным ресурсам...
Но это вовсе не значит, что такое печальное положение сохраняется и сегодня...


P.S. Где хранится "смерть Кащея", Маккарти сознался еще в 1978 г. (History of LISP):

LISP will become obsolete when someone makes a more comprehensive language that dominates LISP practically and also gives a clear mathematical semantics to a more comprehensive set of features.

Вы считаете, что "смерть Кащея" уже наступила? Интересно, и кто же по-вашему заменил Лисп?

Ответ на »сообщение 2013« (Сергей Перовский)
___________________________
Упс. Вы правы Сергей. Это не мое место, не мое обсуждение, и не моя тема.
Хотите продолжить, знаете где.

Ответ на »сообщение 2010« (Jack Of Shadows)
___________________________
>>>Вам не нужны доказательства. Вам нужно самоуспокоение. :))
А Вам в этом форуме что нужно?
Что функциональный подход ВСЕГДА лучше других мы не поверим.
Достаточно того, что в функциональные языки приходится вводить элементы императивности.
Но на вопрос КОГДА ИМЕННО функциональный подход лучше других Вы упорно отвечаете ВСЕГДА!
Это вызывает сомнение в Вашей компетентности в данном вопросе (не в функциональном программировании, боже упаси, а в вопросе границ его применимости).
В результате Вы отпугнете даже тех, кому может ФП - то, что доктор прописал.

Ответ на »сообщение 2011« (Илья Ермаков)
___________________________
Это маразм - ввести огромное количество мелких функций на все случаи жизни и затем превратить наглядный самодокументируемый код в более короткое, но неочевидное нагромождение вызовов.
Пострясающе :))) История повторяет сама себя в виде фарса. Где то я это уже слышал :)))

Ответ на »сообщение 2005« (Geniepro)
___________________________
В Обероне есть метапрограммирование, на уровне рантайма. Правда, библиотеки не стандартизированы.
Есть базовый тип для всех записей ANYREC и ANYPTR, можно выяснить реальный тип, поднять имена и значения всех полей и т.п.
С массивами обобщенно действительно сложно работать. В данном случае пришлось бы делать массив из указателей.
В Блэкбоксе, правда, есть специальный служебный тип SYSTEM.PTR - если процедура имеет параметр этого типа, то ее можно применять к любому динамическому объекту - POINTER TO RECORD и POINTER TO ARRAY. Далее можно поднять тип массива, тип его элементов и т.п. Так, например, реализовывается функция SetLength для массивов.
Однако прямого способа для этой цели нет. Иногда дженериков немного не хватает.

Однако в данном конкретном случае я не понимаю смысла огород городить - неужели ради того, чтобы заменить очевидное FOR i := 0 TO LEN (res) - 1 DO на Map(container, f)?
В первом случае совершенно очевидно, что делают три строчки кода.
Во втором случае мы получаем одну строчку, чтобы понять эффект которой, нам надо лезть к определению функции Map и читать документацию на нее.
Это маразм - ввести огромное количество мелких функций на все случаи жизни и затем превратить наглядный самодокументируемый код в более короткое, но неочевидное нагромождение вызовов.
Программист вместо написания программ тратит уйму времени на знакомство с фичами огромных библиотек, а через пару-другую месяцев не сможет реализовать двоичный поиск без наличия под руками готовой библиотеки с binary_sort и т.п.

Ответ на »сообщение 2004« (Снегурочка)
___________________________
Любой подобный пример демонстрирует потенциальную возможность использования ФП в данной области, но не эффективность... Бла бла бла.
Вам не нужны доказательства. Вам нужно самоуспокоение. :)) Чтобы не было обидно. Эпоха заканчивается.
Последние могикане спиваются. Так не хочется осознавать что то что ты считал лучшим на самом деле всего лишь конец каменного века.

Ответ на »сообщение 2007« (Jack Of Shadows)
___________________________

Однако теоретическая возможность не означает "в пределах возможности человека"

Значит, тут слегка перегнули палку. Для демонстрации достижимости достаточно примера. А для демонстрации недостижимости нужно доказательство. Раз с этим проблемы, все остальные слова, IMHO, просто эмоции.

Ответ на »сообщение 2001« (Jack Of Shadows)
___________________________
>>>Кстати общаетесь с СУБД вы тоже на ФЯ (SQL) :))
Ну еще бы. SQL-запрос представляет собой реализацию ОДНОЙ функции реляционной алгебры. Если тут не использовать ФП, то где же тогда.

>>>На Ерланге написана великолепная СУБД Mnesia
Тогда объясните постановочно, как свести типичные задачи СУБД к функциям.
На входе такой функции будет текущее состояние всей базы и некоторый запрос, на выходе новое состояние базы или результат запроса. И как построить такую функцию, учитывая, что данные впрямую недоступны, требуют буферизации и т.д.
Достаточно математической постановки - большинство тут поймет. Как раз запись на конкретном языке понята, скорее всего, не будет.

Ответ на »сообщение 2004« (Снегурочка)
___________________________
А где можно почитать теоретическое обоснование невозможности получения "надежности, недостижимой ни для одного императивного языка"?
А где можно почитать теоретическое обоснование невозможности написания ЛЮБОЙ программы на ассемблере ?
Однако теоретическая возможность не означает "в пределах возможности человека"
Теоретическое ограничение скорости движения скоростью света не означает что человек может двигаться со скоростью света.
Теоретическая возможность написания ЛЮБОЙ программы на ассемблере не означает что человек сможет написать эту любую программу на ассемблере.

Ограничением уровня надежности является потолок абстракции. Чем он выше, тем большей надежности может достигнуть человек до тех пор пока не стукнется в потолок.
Потолок абсракции в ФЯ гораздо выше чем в ИЯ. И вот вам результат.
Он подтверждается практикой - десятками лет разработки больших систем (в несколько миллион строк кода)
Императивные языки имели свой шанс доказать свои возможности много раз, и до сих пор не смогли преодолеть планку надежности которую сходу взял Erlang в своем первом же применении.