?

Log in

Про фп ище - 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)
[User Picture]From: m_krokodilov
2014-06-23 07:38 am (UTC)
Я вот пытался F# освоить (который, насколько я понял, OCaml-мутант) - пока всякие рекурсии пишешь, оно красиво, но как только начинатся окошки или работа с данными - всё, приехали, тот же самый ООП-С#, только в OCaml-нотации.

Я по этому вопросу согласен с Талебом - чем старше технология, тем дольше и полезней она проживёт. То есть ООП удобен для написания некоторых задач - он там и будет разрастаться (например, я надеюсь, что следующий C# всё-таки научится концертировать из базового в производный классы целыми коллекциями, и наконец-то вытащат на свет Божий functional requirements - их черновик с версии 2008 в недокументирвоанных функциях лежит). А для тех задач, где он неудобен - будет разрастаться Go, Rust, OCaml и прочиe Scala.
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: ext_1684112
2014-06-23 10:09 am (UTC)
Расскажите пожалуйста, как надо начинать с Окамл. Книжки, пособия ли, где задачи под него брать.
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: tomcatkins
2014-06-23 11:50 am (UTC)
а с sml не лучше? и не только функциональную парадигму, а програмирование и cs вообще.
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: yigal_s
2014-06-26 02:22 am (UTC)
* начинать надо с Ocaml, а не с Haskell - это стандартная методическая ошибка

вопрос от малокомптентного в теме: а почему это ошибка?
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: voidex
2014-06-26 04:30 am (UTC)
А почему надо начинать с OCaml? Если уж учить ФП, то сразу каноничный.
Agda2 ещё хороша, но уже как ЗТ.
(Reply) (Parent) (Thread)
[User Picture]From: thesz
2014-06-27 06:35 am (UTC)
Адово перепутанное это в Скале и в OCaml.

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

(я сейчас на C# пишу - вот уж где ужас. а кто-то без ума.)
(Reply) (Parent) (Thread)
[User Picture]From: m_krokodilov
2014-06-27 07:13 am (UTC)
Как по мне, сложно вообразить язык более предсказуемый, чем 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)
[User Picture]From: _slw
2014-06-23 07:36 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)
[User Picture]From: trilirium
2014-06-23 09:17 am (UTC)
Но готов спорить, что BFG-9000 в нем нет! ))
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: trilirium
2014-06-23 09:49 am (UTC)
Шутки шутками, но мой вопрос про игрушки -- вполне серьезен.

Я могу представить себе алгоритмизацию какой-то чисто вычислительной работы на Хаскелле. В конце концов, для этого он и предназначен.

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

(Так что, вот если кто подкинет мне пример игрушки на Хаскелле (работающей достаточно эффективно) -- я соглашусь, что на нем действительно можно все. )))
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: thedeemon
2014-06-24 12:32 pm (UTC)
http://bysusanlin.com/raincat/ очень няшная, но на современной винде плохо рабоает. На XP и Vista у меня запускалась.
(Reply) (Parent) (Thread)
[User Picture]From: trilirium
2014-06-24 01:48 pm (UTC)
Забавно. Спасибо.
(Reply) (Parent) (Thread)
[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)
[User Picture]From: rdia
2014-06-24 04:26 am (UTC)
> ну если смириться со страшным синтаксом и многословием

Что-то в начале ничего, а ближе к концу страницы уже противно.

Кстати, глаз зацепился за функцию adjacent_distinct - вроде как в традиции называть подобные функции не distinct, а unique.

Непонятно, зачем нужна adjacent_difference, когда есть zip_with (стало понятно - см. ниже про tail).

Почему функция fold называется reduce? Где функция tail? Собственно, понятно, почему tail нет: <
[Error: Irreparable invalid markup ('<streams [...] copiable),>') in entry. Owner must fix manually. Raw contents below.]

> ну если смириться со страшным синтаксом и многословием

Что-то в начале ничего, а ближе к концу страницы уже противно.

Кстати, глаз зацепился за функцию adjacent_distinct - вроде как в традиции называть подобные функции не distinct, а unique.

Непонятно, зачем нужна adjacent_difference, когда есть zip_with (стало понятно - см. ниже про tail).

Почему функция fold называется reduce? Где функция tail? Собственно, понятно, почему tail нет: <<Streams are only movable (not copiable), and moving a stream results in a "vacant" stream>>.

В общем, такой хоккей нам не нужен.
(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)