| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 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« (Илья Ермаков)
___________________________
Вопрос в том что вы считаете "элементарным" шагом. Для меня элементарный шаг - это операция заданная на формальном языке. Все остальные шаги, которые на этом формальной языке явно не заданы - в алгоритм не входят, а потому различия в компиляторах и оптимизациях формальный алгоритм не меняют.
Полностью согласен! Про то и речь.
Многократно здесь показывавшийся алгоритм сортировки на хаскеле имеет несколько четко прописанных шагов:
Выбрать из списка все обьекты меньше первого обьекта, отсортировать их по этому же алгоритму.
Добавить к полученному результату все обьекты из списка, равные первому обьекту.
Добавить к полученному результату (Выбрать из списка все обьекты больше первого обьекта, отсортировать их по этому же алгоритму).
Так мне кажется, что это как раз "остальные шаги, которые на формальном языке явно не заданы". На языке явно задано функциональное отношение, вычисление которого приводит к решению задачи. Для выполнения на физической императивной машине это отношение трансформируется в последовательность шагов - и выполняется. Потому что "физических вычислителей" для функций практически создано не было. Хотя можно себе представить, ну, например, аналоговую конструкцию на нейронных сетях, наученную сортировке небольших массивов - вычисляющую ту же самую функцию, но без "последовательности элементарных шагов"!
Разве от того что в этом алгоритме отсутствуют инструкции о том где хранить предварительные результаты, он уже превращается из алгоритма в "другой формализм" ?
Просто мы скатываемся до житейского понимания "алгоритм" как любое описание решения задачи. Хотя теоретически говорить "алгоритм машины Тьюринга" смысл имеет, а вот говорить "алгоритм лямбда-исчиления" - всё-таки нет. Неспроста даже алгорифмы Маркова продолжают называть алгорифмами - потому что это уже "не те" алгоритмы, а другой формализм, эквивалентный алгоритмам и функциям.
Хотя всё это, естественно, спор о словах - но ведь в словах мы думаем :-)
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
