?

Log in

No account? Create an account
Про фп ище - kouzdra [entries|archive|friends|userinfo]
kouzdra

[ website | www.kouzdra.org ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Про фп ище [Jun. 23rd, 2014|10:33 am]
kouzdra
У ФП на сам деле преимуществ два - первое - сильно более удобная и компактная нотация - это само по себе не революция, но сокращение объема кодирования в 2-3 раза довольно сильно повышает и производительность труда и управляемость кода. Другое дело, что индустрии пока проще не повышать производительность, а развиваться экстенсивно.

А второе более важное - c программами на функциональных языках легко работать формальными методами - поскольку модель прозрачная, строгая типизация дает массу информации о том, что может быть, а главное - чего быть не может.

А в pure functional языках еще убрана чуть не главная головная боль всех оптимизационных и верификационных средств - неявные зависимости по изменяемым данным. Примера для - в чем плюс erlang - язычок сам по себе кривоват - именно в том, что pure functional.

Что в частности означает, что перекидывание процесса на другую машину (сколь угодно удаленную) требует лишь разового копирования замыкания. тогда как в большинстве других языков - абю. Все процессы сидят на общем массиве мутирующих данных и фиг ты чего куда выкинешь автоматически - без подсказок программиста и специальной заточки кода под это.

Ну и еще что отсутствует необходимость постоянно обкладывать семафорами все мутации потенциально разделяемых данных теряя на этом перформанс и ловя глюки - но это-то в принципе решается везде использованием pure functional структур - тут просто язык энфорсит эту политику
LinkReply

Comments:
[User Picture]From: m_krokodilov
2014-06-23 07:11 am (UTC)
Я вот C++ с детства обожаю. Правда, писать в последние лет 5 почти не доводилось.

Что до современной функциональщины, то она по большей части производит впечатление чего-то адово перепутанного и искусственного.

Остаюсь с надеждой, что оно не вытеснит ООП, а встроится в него, как уже сейчас происходит в C#/C++/Java/Python/Ruby (лямбды и замыкания даже в JavaScript давно есть).

Как ООП сохранило структуры, а C - наработки ассемблера.
(Reply) (Thread)
[User Picture]From: kouzdra
2014-06-23 07:31 am (UTC)
Функциональщина на сам деле штука простая и логичная - просто очень непривычная (и начинать надо с Ocaml, а не с Haskell - это стандартная методическая ошибка). Те же классы типов можно рассматривать как "человеческий аналог" шаблонов С++ - только без их косяков и криви (и в частности с нормальной раздельной компиляцией, без семантки inline)

Остаюсь с надеждой, что оно не вытеснит ООП, а встроится в него,

Не встроится - потому что самые ценные его фичи туда не встраиваются - Scala - это видимо максимум того, что можно выжать - и получилось нечто громоздкое. Я лично прогнозирую щас возникновение не ОО язычков (Go и Rust я уже упомянул - а они в частности интересны тем, что это не академические, а промышленные языки, хотя и экспериментальные в значительной степени).

И "классика" чем дальше тем больше будет "тянуть вниз" - не давая получить основные выгоды.
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: thesz
2014-06-27 06:35 am (UTC)
Адово перепутанное это в Скале и в OCaml.

В Haskell всё гораздо приличней.

(я сейчас на C# пишу - вот уж где ужас. а кто-то без ума.)
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: _slw
2014-06-23 07:23 am (UTC)
эта компактность возможно играет только по сравнению с текущей мейнстримовой экосистемой жабы.
да и то, скорее всего с развитием экосистемы ФП они тоже будут вынуждены перейти на длинные имена.
а там и анекдотов насочиняют.
один хрен в приличной программе основной объем кода -- это проверки граничных условий, особых ситуаций и внятная реакция на них пользователю и в лог. а тут уже вряд ли что-то удастся поиметь что-то компактное.
(Reply) (Thread)
[User Picture]From: kouzdra
2014-06-23 07:32 am (UTC)
Там не в именах компактность. А именно в "проверки граничных условий, особых ситуаций и внятная реакция на них пользователю и в лог" (включая вылавливание ошибок на этапе компиляции - на удивление много ловит - количество того, что надо проверять в разы меньше - как пример не надо проверять "разыменование нулевого указателя" - этого просто обычно не бывает, а в тех ситуациях, где тебе действительно надо вариант "нет значения" - оно энфорсится на уровне системы типов - то есть забить не получится.

Edited at 2014-06-23 07:34 am (UTC)
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: trilirium
2014-06-23 08:16 am (UTC)
Кстати: а существует ли хоть одна игрушка, написанная на haskell? )))
(Reply) (Thread)
[User Picture]From: orleanz
2014-06-23 08:48 am (UTC)
хаскелл - сам по себе лучшая в мире игрушка (я без иронии. изучать хаскелл гораздо интереснее чем бегать по уровням).
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: trilirium
2014-06-23 09:17 am (UTC)
Но готов спорить, что BFG-9000 в нем нет! ))
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: thedeemon
2014-06-24 12:32 pm (UTC)
http://bysusanlin.com/raincat/ очень няшная, но на современной винде плохо рабоает. На XP и Vista у меня запускалась.
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: krlz
2014-06-23 02:49 pm (UTC)
С ФП есть еще один плюс, это возможность относительно беспроблемного доказательства корректности. Доказывать корректность алгоритмов при помощи систем типа Coq, и Haskell достаточно несложно. С большими системами, конечно, все сложнее. При этом, в императивных языках это становится адом, придумываются всякие separation logics и прочее хрень.
(Reply) (Thread)
[User Picture]From: kouzdra
2014-06-26 09:54 am (UTC)
Да - причем реально польз от этого больше - во-первых сам по себе type inference ловит много семантических ошибок, а во-вторых - во всей оптимизационной науке прозрачность связей в программе очень важна - потому что иначе приходиться действовать по принципу "самого плохого варианта"
(Reply) (Parent) (Thread)
[User Picture]From: pappadeux
2014-06-23 05:47 pm (UTC)
> А в pure functional языках еще убрана чуть не главная головная боль всех оптимизационных и верификационных средств - неявные зависимости по изменяемым данным. Примера для - в чем плюс erlang - язычок сам по себе кривоват - именно в том, что pure functional.

