Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 2732 06-04-2007 06:44 | |
Ответ на »сообщение 2729« (Илья Ермаков)
___________________________
Например, я могу слинковать приложение с реализацией диспетчера памяти, оптимизированным под выделение крупных блоков памяти, а могу - с мелкогранулярной политикой выделения...
Ну так и соответсвующие классы будут называться по-разному. Опять же проблема исчезает без применения Оберона.
Версионность одних и тех же сущностей в компонентной системе - это скорее правило, нежели исключение. И компонентная парадигма позволяет легко этим управлять.
Версионностью позволяют управлять не парадигмы, а системы контроля версий вообще-то ;)
№ 2731 06-04-2007 05:46 | |
Ответ на »сообщение 2699« (panda)
___________________________
Конечно! Ведь меня пытаются убедить, что это у меня проблемы, а не у Вас или Ильи Ермакова, когда вы переходите с Оберона на Delphi.
Мое мнение, что у меня нет проблем, явно должно быть решающим в этом вопросе ;)
Ну, если Вас пытаются убедить, что у Вас есть проблемы, это конечно неправильно. Но то, что Вы могли бы себя обезопасить от некоторых проблем, это точно. Другое дело, цена вопроса -- время, желание и т.д. и т.п. Но, поверьте, подробно разжевывая пресловутый квалифицирующий импорт, я не ставил перед собой такой цели в отношении конкретно Вас. Просто пояснил, что в решении Geniepro меня смутило. А дальше пошла цепочка упорного недопонимания (возможно с обеих сторон). Но чтобы прояснить вещи, оказавшиеся погребенные под эмоциями, написал два развернутых сообщения в соседней ветке по Оберону (где, видимо, это более уместно).
№ 2730 06-04-2007 03:04 | |
Ответ на »сообщение 2724« (panda)
___________________________
Ответ на »сообщение 2703« (Илья Ермаков)
___________________________
"дремучесть", уж извините...
Не извиню. Когда Вы сможете доказать, что Вы - более квалифицированный программист, чем все люди, с которыми Вы спорите, вот тогда посмотрим.
Эпитет не относился к Вам. Он относился в целом к стилю программирования, принятому среди массового Дельфи-программинга.
Конечно, гораздо лучше, чем среди массового Це-программинга, но любая попытка предложить что-то "устрожить" также обычно встречается в "штыки": "скока лет так ваяли - и дальше будем".
У нас позиция другая - если можно ввести большую ясность/прозрачность/аккуратность, то это надо делать...
№ 2729 06-04-2007 02:55 | |
Ответ на »сообщение 2724« (panda)
___________________________
Ответ на »сообщение 2703« (Илья Ермаков)
___________________________
Измышления про 2 функции sqrt вообще идут лесом, в промышленных проектах любая функциональность должна достигаться одним способом, а не двумя, тремя, тысячью. Иначе через год никто не сможет объяснить, для чего вообще это все нужно.
Промышленный проект обычно имеет ряд версий и модификаций, в которых одна и та же функциональность реализована по-разному.
Например, я могу слинковать приложение с реализацией диспетчера памяти, оптимизированным под выделение крупных блоков памяти, а могу - с мелкогранулярной политикой выделения...
Версионность одних и тех же сущностей в компонентной системе - это скорее правило, нежели исключение. И компонентная парадигма позволяет легко этим управлять. Но требует взамен дисциплины и порядка... А не наплевательского "мне все равно, где что там лежит". Морды к базам данных, как это любит называть Джек, можно, конечно, делать и так. Программист - в первую очередь инженер, строящий техническую систему, а не что-то там..
№ 2728 06-04-2007 02:35 | |
Ответ на »сообщение 2724« (panda)
___________________________
>>>Не извиню.
Уважаемый panda!
Прочтите дискуссию, что функциональщики наговорили в наш адрес.
(Особенно -- Jack of Shadows, в силу горячности и неравнодушия к теме.)
Однако, извинения всегда принимались, разговор продолжался.
№ 2727 06-04-2007 02:22 | |
Ответ на »сообщение 2712« (Geniepro)
___________________________
Серебрянной пули нет!
Эти слова Брукса мы тут повторяли неоднократно (в тех или иных формах)... Почему вы их не заметили? :о(
Где и когда эти слова применялись к ФП?
А то запомнились только перлы (вроде "разумности" маклиспа). :)
№ 2726 06-04-2007 01:58 | |
Ответ на »сообщение 2723« (Trurl)
___________________________
>>>instance Num Kilometers where
А это просто сокращение или хитрый компилятор сам додумывает, что должно быть после where?
Ну в данном случае мне не нужны были реальные реализации арифметический и других операций - главное было посмотреть, будет ли конфликт типов...
Компилятор, конечно, пожурил меня предупреждениями за халатность и разгильдяйство, но главное - определил, что типы несовместимы... :О))
Хит-парад языков для вычисления факториала.
Haskell: product [1..n]
Setl: */ {1..n}
А можно ещё определить простенькую операцию
from */ to = product [from..to] добавить её куда-нить в библиотечку и юзать по полной:
1 */ n :o))
№ 2725 06-04-2007 00:29 | |
Хит-парад языков для вычисления факториала.
Python: reduce(lambda x,y: x*y, range(1,n+1))
Haskell: product [1..n]
Setl: */ {1..n}
K: */ 1+!n
J: !n
№ 2724 06-04-2007 00:16 | |
Ответ на »сообщение 2703« (Илья Ермаков)
___________________________
Каким образом явная квалификация мешает открывать по щелчку мыши? Она всего лишь избавляет от необходимости щелкать для того, чтобы видеть, что откуда. В разработке системных или инфраструктурных частей ПО, особенно компонентного, очень важно видеть, куда и когда идет граф управления...
Нет, нет и еще раз нет. Не важно, а Вам важно. Мне не только не важно, но и не нужно.
Вы не привели ни одного доказательтства в пользу своего мнения. Измышления про 2 функции sqrt вообще идут лесом, в промышленных проектах любая функциональность должна достигаться одним способом, а не двумя, тремя, тысячью. Иначе через год никто не сможет объяснить, для чего вообще это все нужно.
"дремучесть", уж извините...
Не извиню. Когда Вы сможете доказать, что Вы - более квалифицированный программист, чем все люди, с которыми Вы спорите, вот тогда посмотрим.
№ 2723 06-04-2007 00:09 | |
Ответ на »сообщение 2709« (Geniepro)
___________________________
>>>instance Num Kilometers where
А это просто сокращение или хитрый компилятор сам додумывает, что должно быть после where?
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|