Ответ на »сообщение 280« (hugi)
___________________________
Вы всё ещё намерены утверждать, что при рекурсии больших списков в ИЯ, программа просто сдохнет из за элементарного пепеполнения стека, или признаете, что этого не произойдёт?

Оба на! А вот это я пропустил. Вы путаете уважаемый. Теоретическая возможность рекурсии не имеет в данном случае никакого значения. Состояние каждой функции временно запонимается в стеке, для того чтобы после возврата из вызванной функции продолжать вычисления. Если у вас несколько десятков тысяч вложенных друг в друга функций (то есть рекурсия) то стек переполнится и программа сдохнет.

Вы ничего не доказали. Возьмите свой собственный пример и прогоните его с большим списком. 100,000 записей с головой хватит. Потом будете говорить о том что вы там доказали. :))

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

причина очевидна -- эффективность.
...
что эмулируют просто автоматическое управление памятью, 

Contradiction of interests как говорится.
Вы совершенно правы.
В ФЯ особенно экономить нет смысла, потому что изначально присутсвует сбощик мусора. Да и функциональная парадигма ест памяти немерянно. В таких условиях экономить на специфических типах, все равно что вычерпывать воду ложкой из тонущей лодки.

А вот в ИЯ изначально сбощика мусора не было. Тут был смысл экономить на всем.
Все эти специфические конструкции, arrays, structs, int, int32, real, double, AnsiString, WideString, все это вводилось в язык чтобы экономить каждый байтик памяти.

Однако дальше произошло нечто странное. В ИЯ ввели автоматическое управление памятью. Ввели сбощик мусора.
И получилась такая странная конструкция. Язык, заточенный под экономию памяти, при этом поедающий эту память тоннами (сборщик мусора).
И теперь глядя на java или dotnet, в которых есть такие эффективные с точки зрения используемой памяти конструкции как array (по сравнению со списком) странно видеть как эта "эффективная" программа при запуске сьедает несколько десятком мб оперативки. За что боролись спрашивается ? :)) За что страдали ?

Самое интересное - за что ПРОДОЛЖАЕТЕ страдать ?

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

Ответ на »сообщение 277« (hugi)
___________________________
... постепенно все программисты приходят к тому, что начинают в своих программах эмулировать лисп-программы... ;)

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

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

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

И я уже писал, что в отличие от ФЯ, в ИЯ список не является чем-то особенным, он один из многих, многих, многих...

Не поразмышляете ли для всех нас вслух, по какой причине, вам в языке нужны все эти «многие, многие, многие...», ДАЖЕ, в случае, когда вы не занимаетесь уж ОЧЕНЬ низкоуровневым программированием? ;)

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

Можно вспомнить, что даже комплексные числа трудно включить в язык так, чтобы совсем исключить необходимость покомпонентной работы -- подразумевается, без потери эффективности. Даже для квази-простых списков разнообразие возможных вариаций, возможно, и больше, чем для комплексных чисел.

О, нашел еще одну рекурсию в своем ИЯ коде! На этот раз в javascript.
Создание treeview в html. Тоже как видите обработка деревьев.
Похоже это единственная задача для которой применение рекурсии оправдано в ИЯ.

Ответ на »сообщение 293« (hugi)
___________________________
Я не вижу никаких принципиальных удобств/неудобств использования/неиспользования рекурсии/цикла в ИЯ/ФЯ.

И именно поэтому рекурсией в повседневной практике вы не пользуетесь ? Гениально ! :))


Да ладно Вам! Практическая применимость этого такая же, как и в Лиспе!


В который раз на вопрос о практической применимости слышится в ответ ничем не подтвержденное заявление.
Давайте сделаем так. У вас я полагаю достаточно большое количество кода написано. И огромное количество циклических алгоритмов. Просмотрите свой код, и посмотрите в скольких случаях вы использовали рекурсию, а в скольких - цикл. Это будет лучшим доказательством практичности-непрактичности рекурсии в ИЯ.

