| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 1152 06-09-2006 10:17 |   |
Ответ на »сообщение 1151« ()
___________________________
У "богатого" языка есть свой, причём очень существенный обьективный недостаток - гораздо труднее реализовать для него надёжный, качественный транслятор, который к тому же генерировал бы быстрый код, что видно, например, на противостоянии Ада vs Модула/2-Оберон...
Об этом часто упоминают те же оберонисты...
| № 1151 06-09-2006 05:13 | |
Ответ на »сообщение 1150« ()
___________________________
С другой стороны, если почитать то, что написано ниже (But seriously, folks, ...), то становится понятным, что люди разные и професси у них - тоже. Каждый привык по своему мир воспринимать, на одни и те же вещи смотреть под разными углами зрения (парадигмы и привычки у всех - свои)... Вот каждому - свои "куточок". Мало кто из непрограммистов любит (и будет) заниматься созданим на ну уж очень гибком языке собственного языкового расширения. Лучше он увидит, чего понял в "богатом" языке и будет пользоваться только этим подмножеством (средств)...
Остаётся теперь определить не "необходимый минимум", а - "достаточный максимум"... :о)))) Сообщение не подписано
| № 1150 06-09-2006 05:05 | |
Ответ на »сообщение 1149« (Geniepro)
___________________________
Вот и возникает вопрос - не переусложнён ли Хаскель? Действительно ли нужно иметь в одном языке столько способов сделать одно и то же? ;-)
Как всегда, что лучше: иметь набор готовых способов разнообразить себе жизнь или иметь средства для создания такого разнообразия? :о) Из той же оперы, что и "Си++ против Лиспа"...
Сообщение не подписано
| № 1149 06-09-2006 03:01 | |
Забавная статейка - "Эволюция Хаскель-программиста" Фрица Руэра
http://www.willamette.edu/~fruehr/haskell/evolution.html
Столько вариантов функции факториала на Хаскеле я не ожидал увидеть... :-))
Вот и возникает вопрос - не переусложнён ли Хаскель? Действительно ли нужно иметь в одном языке столько способов сделать одно и то же? ;-)
| № 1148 06-09-2006 00:50 | |
Ответ на »сообщение 1147« (Geniepro)
___________________________
2-ядерный пень 3,2 ГГц 512М
| № 1147 05-09-2006 12:50 | |
Ответ на »сообщение 1146« (Артем)
___________________________
P.S. Вааще, надо уже оставить этот дурацкий тест в покое :)
:-)) Да, пора бы что-нить поинтереснее придумать...
ЗЫ. Но вы так и не упомянули, какое у вас оборудование... Чисто интересно...
| № 1146 05-09-2006 12:09 | |
Ответ на »сообщение 1144« (Geniepro)
___________________________
А приведите-ка свой код на C#, если не трудно... :-)
Здрассьте! 8) Это ж ваш код на C#. Я проверял ваш код, ну только по аналогии добавил туда расчеты по времени.
...
static void Main(string[] args)
DateTime t2 = System.DateTime.Now;
Console.WriteLine("time == ", t2-t1);
Console.ReadLine();
}
...
P.S. Вааще, надо уже оставить этот дурацкий тест в покое :)
| № 1145 05-09-2006 09:58 | |
Ответ на »сообщение 1142« (Trurl)
___________________________
А почему на F# рекурсивные вызовы, а на а С# -простой цикл? Надо уравнять.
...
А теперь можно сравнивать :-)
Боюсь, что не получится. :-((
Во-первых, компилятор MS C# (как и многие другие) не поддерживает оптимизацию хвостовой рекурсии,
В результате чего даже при х равном всего лишь 30000 (с типом long) получим переполнение стека, а время замерить не успеем.
Во-вторых, это не императивно! Это всё равно, как если бы в программе на F# использовать цикл вместо рекурсии... :-))
| № 1144 05-09-2006 09:58 | |
Ответ на »сообщение 1135« (Артем)
___________________________
Впрочем, я далек от мысли, что вы специально это сделали. Просто это говорит о том, что первый тест вы провели тяп-ляп и с воплями радости помчались сообщать нам, что
>>ФЯ быстрее ИЯ ! :-) Как вам такое?
Ну, во-первых, этот тест я проводил не один раз, а несколько - результат усреднил. Кстати, результаты менялись довольно сильно - примерно на +-5%
У меня даже в функции main (!) скорость выполнения для 64-битного целого на С#~5.4, на F#~5.8
Вполне возможно. Такие тесты очень сильно зависят от архитектуры процессора, на котором они выполняются. Так что я не удивлён... У вас, кстати, какое железо? Я проверял только на Celeron 1700 под Win2003/.NET 2.0 ...
У меня, почему-то, в .NET обработка 64-битных аргументов функций идёт быстрее, чем 64-битных локальных переменных (к такому вот выводу я пришёл...), у Вас, возможно, по другому...
У меня вот стабильно такие результаты (- 0.1 +0.3 сек)...
Я сталкивался со случаем, когда программа на XDS-Oberon/2 на моём Celeron'е существенно опережала аналогичную на Дельфах и C++BuiderX, а на Sempron'е так же существенно от них отстала... Одни и те же exe-файлы...
ЗЫ. Вообще-то, конечно, надо бы перезагружать Винду перед каждым тестом, а ещё лучше - переустанавливать её, но что-то так лениво... :-))
ЗЗЫ. Сравнить качество реализации компилеров C# и F# я, честно говоря, затрудняюсь...
ЗЗЫЫ. А приведите-ка свой код на C#, если не трудно... :-)
| № 1143 05-09-2006 09:10 | |
Ответ на »сообщение 1142« (Trurl)
___________________________
В указанном вами cs-коде при dec(1000000000) возникнет переполнение стека. Вот, кажется мы снова и вернулись к обсуждению рекурсии. :) Да, разработчики C#, как и разработчики Delphi, поленились реализовать оптимизацию хвостовой рекурсии :) Хотя в самой .Net такая возможность есть и тот же F# ее использует вовсю. Мотивация – хвостовую рекурсию в том случае, если есть вероятность многократных вызовов, лучше переписать в итеративном виде, и делается это легко. Но, конечно хотелось бы, чтобы в следующей версии C# реализовали директиву хвостового вызова, или его оптимизация происходила автоматически (как в F#).
А пока, если есть большое желание, можно воспользоваться прямой вставкой “tail.”-директивы в IL-код функции f2:
.method private hidebysig static int32 f2(int32 x,
int32 y,
int32 z) cil managed
Есть еще «левые» тулзы-посткомпиляторы, позволяющие вставлять IL-код прямо в cs-код, но они, по-моему, довольно корявые. :(
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
