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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 3332—3323 | 3322—3313 | 3312—3303 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 219


    № 3322   07-10-2007 04:13 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3320« (Geniepro)
    ___________________________

    Ответ на »сообщение 3281« (Илья Ермаков)
    ___________________________
    А Вы уверены, что Вы - не машина?
    Почему Вы так уверены в том, что компьютеры никогда не станут настолько сложными (сравнимыми по сложности с Вашим мозгом), что не научатся самообучаться и думать в конце концов?

    Уверен - не уверен - это вопрос субъективный :-)
    А вот, к примеру, теоремы Гёделя о неполносте формальных систем - это для информатики всё равно, что начала термодинамики - приравнивающие ИИ к вечному двигателю :-)


    № 3321   07-10-2007 04:01 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3280« (Руслан Богатырев)
    ___________________________

    Маленькая ремарка: распараллеливание не имеет жесткой привязки к декларативу. Распараллеливать автоматически можно и императив.

    Да, конечно, но с какой эффективностью? Я уже давно упоминал про параллельный чистый ФЯ SISAL, в котором программы распараллеливались настолько хорошо, что были в три-четыре раза быстрее аналогичных на Си и Фортране, распараллеленных и оптимизированных вручную. При этом, программа с SISAL'а переводилась в промежуточный код на Си и транслировалась затем стандартным компилятором Си...


    № 3320   07-10-2007 03:56 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3281« (Илья Ермаков)
    ___________________________

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

    А Вы уверены, что Вы - не машина?
    Почему Вы так уверены в том, что компьютеры никогда не станут настолько сложными (сравнимыми по сложности с Вашим мозгом), что не научатся самообучаться и думать в конце концов?


    № 3319   07-10-2007 03:56 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3293« (Сергей Перовский)
    ___________________________

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

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


    № 3318   07-10-2007 03:36 Ответить на это сообщение Ответить на это сообщение с цитированием
    >>> Формально замкнутый императивный язык - это уже другой коленкор, и тут есть над чем подумать :-)

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

    Основное отличие - интерактивность, как критерий чистоты - грязи задачи.
    Видимо, недаром среда ББ весьма интерактивна, а для Лиспа сред практически нет.
    Allegro CL, ввиду цены, видимо тоже "штаны через голову".


    № 3317   07-10-2007 03:26 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3314« (Илья Ермаков)
    ___________________________
    Так для Сей даже автоматическое управление памятью организовать не получалось - и до Оберона считалось, что это прерогатива интерпретируемых ФЯ :-)

    Простите, как это "до оберона" ? Что до оберона не было ни Лиспа ни Smaltalk которые прекрасно компилировались, и при этом имели сборщик мусора ?
    Далее, java, в которой нет сишных указателей, и система типов вполне даже "герметичная", не вчера появилась, а почти 20 лет назад. И где автоматическое распараллеливание ?
    Где оно для Ада или Eiffel ?
    Вы слишком недооцениваете трудности распараллеливания в среде с неконтролируемым изменением памяти (многократное присваивание). Все рабты которые до сих пор велись и ведутся в этом направлении, называют камнем преткновения именно эту проблему. И все решения до сих пор найденные, необходимым условием успешного распараллеливания называют именно отказ от присваивания. Система типов ни у кого проблем не вызывает.
    Слава богу на сях не работаем уже давно.


    № 3316   07-10-2007 03:21 Ответить на это сообщение Ответить на это сообщение с цитированием
    >>> переменные могут иметь только однократное присваивание.
    Если буквально - переменные будут константами.

    Так же и "однократное присваивание" на самом деле не "однократное присваивание".
    И в рекурсии ячейки перемолачивают байты по многу раз. И в ФЯ.
    Внутри чистой по ФЯ программы не программист решает когда и что присвоить.
    Машина сама решает когда и что присвоить, перегнать.
    Только вход и выход даются в руки.
    В этом смысле и такое вольное понимание однократного присваивания.
    Оно от ввода и декларатива.
    В императиве мы машину ведём за ручку алгоритмом.
    Поэтому трудности с распараллеливанием.
    Предположим, машина будет код внутри себя переделывать по своему усмотрению.
    В контексте обсуждения, например, распараллеливать.
    Но тогда это получается ФП, а не ИП.

    Другое дело, если в ходе решения человек корректирует ход решения.
    Тут дело кардинально усложняется.
    Задача становится не чистой.
    Влезают грязные руки исследователя :)
    Задействовано серое вещество homo sapiens'а.

    Но вот программист решает день за днем чистые задачи.
    У него начинается головокружение от успехов.
    Появляется снисходительный тон к решателям грязных задач :)


    № 3315   07-10-2007 03:19 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3273« (Geniepro)
    ___________________________

    Как обычно, хорошая мысля приходит опосля...

    foldr1 (+) bs можно смело заменить на sum bs
    foldr (+) b $ snd $ unzip eqs заменяется на b + (sum $ snd $ unzip eqs) хотя тут выигрыш уже незаметен...


    № 3314   07-10-2007 02:41 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3307« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 3304« (Руслан Богатырев)
    ___________________________
    Ну а мы так же как и французкая академия, опираемся на реальность бытия. Нет в повседневной жизни вечных машин, равно как и нет в повседневном программировании автоматического распараллеливания императивщины.

    Первым препятствием для этого является не присутствие присваивания и глобального состояния на уровне формального языка (потому что это, как мне кажется, не является препятствием для автоматического распараллеливания, хотя в случаях конкретного кода может оказываться тормозом для эффективного распараллеливания - ну, из той же оперы, как сейчас учёт работы кэша - практически эквивалентная конструкция на ЯВУ может либо попадать, либо не попадать целиком в кэш - и от этого производительность меняться в десятки раз). Так вот, первым препятствием для этого является негерметичность системы типов большинства языков, активно использующихся до сих пор на практике - потому что фактически программист из любого места программы может иметь доступ к любой точке памяти (вот оно - дикое и необузданное глобальное состояние, да не уровне формального языка, а на уровне "дыр в трюмы") - и никакой распараллелизатор не в состоянии отследить обращение к памяти через переменную типа float, в которую программист засунул адрес :-) Потому что формальный язык с его конструкциями оказывается не замкнут - тем самым ставится крест на возможности формального анализа программ. Формально замкнутый императивный язык - это уже другой коленкор, и тут есть над чем подумать :-) Просто не так давно такие языки вошли в жизнь, и ещё особо не думали... Да ещё функциональщики всех пугают - "нельзя, ни у кого не получалось!" :-) Так для Сей даже автоматическое управление памятью организовать не получалось - и до Оберона считалось, что это прерогатива интерпретируемых ФЯ :-)


    № 3313   07-10-2007 02:27 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3305« (Jack Of Shadows)
    ___________________________

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

    Полностью согласен! Про то и речь.



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

    Так мне кажется, что это как раз "остальные шаги, которые на формальном языке явно не заданы". На языке явно задано функциональное отношение, вычисление которого приводит к решению задачи. Для выполнения на физической императивной машине это отношение трансформируется в последовательность шагов - и выполняется. Потому что "физических вычислителей" для функций практически создано не было. Хотя можно себе представить, ну, например, аналоговую конструкцию на нейронных сетях, наученную сортировке небольших массивов - вычисляющую ту же самую функцию, но без "последовательности элементарных шагов"!



    Разве от того что в этом алгоритме отсутствуют инструкции о том где хранить предварительные результаты, он уже превращается из алгоритма в "другой формализм" ?

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


    <<<... | 3332—3323 | 3322—3313 | 3312—3303 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 219


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

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

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

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

    Перейти на конкретную страницу по номеру
      
    Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

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