Я вам сразу скажу в моем дельфи-java-сишарп коде рекурсии практически нет.
Единственный случай в котором я использую рекурсию в ИЯ это обработка деревьев. (Создание Table of Contents для генерируемых pdf файлов.) Да и то только потому что делать это в цикле - можно в психушку попасть из за  нервного срыва.

Однако в том же лиспе рекурсия у меня встречается в каждом файле.

Идем дальше. Возьмите любые open-source библиотеки. Миллионы и миллионы строк кода.
Посмотрите там.
Я пользуюсь довольно большим количеством сторонних лисп библиотек.
Рекурсия в ЛЮБОЙ из них - обычный и широко-распространенный механизм.

А теперь посмотрите на код библиотек в ИЯ.
Вернетесь, и расскажите нам как вы не видите "никаких принципиальных удобств/неудобств использования/неиспользования рекурсии/цикла в ИЯ/ФЯ." :)))

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

Нехилые у вас программисты! Инерции мышления ноль! Сходу "почувствовать" и переориентироваться. Супермены какие то. :)))

Ответ на »сообщение 288« (hugi)
___________________________
Ещё раз прошу Вас подписывать свои сообщения.
?

Вы, я смотрю не очень то утруждали себя изучением моего кода
Именно изучением – нет. Просмотрел и сразу обратил внимание на отрывок, где вы строите список и суммируете его.

Разумеется, элемент списка и информационную часть элемента списка приходится различать. Это ограничение языка.
Именно.

И я уже писал, что в отличие от ФЯ, в ИЯ список не является чем-то особенным, он один из многих, многих, многих...
Не поразмышляете ли для всех нас вслух, по какой причине, вам в языке нужны все эти «многие, многие, многие...», ДАЖЕ, в случае, когда вы не занимаетесь уж ОЧЕНЬ низкоуровневым программированием? ;)

И отношения к списку в ФЯ и ИЯ соответственно разные.
Да. В ИЯ список – это ещё один из «многих, многих, многих...», для которого нужно помнить свои правила обращения с ним и всячески его холить, лелеять и растить (по мере создания обслуживающего его кода). А в ФЯ – это способ реализации базисных идей языка, заложенный в основу исполняющей системы. Прочувствуйте разницу.

Я имею в виду воплощение прямого "постулата" Лиспа о неразличимости формы записей списка элементов и вызова функции? (Это важно, это - не просто каприз на счёт синтаксиса...)
А я, кстати, так и не понял, почему это важно? Не могли бы доходчиво объяснить?
Фу, господи, вы не читаете предыдущих постов?
Уже ж не один раз писали, что это даёт неограниченную возможность модификации и создания новой формы записи. Программы могут обрабатывать и изменять другие программы. Не в смысле вирусов, а как данные. Вы можете при трансляции проинтерпретировать сформированные данные, как програму (и наоборот) и выполнить её. Это – то, что и называют программированием, управляемым данными. Практическое применение этого свойства в том, например, что вы можете определять новые формы записи. В случае с вашим примером – вы. На самом деле не имеете «многих, многих, многих...», выраженных соответствующими формами записи в языке. Вы продолжаете работать с теми же самыми формами и правилами записи Явы. Вы у себя в голове вынуждены держать смысл операций. Где-то вам помогают названия операций. Но - и всё. В Лиспе же, вы можете расширять даже структуру языка. Таким образом, сама форма записи помогает, «наталкивает» на смысл записи. Более того, структура записи текстов может подсказывать структуру обрабатываемых объектов.
Обыкновенные языки – замкнуты, не расширяемы.
В Обыкновенных языках вы наращиваете библиотеки, но не изменяете природу окружения, среды, из использующих. А в Лиспе, вы можете изменять всё, вплоть до синтаксических правил записи случаев использования таких «библиотек». Конечно, это – крайний вариант. А то опять кто-то будет говорить, что «видал он в гробу» такие языки... С привычками из ИЯ – СОГЛАСЕН.

