Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 2512 02-04-2007 13:33 | |
Ответ на »сообщение 2507« (Руслан Богатырев)
___________________________
что, на Ваш взгляд, в решении на КП выглядит тяжеловатым, излишне изобилующим деталями, вызывающим желание переделать (спрятать детали реализации). Я весь внимание...
Странно что вы не заметили. Наш взгляд уже был показан...размером в 63 строчки. :))
И решение на КП на наш взгляд излишне изобилует жонглированием локальным состоянием чуть ли не в каждой строчке программы.
Я уже об этом говорил. Илья сказал что многокоратное присваивание перемеых там используется только в процедурах ввода/вывода но никак не в логике программы. Однако я привел пример 2 центральных процедур именно логики где эти переменные так и мелькают. Опровержения (может пока) не получил.
№ 2511 02-04-2007 13:27 | |
Ответ на »сообщение 2508« (AVC)
___________________________
Если уж, Jack, Вы на самом деле хотите увидеть разницу, то обратите внимание, что Java не поддерживает "старое доброе процедурное программирование".
Поддерживает, поддерживает. Все в одном файле "классе". Все процедуры видят все данные, которые задекларированны как поля одного класса "Программа"
К неудобству того что в начале программы обязательно надо писать class main - легко привыкается.
№ 2510 02-04-2007 13:24 | |
Ответ на »сообщение 2509« (Jack Of Shadows)
___________________________
Вы меня не поняли AVC. Я о том и говорю. Не нужны ни ООП, ни модульность, ни компонентность.
<...>
ФЯ именно в обучении дают преимущество. В том плане что прививают грамотный подход НЕЗАВИСИМО от размера задачи. Прививают ПРИВЫЧКУ к декомпозиции, модуляризации, упрятыванию всего лишнего внутрь, взаимодействия через жесткие и скупые интерфейсы функций (входные параметры, выходные значения)
Это совсем другое дело. :)
Эта мысль действительно заслуживает обдумывания и обсуждения.
Если ФЯ на самом деле дают преимущество в обучении (хотелось бы получше разобраться в этом вопросе), то, конечно, постановка вопроса о ФЯ как первом (или хотя бы втором) языке программирования абсолютно обоснована.
№ 2509 02-04-2007 12:49 | |
Ответ на »сообщение 2508« (AVC)
___________________________
Естественно, что для игрушечных задач, для которых достаточно процедурного программирования, используется именно процедурное программирование.
Вы меня не поняли AVC. Я о том и говорю. Не нужны ни ООП, ни модульность, ни компонентность.
То есть решение Илья принял ВЕРНОЕ.
В этом и проблема. Для того чтобы понять пользу и необходимость всех этих механизмов нужно столкнуться с задачей довольно большого масштаба. Где ? Где столкнуться ? В школьном курсе ? Несерьезно. В реальной жизни ?
Кому ? Студентам у который программирование всего лишь факультативный предмет ?
Получается что вы меняете VB или java на оберон из самых лучших побуждений, а результат нулевой. Разницы никакой. Получается что все эти правильные и нужные механизмы не имеют никакой возможности развернуться и показать свою правильность и нужность ... в школьной среде.
Да ладно черт с ним с возможностью показать (и доказать) свою нужность и полезность.
Что хуже всего, что практика которую получают студенты, вот эти вот маленькие задачи в которых им приходится принимать ВЕРНОЕ решение НЕ использовать ничего из того чему их учили, доказывает им ()пусть и ложно) что МОЖНО обойтись без всего этого. Что это будет даже ЛЕГЧЕ и БЫСТРЕЕ и УДОБНЕЕ.
Таких ведь потом переделать гораздо труднее.
ФЯ именно в обучении дают преимущество. В том плане что прививают грамотный подход НЕЗАВИСИМО от размера задачи. Прививают ПРИВЫЧКУ к декомпозиции, модуляризации, упрятыванию всего лишнего внутрь, взаимодействия через жесткие и скупые интерфейсы функций (входные параметры, выходные значения)
Уже потом, столкнувшись в своей карьере со всеми этими java и сишарп, студенты будут делать абсолютно то же самое что они делали на практике в школе. Опять независимо от масштаба задач, будут лепить процедурщину, или грамотно пользоваться теми инструментами, что у них под рукой, даже ООП.
№ 2508 02-04-2007 12:19 | |
Ответ на »сообщение 2506« (Jack Of Shadows)
___________________________
Ни одного типа класса не описано. Никакой модульностью и не пахнет. Старое доброе процедурное программирование. А ведь это не новичек писал :))
Это писал человек продвигающий здесь "идеи оберона" которые вроде бы должны давать какую то разницу с дельфми или java. К сожалению в коде этой задачи разницы этой так и не обнаружилось.
Неужели этот "критический" пассаж написан всерьез?
Естественно, что для игрушечных задач, для которых достаточно процедурного программирования, используется именно процедурное программирование.
И надо было бы поставить Илье "двойку", если бы он умудрился засадить в эту программку дюжину классов или разбить ее на десяток модулей.
В том-то и достоинство Оберона, что кроме прочего он поддерживает "обычное" процедурное программирование.
В отличие, кстати, от Java.
Если уж, Jack, Вы на самом деле хотите увидеть разницу, то обратите внимание, что Java не поддерживает "старое доброе процедурное программирование".
№ 2507 02-04-2007 12:06 | |
Ответ на »сообщение 2506« (Jack Of Shadows)
___________________________
А Руслан на радостях не разглядел :))
С какой лупой Вы у меня радость-то разглядели? Я тут все сокрушаюсь, горюю, можно сказать, а некоторые это воспринимают как радость. Странно, однако...
Но вот что интерено так это то что Руслан даже не подозревает что в устах этих профессоров "java" означает не конкретный язык а целое семейство языков, подход.
К этому семейству относятя и паскаль и оберон.
Да-да, а также Алгол-68, ПЛ/1, C++ и т.д. и т.п. Это надо еще умудриться всех поставить на одну доску. Что имели в виду американские профессора -- ведомо им одним. Я же привел их слова с целью привлечь внимание к тому факту, что наконец-то американцы прилюдно (опубликовано в центральном американском издании) начинают беспокоиться о том, что преподавание ИТ в сфере их высшего образования, мягко говоря, ущербно. Что не преподают они фундаментальные вещи, не дают препарирование исполнения программы (ассемблер). А то, что они восстали против "Java", так это потому IMHO, что оскомину она уже в американских университетах всем набила. Любят они из одной крайности в другую бросаться. Но язык-то по сути ни при чем (Java или что другое). Надо просто владеть предметом программирования и уметь это владение донести до студенческой аудитории, а не учить языку (видимо, кто-то был не очень внимателен, читая мои сегодняшние сообщения, а жаль, я-то думал, что-то дойдет).
Ни одного типа класса не описано. Никакой модульностью и не пахнет. Старое доброе процедурное программирование. А ведь это не новичек писал :))
Это писал человек продвигающий здесь "идеи оберона" которые вроде бы должны давать какую то разницу с дельфми или java. К сожалению в коде этой задачи разницы этой так и не обнаружилось.
Я специально взял паузу в отношении комментирования трех разных решений олимпиадной задачки. Хочется все-таки, чтобы люди своим умом дошли. Подумайте и скажите, что, на Ваш взгляд, в решении на КП выглядит тяжеловатым, излишне изобилующим деталями, вызывающим желание переделать (спрятать детали реализации). Я весь внимание...
№ 2506 02-04-2007 11:24 | |
Руслан вот тут приводил слова некоторых американских преподов, по поводу того что преподавать студентам java это преступление. Полностью согласен с этим утверждением, сам не раз заявлял подобное.
Но вот что интерено так это то что Руслан даже не подозревает что в устах этих профессоров "java" означает не конкретный язык а целое семейство языков, подход.
К этому семейству относятя и паскаль и оберон.
Для того чтобы это осознать достаточно посмотреть на задачи, которые решают школьники и студенты. Задачи эти маленькие (может за исключением курсового проекта). И в задачах этих школьники, даже те кто 5-ки по программированию получил не используют ни ООП, ни модульность. По существу разницу между кодом одной и той же задачи написанной студентами на java, паскаль или оберон - под лупой не разглядишь.
Не верите мне ? Посмотрите на код олимпиадной задачи на обероне, приведенный здесь совсем недавно:
http://forum.oberoncore.ru/viewtopic.php?t=409
Ни одного типа класса не описано. Никакой модульностью и не пахнет. Старое доброе процедурное программирование. А ведь это не новичек писал :))
Это писал человек продвигающий здесь "идеи оберона" которые вроде бы должны давать какую то разницу с дельфми или java. К сожалению в коде этой задачи разницы этой так и не обнаружилось.
То есть в классе перед учителем, все такие умненькие, ООП там, модульность, "кластерно-модульное" программирование и все такое. Оценку получили, перешли к практике без надзирателя над головой, и вот уже отброшены в сторону все эти ненужные (да, без кавычек) навороты. И на том же самом обероне пишется код, ничем не отличающийся от кода ни visual basic :))
Так будет ли разница если перейти от java к оберону в обучении студентов ? Даже если и будет то только на словах, чтобы оценку получить. А на практике... ну вы видели :))
Будет ли разница если преподавать программирование на лиспе (схеме) или даже хаскеле ?
Несомненно. Причем даже на самых маленьких программах.
Именно это и имели в виду те американские преподы. Они показывали пальцем на MIT с его курсом SICP.
А Руслан на радостях не разглядел :))
№ 2505 02-04-2007 10:25 | |
Ответ на »сообщение 2503« (Geniepro)
___________________________
Хорошо, если с ООП всё ясно, то какие же возможности ФП, не пересекающиеся в то же время с возможностями ИП и ООП (т.е. традиционно характерные именно для ФП), есть в Оберонах?
И насколько удобно и естественно для типичного оберонщика они реализованы?
Списки, кортежи, атомы представимы через "ссылочные" записи (порождаемые в динамике). Разница в том, что в Обероне "модели" собираются из конструктора, а в ФП -- готовые модели. Процедуры-функции, а также ссылки на функции (процедурные типы, процедурные поля, процедурные переменные) дают возможность выстраивать композицию. Ссылки, возможно, удобнее заменить на идентификаторы-строки (т.е. ввести регистрацию с фиксацией реального адреса процедуры с ее "именем"). Это основа, от которой можно отталкиваться. И для этого каких-то сверхусилий (вроде моего примера с имитацией динамических функций через сети Петри) не требуется. Все практически в лоб, без фокусов.
Но... Встает еще задача контроля контекста исполнения функций (равно как и отслеживания побочных эффектов). Для этого нужны дополнительные усилия: в частности, упоминавшееся изолирование в отдельные модули (если действительно это так важно), написание средств статического контроля однократного присваивания (на уровне вспомогательного инструмента с выдачей предупреждений или встраиванием как отдельного прохода к компилятору). Хинтовка (подсказки) для компилятора может осуществляться в комментариях исходника на формальной основе (известный и эффективный прием).
Мое глубокое убеждение, которое я вынес еще со времени проекта интеграции Модулы-2, Лиспа и Пролога 20-летней давности -- не надо все впихивать в один язык. Равно как и пытаться создавать межъязыковое взаимодействие вообще -- на все случаи и времена. Лучше выбрать базис языков в "ортогональных" парадигмах и наладить их взаимодействие через делегирование управления и обмен сущностями (не всеми, а пригодными для "экспорта-импорта"). Взаимодействие может быть достаточно глубокое -- вплоть до возможности автоматического расширения ран-тайма другими языками (как я делал в случае введения в Пролог-машину новых встроенных предикатов, реализованных на Модуле-2). В этой схеме централизация работы (выбор головного и вспомогательных языков) диктуется задачей/проектом и предпочтениями команды исполнителей.
№ 2504 02-04-2007 10:25 | |
Ответ на »сообщение 2503« (Geniepro)
___________________________
Хорошо, если с ООП всё ясно, то какие же возможности ФП, не пересекающиеся в то же время с возможностями ИП и ООП (т.е. традиционно характерные именно для ФП), есть в Оберонах?
Уточняющий вопрос.
Насколько я понял, из крупных идей к ФП относятся:
1) отсутствие побочных эффектов и все возможные следствия этого факта;
2) принадлежность функций к числу объектов первого рода (лямбды и т.д.).
Не забыл ли я о чем-нибудь столь же существенном, как и эти два пункта?
>>>И насколько удобно и естественно для типичного оберонщика они реализованы?
Вы нам льстите.
Где Вы видели типичного оберонщика? ?)
№ 2503 02-04-2007 10:07 | |
Ответ на »сообщение 2501« (Руслан Богатырев)
___________________________
ИП в одеждах МП (в контексте Оберонов) -- это объединение возможностей ФП и ООП (не всех, а существенных) без "жесткости" ограничений ФП и ООП.
Хорошо, если с ООП всё ясно, то какие же возможности ФП, не пересекающиеся в то же время с возможностями ИП и ООП (т.е. традиционно характерные именно для ФП), есть в Оберонах?
И насколько удобно и естественно для типичного оберонщика они реализованы?
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|