возможно ли такое применить на c++?

т.е. темплейты плюс запрет на изменяемые данные?

вместе с && должно работать
(Reply) (Thread)
[User Picture]From: pappadeux
2014-06-23 09:58 pm (UTC)
например

http://jscheiny.github.io/Streams/

что еще надо? (ну если смириться со страшным синтаксом и многословием)
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: stdray
2014-06-24 12:16 am (UTC)
Субъективно, компактность достигается выбрасыванием лишних сущностей.

ООП - это про:
- делегирование ответственности и сертифицированные способы это сделать (патттерны)
- "безопастность уровня разработчка", ведь любой объект в терминах ООП - потенциальная точка расширения как добавлением узко-специфичной логики (костыль) и наследниками нарушающими инвариант, откуда идут закрытые классы (малая реиспользуемость) и избыточное количество деклараций (интерфейсы, полностью абстрактыне классы). Отсюда же пачка модификаторов и бойлерплейт.
- делегирование ответственности во вне: инъекция зависимостей через конфигурацию (xml spring ioc и ему подобные).
- сильную связанность (coupling), поскольку ООП-методы абстрагирования по спирали приводят к ней раз за разом, в виде того же жесткого каркаса на новом уровне абстракции. При этом растут затраты на отслеживаниее этих зависимостей.
- проблемы с тестированием (в силу предыдущего пункта), поскольку модульные тесты имитируют "архитектуру" системы. Формализм объектов - ДКА, и даже mock-объект должен имитировать его состояния.
- высокий порог вхождения. Несмотря на номинально низкий порог, разобраться в этом зверинце практически невозможно. Пока новички комплексуют от классов с пачкой статических методов, прошедшие этот этап налегают на тулинг и накапливают опыт.

ФП - это про:
- first class citizen функции
- безопастность для разработчика, через иммутабельность и чистоту функций
- решение конкретной задачи
- простое тестирование при отсутствие состояния
- высокий порог вхождения, несмотря на концептуальную простоту и доступность обучающих материалов, разбираться в этом зверинце никто не хочет. Пока неофиты пугаются ауры "научности", новички метаются между языками, книгами и прочим, прошедшие этот этап не имеют возможности применять знания технологии на практике.

ЗЫ: пишу про модульные тесты, потому что не понимаю, что такое юнит-тесты и не пишу их. А затраты на интеграционное тестировние (по моей практике) нивелируют разницу в подходах.

ЗЗЫ: ФП очень про анемичную модель (в терминах ООП). И, субъективно, такой подход проще (банально). Например, такая презентация.

Edited at 2014-06-24 12:30 am (UTC)
(Reply) (Thread)
[User Picture]From: rdia
2014-06-24 04:05 am (UTC)
Почему-то после OCaml'а на C++ программировать физически противно. Фиг знает, как с этим жить и бороться.
(Reply) (Thread)