| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 3072 03-10-2007 09:44 |   |
Ответ на »сообщение 3066« (Илья Ермаков)
___________________________
Поделитесь опытом - а как Вы с первого взгляда видите инвариант цикла, в котором использован break?
Чем инвариант такого цикла будет отличаться от аналогичного ему "структурного" цикла, где досрочный выход из цикла имитируется if'ами и флажками?
Кстати, это не единственная "особенность" структурного подхода. Да, конечно, существует теорема Боэма-Джакопини, но Вы видели ее доказательство? Очень конструктивное? А предлагаемые в некоторых книгах приемы борьбы с неструктурируемыми конструкциями, предполагающие дублирование кода (к break это не относится) или вынос фрагментов кода в процедуры? Это, надо понимать, верх эффективности, о которой многие так беспокоятся?
Еще, между прочим, существует теория верификации программ с произвольными goto, не то что с досрочным прерыванием цикла (если мне не изменяет память, ее разрабатывал Флойд). Да, предусловия помеченных операторов получаются сложнее, чем в "структурном случае", но кто сказал, что верификация --- легкое занятие?
Поминая "GOTO statement considered harmful", не стоит забывать и о "Structured programming with GOTO statements". :-)
| № 3071 03-10-2007 09:03 | |
Ответ на »сообщение 3069« (panda)
___________________________
Ответ на »сообщение 3067« (Илья Ермаков)
___________________________
И новичков надо учить применять такие конструкции, а не говорить, что "это плохо".
Ответьте, пожалуйста, на вопрос: а зачем? С аргументами. Только потому, что "в промышленном программировании это норма"? Неиспользование break как-то повлияет на их принятие в промышленной среде? Что от этого неиспользования прибудет, понятно - дисциплина и большая корректность и продуманность кода. А вот что убудет - не понятно.
Знаете, приведу такой пример: когда учат играть на гитаре - очень важно поставить правильную технику. И вдруг оказывается, что правильно ставить руку на грифе может быть очень неудобно. Но вот только опытный педагог не позволит ставить так, как удобно. Потому что потом дойдёт дело до сложных аккордов с баррэ - и взять их с неправильной постановкой руки будет не то что бы неудобно, а просто невозможно. Почему бы не разрешить играть простые аккорды так, как удобно, с расчётом на то, что в сложных случаях рука будет ставиться по-другому? Ан нет. Это - техника, а значит, нечто, у профессионала контроллируемое на уровне подсознания. И нельзя "ставить руку" то по-одному, то по-другому. В любом случае, накладные расходы на переключение режима выйдут дороже, чем выработать единую технику.
Нельзя "немножко использовать goto". Где критерий, по которому вот тут надо, а вот тут не надо? Крайности притягивают, и лучше пусть притягивают хорошие крайности. Ибо чувство меры соблюдается гораздо реже. И у каждого разное - "на вкус и цвет". А в промышленном проекте вкусовщины как раз лучше избегать как огня...
| № 3070 03-10-2007 08:36 | |
Ответ на »сообщение 3069« (panda)
___________________________
Вы завели разговор про "промышленные программы". А там как раз break, return, exit и прочие нарушения чистого структурного программирования - это норма. Разумеется, применять эти конструкции тоже надо умеючи. Скажем, Borland это может делать. Причем весьма неплохо. И новичков надо учить применять такие конструкции, а не говорить, что "это плохо".
Вопрос: а нужно ли в промышленном производстве ПО требовать от программистов контроля инвариантов? Например, нужно ли бить по рукам программиста, который не знает, что такое инвариант цикла и/или не применяет его регулярно в решении повседневных производственных задач? Как это предлагал А.П.Ершов, который, кстати, одним из первых заговорил о промышленном программировании.
| № 3069 03-10-2007 08:30 | |
Ответ на »сообщение 3067« (Илья Ермаков)
___________________________
"Не надо путать теплое с мягким" (с) Дмитрий Пучков
Вы завели разговор про "промышленные программы". А там как раз break, return, exit и прочие нарушения чистого структурного программирования - это норма. Разумеется, применять эти конструкции тоже надо умеючи. Скажем, Borland это может делать. Причем весьма неплохо. И новичков надо учить применять такие конструкции, а не говорить, что "это плохо".
| № 3068 03-10-2007 08:17 | |
| № 3067 03-10-2007 08:00 | |
Ответ на »сообщение 3065« (panda)
___________________________
Ответ на »сообщение 3056« (Илья Ермаков)
___________________________
Угу. Вы один умный. А программисты огромного количества крупных компаний, например, Borland - это "люди, не знающие основ грамотного алгоритмирования".
Увы, у очень многих программистов не хватает времени почитать классику :-) И повысить свой уровень образованности.
Что такое отсутствие систематического образования, все мы прекрасно знаем. Сами такие. Потом дико обидно за бессмысленно потраченное время - "а вот если бы нас сразу так учили".
| № 3066 03-10-2007 07:57 | |
Ответ на »сообщение 3065« (panda)
___________________________
Ответ на »сообщение 3056« (Илья Ермаков)
___________________________
Меня мало интересует, что читают люди, не знающие основ грамотного алгоритмирования. И не представляющие жизни без субститутов goto.
И то, что их код от этого становится намного более простым и понятным - это тоже говорит об их неумении.
Один раз на сто циклов становится. В остальных случаях происходит обратное. Будем пропагандировать стиль программирования с прицелом на редкие случаи? :-)
Поделитесь опытом - а как Вы с первого взгляда видите инвариант цикла, в котором использован break?
Не говоря уже про то, каким образом можно вообще получить цикл с break, раскручивая цикл (хоть и в уме) по постусловиям (разве потом полученный цикл искусственно "соптимизировать" до for с break :-) ). Только при писании методом клёпа и тыка без break никак.
| № 3065 03-10-2007 07:38 | |
Ответ на »сообщение 3056« (Илья Ермаков)
___________________________
Меня мало интересует, что читают люди, не знающие основ грамотного алгоритмирования. И не представляющие жизни без субститутов goto.
Угу. Вы один умный. А программисты огромного количества крупных компаний, например, Borland - это "люди, не знающие основ грамотного алгоритмирования". Ведь они в своем коде (например, VCL) смеют употреблять break. И то, что их код от этого становится намного более простым и понятным - это тоже говорит об их неумении.
| № 3064 03-10-2007 07:09 | |
Вагиф, еще вопросы:
1. Доводилось ли Вам изучать язык SETL? Каковое Ваше мнение об этом языке и о подходе использования теории множеств (основы математики) в качестве фундамента для программирования, для высокоуровневого решения задач?
2. Как Вы думаете, имеет ли смысл рассматривать подходы языка SETL (можно сделать свой -- это не принципиально) в качестве основы, связующего звена в ортогональном базисе языков (ИП-ФП-ООП), в качестве основы интеграции и отображения на них?
| № 3063 03-10-2007 06:51 | |
Ответ на »сообщение 3062« (Илья Ермаков)
___________________________
Вагиф, скажите пожалуйста, а что Вы думаете про РЕФАЛ? Какое место он, с вашей точки зрения, занимает в семействе функциональных (хотя, наверное, шире - декларативных, ведь он "марковский") языков?
Присоединяюсь. И про суперкомпиляцию скажите свое мнение. Не настала ли пора наработки В.Ф.Турчина брать нам на вооружение?
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
|
