Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 2712 05-04-2007 14:55 | |
Ответ на »сообщение 2707« (AVC)
___________________________
Священную войну (holy war или джихад) ведут функциональщики.
Ну вот, сначала объявили в терроризме, а потом:
Никто так и не смог откровенно ответить Руслану на вопрос, является ли ФП серебряной пулей.
ещё и в безумии... :о(
Серебрянной пули нет!
Эти слова Брукса мы тут повторяли неоднократно (в тех или иных формах)... Почему вы их не заметили? :о(
№ 2711 05-04-2007 14:55 | |
Ответ на »сообщение 2697« (Geniepro)
___________________________
Ответ на »сообщение 2686« (Илья Ермаков)
___________________________
Состояние модулей в ИЯ может изменяться заранее неизвестным образом. Это может как угодно изменять поведение этих модулей - функции, вычисляемые процедурами в этих модулях. Сейчас один результат, через полчаса при тех же входных данных - другой, завтра - третий... Какой-то генератор случайных чисел получается... :о)
Если процедура имеет смысл мат. функции, преобразующей входные данные - то она и будет написана только от входных данных...
Если процедура возвращает некоторую характеристику текущего состояния модуля - то естетсвенно, ее значение зависит от состояния этого модуля. Это тоже чистая функция, но функция состояния модуля. Рассматривайте ее как индикатор некоторого параметра в состоянии модуля ("давление пара" али "обороты коленвала" :-) ).
И в том, и в другом случае работает правило: если процедура написана как функция, с возвращаемым значением, то она не должна иметь побочных эффектов... Увы, в Обероне компилятор это не контролирует, можете, если хотите, "взять на карандаш" этот реальный "пробел". Но в той же Аде такой контроль есть - процедура-функция не может иметь побочный эффект, иначе - по шее от компилятора...
№ 2710 05-04-2007 14:46 | |
Ответ на »сообщение 2700« (panda)
___________________________
>>>Да хоть в 110. Ее все равно быстрее открыть, чем делать File - Open.
А я было поверил Вашей фразе из »сообщение 2668« ;)
>>>Возможно, Вы полагаете, что в обероновских средах нет такой возможности?
Разве я такое говорил? ;)
№ 2709 05-04-2007 14:34 | |
Ответ на »сообщение 2696« (Jack Of Shadows)
___________________________
Ответ на »сообщение 2695« (Илья Ермаков)
___________________________
То же самое и в хаскеле. Можете описать отдельные типы километр и килограмм, и компилятор не допустит их смешивания, потребует явное преобразование.
Вообще-то всё не так просто. В Хаскелле до чёртиков разных способов создания новых типов...
Вот пример, который мне сейчас в голову пришёл:
module ModA (
Kilometers,
Color,
Distance (Distance)
) where
type Color = Int
data Kilometers = Int
instance Num Kilometers where
instance Show Kilometers where
instance Eq Kilometers where
newtype Distance = Distance Int
instance Num Distance where
instance Show Distance where
instance Eq Distance where module ModB (
Kilograms,
Density,
Time (Time)
) where
type Density = Int
data Kilograms = Int
instance Num Kilograms where
instance Show Kilograms where
instance Eq Kilograms where
newtype Time = Time Int
instance Num Time where
instance Show Time where
instance Eq Time where module Main where
import ModA
import ModB
type Velocity = Float
main = do print (red - high) -- Допустимое смешивание типов
print (km + kg ) -- Ошибка: несовместимые типы
print (sec * len ) -- Ошибка: несовместимые типы
print (red - kg ) -- Ошибка: несовместимые типы
print (red - sec ) -- Ошибка: несовместимые типы
print (km - len ) -- Ошибка: несовместимые типы
print (speed / kg) -- Ошибка: несовместимые типы
speed = 100.0 :: Velocity
red = 5 :: Color
high = 50 :: Density
km = 10 :: Kilometers
kg = 20 :: Kilograms
sec = Time 5
len = Distance 2
type создаёт фактически синонимы для имеющихся типов, а не новые типы...
Так что есть способы типизации по имени ( data, newtype), а есть - по содержимому ( type)...
№ 2708 05-04-2007 14:22 | |
Никого не убеждая, описываю ситуацию.
Работаю в проекте которому чуть меньше 10 лет. Средства разработки VC - С/С++.
Количество разработчиков несколько десятков + такой же отдел тестеров. Всего может и за сотню перевалит. Разбросаны по нескольким странам.
Количество c/cpp/h файлов порядка 4500. Всего сорцы занимают 45MB. Т.е средний файл имеет размер 10К или поделив на 20 получаем 500 строчек на файл.
Поскольку проект старый и огромный, то очень часто приходится работать с чужим кодом, более того авторы уже давно не работают.
Отлавливать баги, исправлять, изменять, улучшать в таком коде - это просто наказание. Все действительно начинается с тыканья по функциям и переменным где они определены, инициализируются и как используются. Часы, дни и даже недели в Debug'ере... Code-review, Static Analisis, UnitTesting, Purify и т.д.
"Шпаклюешь" в одном месте прорывает в другом. Жёсткий timing по времени. Release должен выйти вовремя. Проект очень успешный - хорошо продаётся.
Все простые программисты имеют высшее образование и опыт 4-8 и более лет на С/С++ и других погремушках. Все плюются, всех тошнит, все ругают С/С++ (например за проблемы с include'ами).
Но самое интересное, что когда пытаешься объяснить, что это проблема в самом языке программирования и никакие Purify, StaticAnalysis, IDE не могут решить и исключить проблемы в самом языке программирования, далеко не все понимают! Хотят иметь свободу и не иметь проблем! "Плохой дизайн, безрукий коллега, недостаточный Unitest" и т.д. но не средство разработки!
Начав изучение программирования на Modula-2 ещё в школе, я был просто в восторге от её продуманности, простоте и возможностях. Мне не с чем было сравнивать. Я не был знаком ни с Pascal ни с C/C++. Просто программировал на Modula-2. Мне казался он идеальным.
Но со временем, меня начали раздражать не однозначности и с диапазонами и с перечислениями и даже не квалифицированный импорт. Да откровенную глупость написать - не напишешь. Modula-2 достаточно строг, но как всегда - человеческий фактор с которым компилятор сделать ничего не может, кроме как... запретить вообще.
Так что для меня не стало разочарованием отсутствие в Oberon этих и многих других "понтов". Возможно я не понимаю всех причин побудивших Вирта и его команду по убирать "лишнее", но если я в течении 3-5 лет программирования в школе и в универе на Modula-2 почувствовал "дискомфорт" в некоторых фичах, то совершенно логично Вирт, потративший только на ветку Pascal -> Modula -> Oberon - лет 30 и вообще на программирование и разработку компиляторов и всяких там систем - лет 60, наверняка многие вещи прочувствовал гораздо лучше меня и наверное лучше большинства присутствующих на этом форуме (без обид). Я уж не говорю про горе программистов на C++/Java с опытом 7 лет+.
Не забудем и про всякие премии, которые наверное не просто так даются.
Суть не в том, что бы закрыв глаза верить всему, что говорит господин Вирт, а проявить уважение и постараться понять причины. Кажется Вирт и ФЯ занимался - что то не пошло - значит были причины. Какие? Нужно разбираться, а не кричать: "он дурак!".
P.S. Когда пришлось познакомится в разное время с Pascal (для олимпиад), C/C++ (в университете) и Delphi (был один проект) - просто тошнило. От С++ и сейчас тошнит, даже после 6 лет использования в университете и на работе, т.е. дело явно не в не знании его возможностей, а в чем то другом.
P.P.S. Да кстати, в С++ нет поддержки длинных чисел, но благодаря operator overloading, можно получить такой же изящный код как и на ФЯ. Ну так что "кто на новенького"?
№ 2707 05-04-2007 14:20 | |
Ответ на »сообщение 2702« (panda)
___________________________
Я 9 лет разрабатывал на Delphi и никогда не возникало потребности использовать map/reduce/lambda. Но попробовав их на Python и возвращаясь в Delphi мне есть с чем сравнивать. Начнем holy war за ФП?
Священную войну (holy war или джихад) ведут функциональщики.
Оберонщики не оспаривают, что у ФП есть свои плюсы, и что это направление перспективно.
Вопрос ставится о границах применимости этого подхода.
Почему-то этот, IMHO, естественный для любого грамотного человека вопрос вызывает у функциональщиков бурю возмущения.
Ка-а-ак?! У ФП могут быть какие-то границы?! Даешь ФП без границ!!
Такое восприятие и лежит в основе разнообразных holy wars.
Никто так и не смог откровенно ответить Руслану на вопрос, является ли ФП серебряной пулей. Это говорит о многом.
№ 2706 05-04-2007 14:08 | |
Не буду спорить - в плане прихода "масс программистов" Оберон не сильно "безопаснее".
Однако это вопросы уже другого разреза. От орд дилетантов и невежд не спасет никакой язык.
Это проблемы образования и подготовки кадров...
В общем, все это палки о двух концах.
№ 2705 05-04-2007 13:29 | |
Ответ на »сообщение 2701« (Илья Ермаков)
___________________________
Не спорю, что дурной пример, навернули ребята не относящегося к делу...
Не только дурной пример, но и говорящий пример.
Уже который по счету пример, показывающий что оберон совершенно спокойно позволяет писать точно также как писали до него на других языках. Все те же "удобства" для желающих развалиться на диване.
А ведь еще раз повторяю - это не лохи (пока). Пока в обероне тусуются в подавляющем большинстве грамотные программисты. И то зачастую сиюминутное удобство написания берет вверх над грамотной архитектурой, декомпозицией задачи на меньшие и независимые подзадачи.
Что же произойдет если "открыть шлюзы" и пустить к вам армию программистов гораздо более слабого уровня ?
Вы говорили о том что мол оберон их переучит. Не вижу.
Чтобы переучить нужно ставить палки в колеса, делать привычный метод работы либо неудобным (лисп), либо невозможным (хаскель).
Оберон не делает ни того ни другого.
Ему по существу нечего предложить в плане повышения качества кода и надежности программ в неконтролируемой среде (массы программистов)
№ 2704 05-04-2007 13:19 | |
И вообще, уважаемые хозяева ветки сказали, что эта тема им не интересна, давайте завершимся - при своих мнениях :-)
№ 2703 05-04-2007 13:17 | |
Ответ на »сообщение 2700« (panda)
___________________________
Ответ на »сообщение 2678« (Илья Ермаков)
___________________________
Знаете, реализация интересующей функциональности может быть рассредоточена по десятку-другому модулей, откуда ее надо аккуратно "отсечь" и перенести... Вот вам и "найти реализацию по щелчку мышки"... :-)
Да хоть в 110. Ее все равно быстрее открыть, чем делать File - Open.
Надоело спорить не по делу... Каким образом явная квалификация мешает открывать по щелчку мыши? Она всего лишь избавляет от необходимости щелкать для того, чтобы видеть, что откуда. В разработке системных или инфраструктурных частей ПО, особенно компонентного, очень важно видеть, куда и когда идет граф управления... В ФП графа управления нет, там позывов к использованию явной квалификации меньше... А в Дельфе - просто банальная лень написать лишнее слово (кстати, если очень хочется, можно научить среду саму дописывать полный префикс) и "дремучесть", уж извините...
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|