| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 2662 05-04-2007 03:49 |   |
Ответ на »сообщение 2660« (Руслан Богатырев)
___________________________
Доказательное программирование -- это не блажь. Оно дает большую пользу даже в ограниченной форме (рассуждений на уровне инженера-математика, анализирующего всю указанную цепочку).
По моему это наш аргумент а не ваш Руслан. :))
По сравнению с тем какие возможности по анализу кода дает хаскель, оберон находится в области гаданий на кофейной гуще.
| № 2661 05-04-2007 03:48 | |
Ответ на »сообщение 2659« (Jack Of Shadows)
___________________________
ФЯ показывают нехилое преимущество перед ИЯ не только в малом но и в большом.
Джек, меня не интересует реклама. Я не на пресс-конференции. Расскажите, как Вы понимаете плюсы и минусы ФП для этой области. Если нет желания, времени и т.д. и т.п. -- никакой обиды. По крайней мере, это будет понятно.
| № 2660 05-04-2007 03:46 | |
Ответ на »сообщение 2657« (Jack Of Shadows)
___________________________
Тут уже нужны unit тесты.
По-моему, здесь налицо явное и глубокое недопонимание. Думаю, вряд ли стоит продолжать в этом направлении обсуждение, убеждать Вас в том, что тесты ходят только по отдельным "трассам" всего множества вариантов. Если бы математики занимались бы только "тестированием", нас ожидал бы весьма странный мир.
Пока постановку задачи делает человек, пока он формулирует спецификацию требований, пока он осуществляет проектирование, пока он реализует проектные решения, только он и может выявить ошибки того уровня, которые не рванули, но рванут. Доказательное программирование -- это не блажь. Оно дает большую пользу даже в ограниченной форме (рассуждений на уровне инженера-математика, анализирующего всю указанную цепочку). Ловить "блох" и "бабочек" -- это хорошо. Особенно для того, чтобы убедить себя и других в том, что все просто замечательно.
| № 2659 05-04-2007 03:42 | |
Ответ на »сообщение 2656« (Руслан Богатырев)
___________________________
Хотя для проектов, где задачи масштабирования
Простите но вы упорно игнорируете примеры больших и сложных систем, написанных на ФЯ, которые масштабируются либо не хуже, либо в разы лучше аналогичных, написанных на ИЯ.
Совсем недавно говорил, но видимо придется еще раз.
Erlang Web Server YAWS держит нагрузку в сотни раз лучше чем признанный стандарт в этой области - apache
Вот посмотрите на диаграмму:
http://www.sics.se/~joe/apachevsyaws.html
Далее, распределенная база данных Mnesia - тоже масштабируется весьма нехило. Она используется в системах реального времени и обрабатывает запросы СОТЕН МИЛЛИОНОВ пользователей.
Для сравнения, такие базы данных как Orale, DB2, и MSSQL, признаные лидеры в области баз данных, и близко не могут подойти к таким результатам.
ФЯ показывают нехилое преимущество перед ИЯ не только в малом но и в большом.
Просто признание рынка не за пару месяцев приходит.
Но я уверен, что это признание наступит, и очень скоро. В ближайшие 5-10 лет.
| № 2658 05-04-2007 03:41 | |
Ответ на »сообщение 2657« (Jack Of Shadows)
___________________________
>>>Ошибка всегда проявляется.
Если бы, Jack, если бы...
| № 2657 05-04-2007 03:33 | |
Ответ на »сообщение 2654« (Руслан Богатырев)
___________________________
Удивительно. А если ошибка не произошла, но она при этом существует?
Это уже паранойа. Ошибка есть а внешних признаков нет. :)) Как же вас бессонница не замучала с такими то мыслями ? :))
Ошибка всегда проявляется. Если не через вылетание программы, то через неправильную работу.
И вот тут вам никакой квалифицирующий импорт не поможет.
Тут уже нужны unit тесты.
А юнит тесты тяжко писать для ОО систем. Зато очень легко для функциональных.
Потому что юнит тесты любят маленькие и автономные функции. А когда все связано друг с другом, тут намучаешься тест писать. Выход - учиться декомпозиции системы на множество маленьких и автономных сервисов - функций.
Как видите у нас свои подходы к решению проблем. И квалифицирующий импорт в них играет второстепенную (если и какую либо) роль.
| № 2656 05-04-2007 03:31 | |
Ответ на »сообщение 2618« (Geniepro)
___________________________
>>Вопрос: какие подходы мировое ФП-сообщество выработало в отношении оценки потребности ресурсов/"просадки" с перспективой возможностей последующего масштабирования (быстро) полученного решения? Это не укол, а желание разобраться. Плюсы ФП (сокрытие деталей) здесь превращаются в минусы. Их, видимо, можно нивелировать. Осталось выяснить как.
Пока остаётся лишь традиционное средство - профилирование программ.
Понятно. Значит, это действительно проблема, как я и предполагал. Хотя для проектов, где задачи масштабирования не ставятся и где мало интересует прожорливость ФП -- это в самом деле неважно. В отношении программирования в малом более-менее разобрались. Вывод, который я для себя вынес из обсуждени -- многие задачи программирования в малом являются задачами на преобразование, следовательно, если программист работает в императивном (процедурном) языке, ему имеет смысл отталкиваться от ФП, заимствуя готовые идеи (используя чужой опыт).
Что Вы могли бы сказать о ФП в отношении программирования в большом (в том числе для задач конструирования/моделирования/макетирования)? Желательно сразу не отсылать к источникам, а сформулировать видение/позицию своими словами.
| № 2655 05-04-2007 03:24 | |
Ответ на »сообщение 2651« (panda)
___________________________
Когда (а не если) я заглядываю в VCL, чтобы позаимствовать оттуда реализацию какой-либо функциональности, я использую Ctrl+мышь. Компьютер справляется с поиском и открытием файла Classes.pas намного быстрее любого программиста.
"Человек должен думать, машина - работать" (с) не мое.
Не понял, к чему это сказано.
Возможно, Вы полагаете, что в обероновских средах нет такой возможности?
Возьмите к примеру ББ.
Допустим, Вам встретилась какая-то процедура, и Вы хотите с ней разобраться.
Пусть, для примера, это будет упоминавшаяся недавно Math.Sqrt.
Двойной щелчок мышкой выделяет идентификатор Math, правый щелчок предоставляет меню с выбором: исходный текст, интерфейс модуля, документация.
Если выбираете исходный текст, то попадаете прямо на реализацию процедуры.
| № 2654 05-04-2007 03:18 | |
Ответ на »сообщение 2650« (Jack Of Shadows)
___________________________
Руслан, если у меня в дельфи где то что то не работает и вылетает ошибка, то я получаю номер строчки и название файла где эта ошибка произошла.
Удивительно. А если ошибка не произошла, но она при этом существует? Т.е. нет никаких внешних признаков. Ибо пока не рвануло. Нужны мозги программиста, который поймет, что это -- ошибка.
| № 2653 05-04-2007 03:13 | |
Ответ на »сообщение 2649« (panda)
___________________________
Думаю, дальше продолжать не надо? Если бы Oberon стал "серебряной пулей" мы бы сейчас обсуждали совсем другие вопросы.
Странно слышать подобную реакцию. Тем более, от достаточно компетентного человека, каковым я Вас считаю. Во-первых, Оберон никогда не был серебряной пулей. И было бы неплохо, если мы все вместе поняли, что здесь не торговля и не реклама товаров (а также не кулики со своими болотами), а желание разобраться. Если есть желание разобраться -- замечательно. Давайте обсуждать.
Во-вторых, неоднократно говорил и буду говорить -- в Обероне главную роль играют модули. Это его главная ценность. Она же являются и его ахиллесовой пятой.
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
