Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  21:31[Войти] | [Зарегистрироваться]
Обсуждение темы:
Функциональное программирование

Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.

Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.

Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.

 Jack Of Shadows

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 5502 сообщения

Добавить свое сообщение

Отслеживать это обсуждение


Смотрите также обсуждения:
Средства разработки. Языки программирования.
  • Delphi 4 or Delphi 5
  • Что приобрести в качестве средства разработки?
  • Delphi6
  • Delphi vs PowerBuilder
  • Сравнение компиляторов
  • Вот и вышла Delphi 7... Вы рады?

  • <<<... | 312—303 | 302—293 | 292—283 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 521


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

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

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


    № 301   20-06-2006 16:55 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 300« (info21)
    ___________________________

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


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

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

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

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



    № 300   20-06-2006 16:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 282« ()
    ___________________________

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


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


    № 299   20-06-2006 16:02 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 296« ()
    ___________________________

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

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

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


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

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




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


    № 297   20-06-2006 15:46 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 293« (hugi)
    ___________________________
    Я не вижу никаких принципиальных удобств/неудобств использования/неиспользования рекурсии/цикла в ИЯ/ФЯ.

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


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


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

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

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

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

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

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

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


    № 296   20-06-2006 15:19 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 288« (hugi)
    ___________________________
    Ещё раз прошу Вас подписывать свои сообщения.
    ?

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

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

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

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

    Я имею в виду воплощение прямого "постулата" Лиспа о неразличимости формы записей списка элементов и вызова функции? (Это важно, это - не просто каприз на счёт синтаксиса...)
    А я, кстати, так и не понял, почему это важно? Не могли бы доходчиво объяснить?

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

    К тому, что накропать набор основных функций работы с множествами можно и на ассемблере.
    Ещё бы. А на чём их интересно МакКарти реализовывал как не на ассемблере?

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


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


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

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

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

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

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

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


    № 295   20-06-2006 15:18 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 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.

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


    № 294   20-06-2006 15:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 292« (Jack Of Shadows)
    ___________________________
    Да ладно Вам! Практическая применимость этого такая же, как и в Лиспе!
     hugi


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


    <<<... | 312—303 | 302—293 | 292—283 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 521


    Добавить свое сообщение

    Отслеживать это обсуждение

    Дополнительная навигация:
    Количество сообщений на странице

    Порядок сортировки сообщений
    Новое сообщение вверху списка (сетевая хронология)
    Первое сообщение вверху списка (обычная хронология)

    Перейти на конкретную страницу по номеру
      
    Время на сайте: GMT минус 5 часов

    Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
    Функция может не работать в некоторых версиях броузеров.

    Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
    Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

     
    © При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

    Яндекс цитирования