К тому, что накропать набор основных функций работы с множествами можно и на ассемблере.
Ещё бы. А на чём их интересно МакКарти реализовывал как не на ассемблере?
МакКарти СОЗДАВАЛ ФОРМАЛИЗМ. Причём с заложенной возможностью безграничной трансформаций. Вы же создали «ещё одну» библиотеку в рамках замкнутого, не расширяемого ни в каких смыслах формализма, не учитывающую природу и способы использования объектов описанной вами предметной области.


Что Вы понимаете под объектом списка? Если атом, т.е. информационная составляющая элемента, естественно, не тождественна элементу списка.
Атом – НЕ «информационная составляющая» элемента. Напоминаю, что элементом списка может быть список... ;)


элементы никак в операциях, посроенных на основе базисных, не фигурируют.
?

Операция head() возвращает атом.
А как вы, на месте пользователя, это определите? ;)

Возможно, единственным напоминанием об элементах является неудачное название класса списка FPListItem, но отбросьте слово Item и всё ОК!
Не, мне так не нравится. Когда заговаривают об изменении названия класса объектов – значит система понятий предметной области «плывёт». Вы сначала выделите все роли и признаки этого объекта, а потом решите, как вы его обобщённо называть будете, хорошо?... ;)

Да, похоже я не ошибся относительно того, что код Вы не изучили.
Не ошиблись. Не видел необходимости именно «изучать»... ;)

Там всё есть.
Вы ошибаетесь. Там НИЧЕГО НЕТ из того о чём мы тут говорим на протяжении уже 300 постингов. ;)

Повторю, в классе FP реализованы три базисные операции join(), head(), tail().
Мы говорим, просто о создании ещё одного вида контейнера данных на конкретном ИЯ или об иллюстрации возможности поддержки ИДЕОЛОГИИ, заложенной в основу Лиспа? ;)

Ответ на »сообщение 286« (Jack Of Shadows)
___________________________
Называется "Десятое правило Гринспена"
Точно! Спасибо.

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Все это, кто осмысленно, кто «по наитию» осознают. Но на рынке - гегемония императивных языков. Соответственно, пытаются «улучшить», то, что имеют. Всё направлено на «декларатизацию» форм записи задач и намерений... Другое дело, что процесс ввода дополнительных «фич» продирается сквозь несовместимость с императивной природой базовых выбранных языковых средств...

Ответ на »сообщение 292« (Jack Of Shadows)
___________________________
Да ладно Вам! Практическая применимость этого такая же, как и в Лиспе!

Ответ на »сообщение 290« (Jack Of Shadows)
___________________________
Да, поражения признавать тяжело. Для всех. Я рад, что Вы умеете это делать. Я тоже стараюсь. Прсто сейчас немного другая ситуация.
Понимаете, я не вижу принципиальных отличий рекурсии в ФЯ и ИЯ. И даже синтаксически всё очень похоже. Поэтому убеждения, что рекурсию в ИЯ применять неудобно, я не раздляю. С фЯ другая ситуация. Если мы берём чистый ФЯ, то там циклов нет. В Лиспе они есть, и Вы сами говорили, что начинающие Лисп-программисты, используют только их в первое время. Стали бы  они это делать, если бы рекурсия была настолько более удобна, я думаю они бы сразу это почувствовали и забросили свои циклы. Хотя, повторюсь в ФЯ всё несколько иначе, чем в ИЯ. Это связано с выделенностью структуры "список" и изначального посыла по технике работы с ним в виде трёх базисных операций.
Ещё раз. Я не вижу никаких принципиальных удобств/неудобств использования/неиспользования рекурсии/цикла в ИЯ/ФЯ. И язык не заставляет Вас использовать ни то ни другое (если не брать во внимание чистые ФЯ языки), он призывает, но не принуждает решать задачи характерным (более органичным) для него способом.
Вот моя позиция. Нежелание признавать поражение тут ни при чём.