Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 2182 23-03-2007 19:20 | |
Ответ на »сообщение 2176« (Jack Of Shadows)
___________________________
Вот тогда императивщикам придется туго. Надо будет переучиваться :))
у "императивщиков" для решения проблем, в частности, параллельного программирования и свой арсенал есть. Увы, мейнстрим не поднимается в абстрагировании выше уровня семафоров/критических секций/потоков - но это уже проблемы мейнстрима...
В паскалевском семействе та же Ada еще в 80-м предоставила превосходные, встроенные в язык средства параллельного программирования, и большинству языков в этом аспекте до нее семь верст сами знаете чем еще плыть :-)
А по поводу "переучиваться" - у меня такое острое очучение, что в ФП побегут в первую очередь цеплюсисты - ибо им, как всегда, собственных проблем решаемой задачи не хватает, нужно еще повоевать с "ветряными мельницами" наворотов языка :-) Ну, или наворотов, измысленных математиками-теоретиками в минуту праздного безделья :-)
№ 2181 23-03-2007 19:19 | |
Ответ на »сообщение 2179« (Булат Зиганшин)
___________________________
>>>ну пусть не все языки, но многие :)
Точнее сказать -- некоторые.
Такие языки называются модульными. :)
№ 2180 23-03-2007 19:14 | |
Ответ на »сообщение 2176« (Jack Of Shadows)
___________________________
IBM делает процессоры cells для Playstation 3, в которых работают несколько асинхронных ядер.
Это в корне отличается от обычной SMP архитектуры.
асинхронные - это как? может, асимметричные? в xbox 3-ядерный powerPC. в ps3 1нормальное ppc ядро, и ещё 8 упрощённых, чисто вычислительных, с 128к локальной памяти каждое. какие-нибуль научные расчёты на них пускать - самое милое дело. помните, как ps2 щапретили ввозить в россию, поскольку его мозность, 5.6 гфлопс, попала в диапазон, описывающий суперкмопьюетры? :)
№ 2179 23-03-2007 19:09 | |
Ответ на »сообщение 2178« (AVC)
___________________________
Вы говорите о независимой (independent) компиляции, а Руслан Богатырев -- о раздельной (separate).
Основное (но не единственное) различие -- в межмодульном контроле типов.
Кроме того, раздельная компиляция позволяет избегать перекомпиляции клиентов модуля (при условии сохранения или даже расширения интерфейса).
А отсюда один шаг до компонентного подхода.
ну пусть не все языки, но многие :) с тех пор, как наткнулись на проблемы с нею, придумали отделение интерфейса от реализации, что и позволяет реализовать контроль типов. что касается избегания перекомпиляции - с этим в ghc как-то не очень, хотя я подозреваю, что делов в том, что я экспортирую всё и сигнатур не пишу, в результате чего у меня интерфейсы меняются за милую душу. но при этом я хамечаю, что при включенной оптимизации перекомпиляция случается чаще - видимо, из-за кросс-модульного инлайнинга функций
№ 2178 23-03-2007 18:52 | |
Ответ на »сообщение 2175« (Булат Зиганшин)
___________________________
Ответ на »сообщение 144« (Руслан Богатырев)
___________________________
Какие языки ФП имеют концепцию модуля как средства для инкапсуляции программных сущностей и инструмента поддержки раздельной компиляции (separate compilation) -- отчуждение интерфейса модуля от его реализации и автономную компиляцию модуля на основе одних интерфейсов при отсутствии доступа к реализации импортируемых им модулей?
по-моему, все практические компилируемые языки, начиная с фортрана, поддерживают раздельную компиляцию - иначе далеко не уедешь. в ml какое-то особо мощное модулльное программирование - модули образуют так называемые функторы. что это такое, я так и удосужился разобраться, но судя по тому, что их сравнивают с type classes...
Вы говорите о независимой (independent) компиляции, а Руслан Богатырев -- о раздельной (separate).
Основное (но не единственное) различие -- в межмодульном контроле типов.
Кроме того, раздельная компиляция позволяет избегать перекомпиляции клиентов модуля (при условии сохранения или даже расширения интерфейса).
А отсюда один шаг до компонентного подхода.
№ 2177 23-03-2007 18:52 | |
Ответ на »сообщение 156« (info21)
___________________________
А возращать локальные функции -- в гробу хочется видеть такие штуки. Жизнь-то одна, и хочется че-нить реальное совершать, а не примеры для конкурса Obfuscated Lisp генерить.
а ведь объект - это как раз и есть данные вместе с привязанными к ним функциями :)
я на http://haskell.org/haskellwiki/IO_inside приводил несколько примеров возрастающей сложности, как вместо класса, реализующего ту или иную функциональность в ООП-овской парадигме, в хаскеле возвращаются просто те самые несколько функций, которые составляют функционал этого класса. чем это лучше? меньше писанины. чем хуже? нет наследования. т.е. фактически это АТД, а не ООП
вообще, ФП приучает к мышлению в стиле "какая функциональность нам здесь нужна?". т.е. если в ООП я ищу класс и к нему приляпываю данные и методы, то в ФП я ищу, какие действия нужно выполнять, и возвращаю непосредственно эти действия, оставляя переменные внутри процедуры, которая эти действия создаёт. ничего лишнего, никаких ненужных объявлений - только код, который непосредственно что-то делает
№ 2176 23-03-2007 18:40 | |
Булат переключился на начало списка :))
Если он продолжит в том же духе, нас ждет масса интересных коментариев.
Кстати по поводу нестандартной архитектуры компьютеров.
IBM делает процессоры cells для Playstation 3, в которых работают несколько асинхронных ядер.
Это в корне отличается от обычной SMP архитектуры.
И эти машины уже у нас дома. PS3 по моему продан уже в обьеме нескольких миллионов экземпляров.
Я думаю не за горами тот день когда мы увидми персоналки с асинхронными ядрами.
Вот тогда императивщикам придется туго. Надо будет переучиваться :))
№ 2175 23-03-2007 18:40 | |
Ответ на »сообщение 144« (Руслан Богатырев)
___________________________
Какие языки ФП имеют концепцию модуля как средства для инкапсуляции программных сущностей и инструмента поддержки раздельной компиляции (separate compilation) -- отчуждение интерфейса модуля от его реализации и автономную компиляцию модуля на основе одних интерфейсов при отсутствии доступа к реализации импортируемых им модулей?
по-моему, все практические компилируемые языки, начиная с фортрана, поддерживают раздельную компиляцию - иначе далеко не уедешь. в ml какое-то особо мощное модулльное программирование - модули образуют так называемые функторы. что это такое, я так и удосужился разобраться, но судя по тому, что их сравнивают с type classes...
№ 2174 23-03-2007 18:08 | |
Ответ на »сообщение 31« (Q. Werty)
___________________________
Проблема в другом. Функциональный подход не сможет полностью вытеснить императивный до тех пор, пока сама архитектура компьютера будет оставаться "императивной", т.е. фон-неймановской.
в свою очередь фон-неймановская архитектура была придумана отгадайте для чего?... для того, чтобы упростить программирование! :) один из первых компьютеров, созданный под руководстовм Тьюринга, имел возможность программировать все исполнительные устройства параллельно и независимо, а данными управлять так, чтобы они приходили на исполнительные устройства just-in-time. в результате чего он работал в 6 раз быстрее (по сравнению с самим собой, работающим в "фон-неймановском" режиме), но его программирование превращалось в настоящий вызов для программистов :))
и это в те времена, когда не было даже ассемблеров. Тьюринг блестяще решил некую теоретическую задачу, держа в уме, что оптимальную программу для компьютера может составить сам компьютер - вот только несколько опередил своё время
современные же компьютеры имеют отнюдь не фон-неймановскую микро-архитектуру. они *супер-скалярны* и только из-за проблем совместимости вынуждены эмулировать фон-неймановскую архитектуру, которая тянется как минимум со времён 8080. была подвижка с vliw-процессором itanium, но её благополучно закатала под асфальт amd :))
тем не менее, экспериментальные процессоры, управляемые данными, существовали. представь себе - есть куча исполнительных блоков. есть очередь заданий на вычисление - скажем вычислить x+y и поместить результат в z, затем a+b->c и z*c->t. задания из этой очереди расхватываются исполняемыми устройствами и выполняются в порядке, опредлеляемом их зависимостями *по данным*. в остальном же выполнение порграммы идёт асинхронно. фактически именно так сейчас и исполняются МОПыб в которые превращаются внутри процессора старые добрые x86 инструкции
добавь к эому параллелизм на уровне ядер (число которых intel обещает к концу десятилетия довести до 80 и вообще говорит, что теперь закон Мура будет работать в отношении числа ядер). не забудь ещё hyperthreading, хотя он наверно останется в основном для серверных процов; кстати уже продающийся sun t1 имеет не то 8 ядер по 4 треда, не то наоборот
или скажем CUDA - это когда на обычной nvidia-евской видеокарте запускают мат. вычисления. используя до 128 "ядер", которые там имеются.
или - слышали про google mapReduce? идея из функционального программирования, которая используется google для построения из тысяч компьютеров кластера, "суперкомпьютера", просеивающего гигабайты информации в секунду. между прочим, отсутствие состояния здесь существенно используется - оно позволяет перезапустиь любую часть вычисления заново, если её результаты были потеряны из-за сбоев в компьютерах
так что функциональный подход хорош для обработки данных, и современные комптютерные архитектуры вынуждены рещать проблему прямо противоположную имевшейся 60 лет назад - не как извратить *аппаратные* средства, чтобы программисту было проще программировать в машинном коде, а какие дать средства *программисту*, чтобы пришлось как можно меньше извращать аппаратуру от уровня естественного схемного параллелизма
№ 2173 23-03-2007 17:23 | |
Ответ на »сообщение 2172« (Jack Of Shadows)
_________________________
Кстати, почему delphikingdom ? Насколько я понял ты к дельфям никакого отношения не имеешь.
geniepro в жж ссылку кинул на задачку ACM. а к дельфи я действительно отношения никакого не имею, кроме того, что с 98-го его на хлеб намазываю :)))
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|