| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 2392 31-03-2007 18:57 |   |
Ответ на »сообщение 2388« (Geniepro)
___________________________
Ну извините, это уж от Вас зависит, как Вы это всё проделаете, как построите программу.
Будете использовать абстрактные типы данных - будет проще, не будете использовать их - сложнее... Будете максимально абстрагировать задачу или не будете...
Вопрос был не в том, собираюсь ли я использовать АТД или нет. :)
Собираюсь, естественно, там где буду чувствать потребность.
Вопрос был в другом.
Вот создал я АТД, а он должен торчать "кишками наружу", чтобы выдержать принципы ФП.
Допустим, от многих неприятностей меня функциональность как раз и защитит (не даст модифицировать мои структуры данных).
Но что будет, если мне потребуется изменить эти структуры?
В модульном и объектно-ориентированном программировании здесь нет никаких проблем (да-да, то самое сокрытие информации), но там структура данных не всплывает наверх, в отличие от ФП.
| № 2391 31-03-2007 18:48 | |
Ответ на »сообщение 2384« (Руслан Богатырев)
___________________________
Для школ идеальны языки с минимумом синтаксиса и маскимумом приближения к школьной математике.
Например?
Ну, для меня пример очевиден - Хаскелл с его рафинированным синтаксисом и незаставлянием думать о лишних деталях, неважных на уроках информатики. :о))
Впрочем, гибридные языки, такие как Питон и Scheme - тоже весьма подойдут...
Неужели Вы действительно думаете, что решать типичные школьные задачки на Обероне легче, проще и быстрее, чем на этих трёх языках?
Зачем требовать от школьников инженерных подходов к программированию? Всё равно мало кто из них захочет стать в будущем программистами, так зачем зря отпугивать? Пусть хоть что-то поймут, простейшие алгоритмы математические научатся реализовывать без лишней головной боли...
Конечно, не нужно их грузить теорией категорий, но уж что проще, чем объяснить математические рекурсивные функции?
Так вот, Оберон -- это упрощенный Паскаль.
Да, с точки зрения имеющихся в наличии учителей - Оберон, пожалуй, лучший выбор, потому что знаком по Паскалю.
А вот с ФЯ наши учителя практически незнакомы, увы... Их самих учить надо... :о(
Друзья-товарищи-господа-коллеги! Давайте определимся, что мы обсуждаем: ФП или конкретно Хаскель? Если ФП, то давайте остановимся на конкретной эталонной книге (ее кстати уже рекомендовали) и относительно нее будем плясать. Так можно ее уже изучать или погодить из-за того, что "просроченная"?
Эх, не устану повторять, что Хаскелл - эталонный ФЯ... :о))
Впрочем, эталон, как и идеал, понятие субъективное...
А что насчёт книги - боюсь, ни одна книга не сможет охватить полностью всё многообразие как ИП, так и ФП...
Но мне кажется, что книга Филда и Харрисона очень неплоха. Ну а по новым течениям в ФП придётся изучать дополнительную литературу...
| № 2390 31-03-2007 18:42 | |
Ответ на »сообщение 2260« (Geniepro)
___________________________
Лямбда-абстракции (безымянные/анонимные функции) - это очень важный элемент ФП, который напрочь отсутствует в Оберонах. Без этого элемента язык не может считаться функциональным.
Почему?
Функции как объекты первого класса - функции можно не только вызывать, принимать как значения (по имени/ссылке), но и создавать и возвращать в качестве результата.
В Оберонах процедуры не являются объектами первого класса, поскольку в нём нет лямбд, нельзя возвращать локальные процедуры в качестве результата.
Разве Оберон (или др. ИЯ) обязан подражать ФП во всех деталях реализации?
Вместо локальной процедуры вполне можно вернуть объект с функцией (функтор, объект-функцию).
В Си++, особенно в обобщенном программировании, вместо функции очень часто используется функтор.
А ведь в Си++ тоже нельзя вернуть вложенную процедуру (их там нет).
Сопоставление по образцу (pattern matching) - очень модный аттрибут современных ФЯ и некоторых гибридных языков.
Причем здесь ФЯ?
Например, паттерн-матчинг применяется как в генераторе лексических сканеров lex (строящем конечный автомат), так и в скриптовом языке AWK.
Определители/генераторы списков/массивов (list/array comprehensions) - позволяет в очень удобной декларативной манере задавать содержимое списков или массивов.
В Оберонах для этого придётся создавать отдельные процедуры или циклы (что уже противоречит духу ФП).
Если содержимое массива можно задать в "удобной декларативной манере" (т.е. не надо перечислять все элементы, а есть некая система), то и в императивной большого труда не составит.
Это из области синтаксического сахара.
Не стану сейчас разбирать все пункты.
Кортежи (tuples) - чертовски удобны в использовании, так как освобождают от необходимости создавать лишние типы данных.
В Оберонах есть зачатки кортежей - это списки параметров процедур. То есть каждая процедура с параметрами в Оберонах фактически имеют один-единственный параметр - кортёж.
Так почему же нельзя сделать кортежи в Оберонах объектами первого класса? Почему нельзя возвращать кортежи в качестве результата? Вместо этого приходится плодить ненужные обёртки (записи новых типов) или вообще переходить к императиву - глобальным изменяемым объектам или к VAR-OUT-параметрам...
Опять же, предрассудок, что Оберон должен делать все так же, как ФЯ.
Между тем, кортежи в Обероне есть -- это записи-параметры.
На их использовании основана работа часто упоминаемой в обероновской ветке software bus.
Запись можно передать в качестве аргумента, можно вернуть в качестве результата.
Оптимизация хвостовой рекурсии в Оберонах отсутствует, но это является недостатком не языка, а его имеющихся трансляторов. Тем не менее, учитывая запрет на использование циклов, этот недостаток сильно ограничивает создание циклических расчётов, поскольку приводит к быстрой перегрузке стека.
Виноваты, просто руки не дошли. :)
Ведь в Обероне используются циклы, поэтому до оптимизации хвостовой рекурсии не дошло.
Но можно и "докрутить". :)
Собственно и в ФЯ этого не было до Схемы.
Могу выделить два пункта.
1) Большая любовь к синтаксическому сахару (что для ФЯ, возможно, необходимость).
2) Уверенность, что Оберон должен реализовывать некую функциональность так же, как ФЯ. Поэтому просто выпадает из зрения тот факт, что он эту функциональность реализует по-другому.
| № 2389 31-03-2007 18:26 | |
Ответ на »сообщение 2388« (Geniepro)
___________________________
Ну а почему бы не Хаскелл, раз уж он является "квинтэссенцией" ФП, как Оберон - ФЯ...
Упс! Имелось в виду, конечно же, что Оберон - квинтэссенция ИП... :о))
| № 2388 31-03-2007 18:23 | |
Ответ на »сообщение 2383« (AVC)
___________________________
IMHO, не все, чего нет в Обероне, относится к ФП.
Уточните, что куда по-Вашему относится.
(а список явно напирает на то, чего в Обероне нет).
Список был составлен исходя из вопроса Руслана Богатырёва, захотевшего узнать, чего нет в Обероне, что должно быть для полного функционального "щастья".
Ну какая принципиальная разница, именована функция или нет, если ее имени не видно за пределами модуля?
Почему, собственно, без анонимных функций нет ФП?
Ну, вообще-то такой уж принципиальной разницы, пожалуй нет. Если и есть, то скорее для динамических языков.
Просто вопрос удобства. Зачем нужно имя временному объекту с минимальной областью видимости?
Я просто хочу видеть, как именно выглядят эти "глобальные" структуры данных в ФП, как они соединяются в одно целое.
Что, например, будет, если я захочу поменять представление данных в каком-то месте программы?
Во что это выльется?
Ну извините, это уж от Вас зависит, как Вы это всё проделаете, как построите программу.
Будете использовать абстрактные типы данных - будет проще, не будете использовать их - сложнее... Будете максимально абстрагировать задачу или не будете...
А в чем разница для остальной части программы?
Какая ей разница, поместили Вы датчик внутрь монады или просто используете локальную переменную?
Особой разницы, пожалуй и нет, просто вопрос принципа - в чистых ФЯ приходится делать так, что бы сохранить чистоту... Монады ввода-вывода, уникальные типы... Одним словом, запрет на доступ снаружи и на переходы назад в цепочке операторов...
Если использовать изменяемые локальные переменные и при этом запретить операторы циклов и условных/безусловных переходов - то Вы получите фактически имитацию монады ввода-вывода, в некотором роде... Конечно, имитация монад будет частичной, далеко не полной.
Вообще, складывается впечатление, что до Хаскеля ФП не существовало, т.к. Вы все время переводите разговор на Хаскель.
Ну а почему бы не Хаскелл, раз уж он является "квинтэссенцией" ФП, как Оберон - ФЯ...
(Просто другие ФЯ я знаю ещё хуже, чем Хаскелл :о)))
| № 2387 31-03-2007 17:57 | |
Ответ на »сообщение 2374« (Илья Ермаков)
___________________________
И чем больше работаю, тем больше "душа поет".
Рад за Вас! :о) Честно говоря, не понимаю, как от Оберона может "душа петь", но Вы, надеюсь, поймёте, что и от Хаскелла "душа может петь" не меньше! :о))
Киньте ссылочку, плиз. Это что-то из ряда вон, даже интересно стало :-) Если учитывать известное качество мат. подготовки в американской школе, то я просто не представляю, как им удалось втиснуть туда ФП...
И я, и Jack Of Shadows уже приводили такие ссылки. Правда, не совсем про американские школы... Вообще, я не в курсе американских школьных программ, есть ли там уроки по информатике...
Самый известный пример: проект "TeachScheme!"
Правда, не смогли удержаться от коммерциализации - в конце обучения переходят на Java...
(Эх, Джек опять опередил! :о))
Менее известная работа, которую я тут недавно приводил:
"The Pros and Cons of Teaching Purely Functional Programming in First Year"
Manuel M. T. Chakravarty & Gabriele Keller
Пример Оксфорда и MIT Вас, похоже, не впечатляет, а жаль...
Однако я все же заметил, что для некоторых особенно критичных модулей системы можно использовать ручное управление.
Вообще-то Вы сказали - "приходится"...
А в чём, собственно говоря, проблема у ФП в жёстком РВ? Только в том, что Вам об этом не так много известно, как об Оберонах в жёстком РВ?
Пример ОС РВ, написанной на языке Timber, основанном на Хаскелле.
M. Wallace "Functional Programming and Embedded Systems"
Учитывая, что тут описываются встраиваемые системы - это такое же ЖРВ, что и в случае с Оберонами...
Область систем промышленной автоматики - это отнюдь не узенькая, а очень широкая область, актуальная для любого современного промышленного предприятия.
Да я понимаю. Я бы и сам с радостью использовал Оберон или Модулу-2 в своих микроконтроллерных разработках, да только нет трансляторов, вот и приходится на Сях работать...
А я бы не стал перенапрягать их моск нюансами каррирования функций...
А какие там есть непонятные нюансы? Я кроме удобства в этом ничего больше не вижу...
| № 2386 31-03-2007 17:46 | |
Ответ на »сообщение 2372« (Geniepro)
___________________________
Это отличная книга - классика! НО! Эта книга не есть истина в последней инстанции!
Друзья-товарищи-господа-коллеги! Давайте определимся, что мы обсуждаем: ФП или конкретно Хаскель? Если ФП, то давайте остановимся на конкретной эталонной книге (ее кстати уже рекомендовали) и относительно нее будем плясать. Так можно ее уже изучать или погодить из-за того, что "просроченная"?
| № 2385 31-03-2007 17:42 | |
Ответ на »сообщение 2371« (Geniepro)
___________________________
Да ещё заставлять бедных школьников перенапрягать свой бедный моск всеми хитростями и премудростями "грамотного проектирования фабрик объектов на Обероне"?
Странное какое-то передергивание. Оберон -- это упрощенный Паскаль (если брать то, что разумеют под этим словом в школах -- это не классический Паскаль 1970 г., не Паскаль 1972 г., не ISO Pascal -- это детище компании Borland). Так вот, Оберон -- это упрощенный Паскаль. А то, что он при этом могет быть языком системного программирования и заниматься всякой там коммутацией-композицией модулей и процедур -- просто полезный "довесок".
| № 2384 31-03-2007 17:36 | |
Ответ на »сообщение 2371« (Geniepro)
___________________________
Для школ идеальны языки с минимумом синтаксиса и маскимумом приближения к школьной математике.
Например?
| № 2383 31-03-2007 17:31 | |
Ответ на »сообщение 2376« (Geniepro)
___________________________
Сущность же функционального программирования - в манипулировании функциями, это-то и отражено в названии этой парадигмы.
Те самые "навороты" (по мнению Ильи Ермакова) - это и есть сущность ФП. Ну а что бы ФП работало без сбоев, приходится ограничивать изменения состояния, локализовать их в карантинных зонах...
IMHO, не все, чего нет в Обероне (а список явно напирает на то, чего в Обероне нет), относится к ФП.
Кроме того, возникают и совсем наивные вопросы.
Ну какая принципиальная разница, именована функция или нет, если ее имени не видно за пределами модуля?
Почему, собственно, без анонимных функций нет ФП?
>>>(Кстати, а куда Руслан Богатырёв пропал? Читал ли он ту мою мессагу?)
Руслан, скорее всего, занят подготовкой очередного номера "Мира ПК".
Вернется... :)
Вы имеете в виду сокрытие (hiding) данных? А какие именно замечательные свойства у этого сокрытия есть с точки зрения ФП? ООП и ФП - всё-таки разные вещи. Что для ФП - хорошо, то для ООП - смерть! :о))
Или наоборот... :)
Я просто хочу видеть, как именно выглядят эти "глобальные" структуры данных в ФП, как они соединяются в одно целое.
Что, например, будет, если я захочу поменять представление данных в каком-то месте программы?
Во что это выльется?
Та проблема с датчиком случайных чисел актуальна для Scheme, но это не значит, что она актуальна для чистого ФП. В Хаскелле этот датчик помещается внутрь монады ввода-вывода, и тем самым скрывается от остальной части программы...
А в чем разница для остальной части программы?
Какая ей разница, поместили Вы датчик внутрь монады или просто используете локальную переменную?
Вообще, складывается впечатление, что до Хаскеля ФП не существовало, т.к. Вы все время переводите разговор на Хаскель.
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
|
