K>... Есть и несколько другой подход — система типов Хаскеля. Она гораздо мощнее, чем в том же .NET. Единственный минус — если в ОО можно делать "методы-омонимы", т.е. методы у совершенно несвязанных классов, обладающие различной функциональностью, но имеющие одинаковые названия, то в Хаскеле такого провернуть не удастся, потому приходится придумывать кучу префиксов для методов. Но и эта проблема разрешима, т.к. при правильном проектировании такие вещи сводятся к минимуму.
Она решена с помощью квалифицированных имён: [Имя_модуля].[конфликтное_имя].
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
Да, я тоже согласен. Вот только вопрос: если ФП никак не мешает использовать ООП, то зачем ругать ФП?
КЛ>чувствуешь разницу м/у лямбдами и спагетти из лямбд? Ну ладно, тут почти можно отступить.
Ну так если руки кривые, то спагетти можно нагородить на ровном месте любыми средствами.
КЛ>>>4. трудная для понимания программа. см. пункт 3.
K>>Конечно же. Программа на языке, содержащем крутые фичи по объёму меньше, чем на менее мощном языке. Потому средняя скорость восприятия (в строках) такой программы на мощном языке меньше. Надо заметить, что крутой язык — не обязательно ФЯ. Но вот если язык смог правильно позаимствовать из ФЯ хорошие концепции, то это только увеличивает его мощь.
КЛ>Проблема — структурированность. Сам писал на clisp, поэтому есть представление.
И что же, по твоему clisp — чисто функциональный?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
КЛ>>>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.
K>>Кто сказал такую глупость. ...
КЛ>здесь сказали такую глупость и я с ней согласен
В Хаскелле инкапсуляция достигается с помощью системы модулей, которые помимо этого играют роль пространств имён.
А наследование и полиморфизм (специальный) реализованы с помощью классов типов (аналог обобщённых интерфейсов) и возможности для типов данных эти интерфейсы воплощать.
Так что весь ООП-шный инструментарий в наличии.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
K>Да, я тоже согласен. Вот только вопрос: если ФП никак не мешает использовать ООП, то зачем ругать ФП?
да ну не хотелось его ругать Как бы недостатки хотел показать
КЛ>>чувствуешь разницу м/у лямбдами и спагетти из лямбд? Ну ладно, тут почти можно отступить.
K>Ну так если руки кривые, то спагетти можно нагородить на ровном месте любыми средствами.
КЛ>>>>4. трудная для понимания программа. см. пункт 3.
K>>>Конечно же. Программа на языке, содержащем крутые фичи по объёму меньше, чем на менее мощном языке. Потому средняя скорость восприятия (в строках) такой программы на мощном языке меньше. Надо заметить, что крутой язык — не обязательно ФЯ. Но вот если язык смог правильно позаимствовать из ФЯ хорошие концепции, то это только увеличивает его мощь.
КЛ>>Проблема — структурированность. Сам писал на clisp, поэтому есть представление.
K>И что же, по твоему clisp — чисто функциональный?
а вот тут то я и попался
насколько помню с ооп там было бедненько
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, Константин Л., Вы писали:
КЛ>>>PS: просто высказал своё мнение. Вроде форумы именно для этого. Не тратьте силы, чтобы разубедить меня , я либо изменю своё мнение сам, либо не изменю
К>>Ты есть замкнутая система, которая не разумеет чужих мыслей?
КЛ>с каких это пор (разумеет мысли) == (разделяет мнение)?
откуда ты взял "разделяет мнение"?
Каждый имеет право на свою точку зрения и форум есть средство для обменя этими самыми точками зрения.
Не надо загодя собеседника принимать обязательно за противника
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Константин Л., Вы писали:
КЛ>ладно, я имелл ввиду, что мог привести пример понавороченее.
Легко
-- стандартный оператор композиции
-- (.) :: (a -> b) -> (c -> a) -> (c -> b)
-- добавляет спереди единицу арности ко второму аргументу и возвращаемому значению
-- переданной бинарной функции
addArity :: (a -> b -> c) -> (a -> (d -> b) -> (d -> c))
addArity = (.) (.)
-- композитор унарной и бинарной функций
-- f(g(x y))
(.##) :: (a -> b) -> (c -> d -> a) -> (c -> d -> b)
(.##) = addArity (.)
-- композитор унарной и тернарной функций
-- f(g(x y z))
(.###) :: (a -> b) -> (c -> d -> e -> a) -> (c -> d -> e -> b)
(.###) = addArity (.##)
-- и.т.д. рекурсивно
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, konsoletyper, Вы писали:
K>>И что же, по твоему clisp — чисто функциональный?
КЛ>а вот тут то я и попался
КЛ>насколько помню с ооп там было бедненько
Здравствуйте, Константин Л., Вы писали:
КЛ>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.
Отсуствие оных средств не мешает, тем не менее писать чистый и ясный код. Многие алгоритмы записанные в функциональном стиле читаются намного лучше. А качетсво кода завист в первую очередь от программиста. Дурак и на С++ и на Хаскеле макаронный код написать сможет.
Так что отсуствие оных средств просто говорит в пользу гибридных языков. И говорит о том, что на чистых ФЯ тяжело создавать огромные проекты. Но макароы тут не причем. Не надо их с катлетами и мухами мешать.
КЛ>3. запутанная. Как следствие присутствия 1 и 2, плюс спагетти из лямбд и функций высшего порядка. ИМХО сильно ухудшает читабельность и саппорт лиджаси
Спагети как раз обычно без лямбд получаются. Лямбды средство борьбы с морем грязи в коде. Правда опять таки только в хороших руках.
КЛ>5. особенно содержащая много операторов GOTO. Ну тут не в тему. Однако что может быть хуже для читабельности, чем "функций высшего порядка"?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Константин Л., Вы писали:
КЛ>5. особенно содержащая много операторов GOTO. Ну тут не в тему. Однако что может быть хуже для читабельности, чем "функций высшего порядка"? Это ж где? Посмотри на Яву и на ГоФ.. Паттерн Command, интерфейсы Comparator, Runnable и иже с ними — как раз следствие отсутсвия ФВП, точнее, что-то типа эмуляции ФВП через объекты..
<< RSDN@Home 1.1.4 stable SR1 rev. 568>>
Сейчас играет Чур — Карна
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Константин Л., Вы писали:
КЛ>5. особенно содержащая много операторов GOTO. Ну тут не в тему.
В тему,в тему. Правоверный фунциональщик должен знать по крайне мере название работ основоположиков. Во фракции большевиков-лямбдистов особо чтимы
Lambda: The Ultimate Imperative
Lambda: The Ultimate Declarative Lambda: The Ultimate GOTO
Меньшевики-комбинаторщики любят ссылаться на откровения преп. Дж.Бэкуса:
The lambda expression (with its substitution rules) is capable of defining all possible computable functions of all possible types and of any number of arguments. This freedom and power has its disadvantages as well as its obvious advantages. It is analogous to the power of unrestricted control statements in conventional languages: with unrestricted freedom comes chaos.
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, deniok, Вы писали:
D>Да, чистая лямбда — это, конечно, то ещё спагетти. Но, в отличие от goto, немножко лямбды кода не испортит.
Тут как посмотреть... правильно поставленные goto тоже код не портят...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, deniok, Вы писали:
D>>Да, чистая лямбда — это, конечно, то ещё спагетти. Но, в отличие от goto, немножко лямбды кода не испортит. WH>Тут как посмотреть... правильно поставленные goto тоже код не портят...
Лямбда, в отличие от goto, локальна. Поэтому всякое goto — макаронина отсюда куда-то. А лямбда "макаронизируется" только если вкладываем одну лямбду в другую, в третью, etc, что бывает, когда мы пишем код на чистой лямбде (то есть вообще без именованных функций). Ну или когда мы поставили перед собой задачу обфускации
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Константин Л., Вы писали:
КЛ>>>По-моему, чистый фп подход продьюсит спагетти-код
И много ты ФП кода видал? Можно на примерах?
D>>Эээ, залезем в Вики
D>>
D>>Спагетти-код — (1)плохо спроектированная, (2)слабо структурированная, (3)запутанная и (4)трудная для понимания программа, особенно (5)содержащая много операторов GOTO, (6)исключений и (7)других конструкций, ухудшающих структурированность.
КЛ>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.
Да лана. Есть модули, есть стримы. Есть злые монады. Этого вполне достаточно для построения макроархитектуры.
КЛ>2. слабо структурированная. Туда же.
Куда же туда же. Это неправда. Как система будет структурирована — зависит от того, как у человека мысли в голове структурированы. И только. А дурака хоть молиться заставь — один хрен лоб до затылка расшибет.
КЛ>3. запутанная. Как следствие присутствия 1 и 2, плюс спагетти из лямбд и функций высшего порядка. ИМХО сильно ухудшает читабельность и саппорт лиджаси
Саппорт легаси усложняет работа с явням разделяемым состоянием. Которое из-за спагетти-кода может поменяться откуда угодно (в этом и суть спагетти), в результате поведение кода трудно предсказать и сложно выделить границы подсистем.
В чистом ФП нет разделяемого состояния. Не будет и связанных с этим проблем, например спагетти. Это хорошо. Проблем в целом будет меньше.
КЛ>4. трудная для понимания программа. см. пункт 3.
Субъекивно. Что трудно для вашего понимания, может быть легко для моего, и наоборот.
КЛ>5. особенно содержащая много операторов GOTO. Ну тут не в тему. Однако что может быть хуже для читабельности, чем "функций высшего порядка"?
Да что угодно. GOTO, паттерн "визитор", дабл диспатч, а также наследование, примененное не по назначению.
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, deniok, Вы писали:
КЛ>>>>1. плохо спроектированная. Пожалуй, впервые соглашусь с Владом — нету в фп средств для построения макро-архитектуры.
K>>>Кто сказал такую глупость. ...
КЛ>>здесь сказали такую глупость и я с ней согласен
D>Я так и не понял, что там имелось ввиду.
D>В Хаскелле инкапсуляция достигается с помощью системы модулей, которые помимо этого играют роль пространств имён. D>А наследование и полиморфизм (специальный) реализованы с помощью классов типов (аналог обобщённых интерфейсов) и возможности для типов данных эти интерфейсы воплощать.
D>Так что весь ООП-шный инструментарий в наличии.
Ты почти прав. Только ты упустил главное из ООП-шного инструментария. Что такое "объект"?
Объект = АДТ (абстрактный тип данных) + состояние
АДТ = тип данных, определяющийся набором операций над ним. С этим у ФЯ все в порядке.
Объект же не просто АДТ — он имеет состояние и "идентити" — т.е. в системе могут существовать два одинаковых по состоянию объекта с разным идентити. В ОО языках роль "идентити" играет указатель. Идентити — непременный атрибут изменяемого состояния и ООП.
Так вот, в Хаскеле есть АДТ, полиморфизм, и наследование. Но в "объектах" у него нет главного, что позволяет проводить ОО декомпозицию. Это инкапсулированного состояния. Пример: У тебя два объекта, один (А) держит на другой (Б) указатель. Ты можешь изменить состояние объекта Б, при этом А будет указывать на измененный объект. В Хаскеле и в чистом языке вообще так в лоб сделать не получится. Для полноты картины, представь, что у тебя объекты замкнуты ссылками в кольцо, и попробуй изменить их состояние.
В чистых языках состояние можно моделировать стримами (ленивыми списками) — это альтернативный ОО-декомпозиции подход.
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
Как бы недостатки хотел показать 
