| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 2642 05-04-2007 01:36 |   |
Ответ на »сообщение 2639« (Max Belugin)
___________________________
Многое зависит от терминологии. Если объектно-ориентированный это "язык с классами и наследованием", а функциональный - "язык со всякими новомодными штучками", то никакого противостояния нет.
Но если занять более консервативную позицию, можно заметить следующее:
1. При объектном подходе процесс вычислений рассматривается как последовательная смена состояний системы, состоящей из объектов. Объектно-ориентированный язык должен обеспечивать средсва для описания состояний объектов и методов изменения состояний.
2. При функциональном подходе процесс вычислений рассматривается как последовательность применения функций. Объекты, которыми манипулируют функции, не имеют состояний. Функциональный язык должен предоставлять только средства описания функций. Если же добавить возможнось работы с изменяемыми объектами, то функциональная модель вычислений рушится и мы переходим к случаю 1.
| № 2641 05-04-2007 00:36 | |
Ответ на »сообщение 2638« (Trurl)
___________________________
Для выяснения какая функция из какого модуля совсем необязательно перед каждым из них везде писать имя модуля. Достаточно навести на него мышку, и редактор вам покажет полное имя. Более того достаточно нажать Ctrl-Мышка и пожалуйста, редактор прыгнет прямо в тело описания этой функции.
А какой редактор Вы используете для Haskell?
Я вообще о редакторах говорил а не для хаскеля. В Дельфи есть авто-навигация по модулям. В Visual Studio есть, в emacs для лиспа есть, в Lispworks есть.
В хаскелевском плагине для Visual Studio тоже есть. То есть такая функциональность для любого языка - не проблема.
| № 2640 05-04-2007 00:18 | |
Ответ на »сообщение 2633« (AVC)
___________________________
>>>>Если код на хаскеле скомпилировался без ошибок то я УВЕРЕН что в нем отсутствует конфликт имен.
>>>Значит, Хаскель в данном пункте превосходит C#.
Да, превосходит и C# и Delphi. Но все же проблема и здесь может возникнуть, хотя вероятность этого мала, да и последствия не такие серьезные.
Например, мы решили добавить/изменить несколько функций. При этом нам потребовалсь функции из модуля X. Импортируем его и делаем, что хотели. Но прикомпиляции получаем сообщение о конфликте имен с модулем Y. Нет проблем - переходим к ограниченному импорту. Теперь осталось отыскать все вхождения конфликтующих функций и уточнить имена. Плохо, если у них тип совпадает.
| № 2639 05-04-2007 00:15 | |
Уважаемый Trurl. В прошлой теме вы как-то сказали что-то типа "Чем более язык функциональный тем менее он объектно-ориентированный". Не могли бы вы развить эту мысль?
| № 2638 04-04-2007 23:50 | |
Ответ на »сообщение 2619« (Jack Of Shadows)
___________________________
>>>Для выяснения какая функция из какого модуля совсем необязательно перед каждым из них везде писать имя модуля. Достаточно навести на него мышку, и редактор вам покажет полное имя. Более того достаточно нажать Ctrl-Мышка и пожалуйста, редактор прыгнет прямо в тело описания этой функции.
А какой редактор Вы используете для Haskell?
| № 2637 04-04-2007 23:21 | |
Ответ на »сообщение 2630« (Илья Ермаков)
___________________________
Для серьезных случаев, с использованием типов данных из сторонних модулей и т.п. - важно сразу видеть, какой из модулей отвечает за ту или иную функциональность. Не при написании. При изучении, а особенно - изменении. Я уже приводил пример - разобраться в одном из крупных модулей VCL - иcщелкаетесь мышкой :-)
Ага, ну вот узнал я, например, что класс TThread находится в модуле Classes. И что с того? Мне от этого должно стать легче?
| № 2636 04-04-2007 17:07 | |
Ответ на »сообщение 2619« (Jack Of Shadows)
___________________________
>>>Для выделения служебных слов не нужно заставлять программиста писать их большими буквами. С этим прекрасно справляется любой программистский редактор.
Совершенно верно. :)
Лично я набираю служебные слова маленькими буквами, а большими (и, при желании, подсвеченными) их делает редактор.
Для этого редактор не обязан быть частью обероновского IDE.
Например, в vi существует такое средство как abbr.
| № 2635 04-04-2007 16:54 | |
Ответ на »сообщение 2630« (Илья Ермаков)
___________________________
Ответ на »сообщение 2629« (Jack Of Shadows)
___________________________
Обясните мне чем sqrt(4) отличается от Math.sqrt(4)
В плане понимания кода, ничем.
Для примитивного примера с мат. функциями - ничем.
Даже для "примитивного" примера с мат. функциями, IMHO, все не так просто.
Расширяемая программная система устроена так, что в ней одновременно может существовать несколько функций sqrt.
Мне сразу не очевидно, не приведет ли неквалифицированный импорт в таких обстоятельствах к каким-либо проблемам.
| № 2634 04-04-2007 16:36 | |
Ответ на »сообщение 2632« (Илья Ермаков)
___________________________
Для любого знания нужен опыт. Для получения опыта нужно его приобретать. Чтобы его приобрести, нужно сначала поверить в то, что он вообще есть... Наука тоже базируется на вере. Поверь, что мир познаваем - и попробуй это делать. Набивай шишки и получай опыт. Наличие собственного опыта дает твердое знание... В итоге имеем бесконечные споры между теми, кто прошел из стадии веры до стадии знания, и теми, кто требует знания сразу, "на тарелочке".
WOW! Наверное это мне надо было отвечать Сергею Перовскому на его запросы показать в чем преимущества ФП "в большем".
Ну что ж, пользуясь уроком Ильи, отвечаю вам вашими де словами: Для любого знания нужен опыт. Для получения опыта нужно его приобретать. Чтобы его приобрести, нужно сначала поверить в то, что он вообще есть.
Короче говоря, всем бегом на сайт haskell.org, скачивайте, ставьте, реализуйте проект достаточно большой, чтобы эти преимущества в большом увидеть а так же опыт наработать, и потом возвращайтесь на этот форум :))
| № 2633 04-04-2007 16:29 | |
Ответ на »сообщение 2625« (Jack Of Shadows)
___________________________
>>>Непонятный запрос. Уверенность в отсутствии конфликтов имен дает компилятор вообще то :))
В обероновской ветке в свое время рассматривался пример из статьи Свердлова, в котором компилятор весьма современного языка (C#) не мог предотвратить конфликт имен и генерацию ошибочного кода.
>>>Если код на хаскеле скомпилировался без ошибок то я УВЕРЕН что в нем отсутствует конфликт имен.
Значит, Хаскель в данном пункте превосходит C#.
>>>То же не понял. Используя нормальный IDE вы типа НЕ имеете полную принципиальную схему системы, с наглядным выделением взаимных связей ?
В Обероне (я сейчас не рассматриваю отдельные компиляторы, вроде XDS) нет традиционного понятия программы.
В любой момент система может быть на лету расширена новым модулем.
И как именно я могу получить полную принципиальную схему системы, которая всегда открыта для расширения, независимо от того, каким IDE я пользуюсь?
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
