Объясните, пожалуйста, разницу между состоянием и функцией

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Я безработный программист и у меня ООП головного мозга.
У меня всё объект и всё состояние. Даже функции и циклы — это объекты со своими методами на которые указывает ссылка в область памяти.
Даже самый распоследний асемблеровский push у меня объект.
Я признаю своё поражение и свою слабость — весь окружающий мир, вся его красота и бесконечность, для меня это лишь объекты и состояния и ничего более. Я, словно обезумевший физик, отрицаю существование самого времени, а точнее определяю его как абстрактное направление от одного состояния энтропии системы к другому состоянию.
Причины моего падения скорее всего находятся в моём прошлом — в детстве лишённом всякой абстракции и математической школы в престижном районе. Весь окружающий мир всегда был слишком реалистичен.
Одновременно с осознанием этой своей ущербности приходит страх — ведь когда-нибудь придётся проходить собеседование, и там молодой и амбициозный техлид, сдвинув в уголок рта дымящую пахитоску и прищуриваться от табачного дыма, обязательно спросит — Что такое функциональная парадигма программирования? При мысли об этом, меня охватывает ужас.
Я знаю, что на форуме много людей которые давно и успешно программируют на функциональных языках, создают, действительно нужные людям, программы.
Я обращаюсь к ним за помощью.
Мне проще всего что-то понять через постановку задачи.
Прошу вас, ради святого Эрланга и равнораспределённой Монгодиби, придумайте мне задачи которые можно и нужно решать именно с помощью функциональной парадигмы программирования.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

придумать учебную задачу которую, по вашему мнению, было бы проще, удобнее, выгоднее решать с помощью функционального подхода (не обязательно языка).
Не будет такой задачи. ФП или ООП или ДругоеП — это только инструменты, если вы не владеете ФП в достаточной мере, то вам любая задача решеная этим подходом будет выглядеть странно, аналогичная ситуация с другими *П.
.
Читайте про подход, пытайтесь его понять, пытайтесь применять на практике и скорее всего некоторые задачи вам будет проще решать этим подходом. У меня есть пару мелких примеров где решение было в ФП-стиле или по крайней мере навеяно ФП-стилем (иммутабельность, код собераетсо как композиция функций, и только потом применяется к данным), но они очень специфичны для конкретного приложения.

Как потративший усилий на получение ответов(а еще больше — молча наблюдая как другие пытались получить ответы) на подобные вопросы у функциональщиков больше чем на заучивание паттернов ООП, могу кратко поделиться результатами:
1. если будете упорно расспрашивать что оно такое ФП, а чем лучше,и проч. то самый конструктивный ответ будет выражен на языке теорката, и мат логики. на этом пути вам без двусмысленной придется узнать что вы идиот. обычное у ФПшников обозначение для неимеющих уверенных знаний теорката и матлогики. на чужих, не фпшных форумах они конечно об такой оценке помалкивают.
1а ООП плохо, мерзко, и т.д. именно если мерять его теоркатом и матлогикой. Если не поняли — то вы идиот.
2. если не зная, попробуете хаскель или функциональную часть скалы, или окамл, и вам понравится — ждет теплая, внимательная помощь. правда, если вы идиот по пункту 1, помощь эта будет как пособие по инвалидности. чтобы перестать быть инвалидом — придется осилить теоркат.
2а другой выход — найти гуру, и полностью ему довериться. как в индийских и китайских религиях — какой бы чушью не звучало, какие бы личные муки не вызывало — делай как гуру сказал! и осилишь теоркат в конце концов!
3. про реальные проекты расспрашивать нет смысла. они конечно — есть. причем, всячески — и логически и демагогически будет указываться на из бОльшую значимость для человечества, чем всех остальных не ФПшных проектов.
Будет и «аргумент из будущего» — «через 5, 10 лет ФП станет обязательным и программист без знания фп — исчезнет как динозавр»
4. почему на ФП лечге писать программы не поймете, в силу п 1. А тем более почему моделировать действительность легче на ФП.
прим* в большинстве случаев идиотом будут называть вас другие идиоты, просто верующие в теоркат, и потому не задающие идиотские вопросы. со временем вы начнете отличать одних фпшников от других — но п1 это не отменит :)

и положительное:
ФП — это способ заработать на хлеб с маслом для математиков, которые в силу разных причин не могут зарабатывать собственно математикой или ее преподаванием. Если нравится математика и хотите чтобы программирование было в одной с ней тональности — идите в ФП.
Имеется ввиду не инженерная математика, а проблематика математики 20го века. с поисками оснований математики, построений метаматематических описаний математики от Бурбаки до МакЛейна. в которые вплетены поиски Фреге, Геделя, Тарского, ...

Добрый день.
Возможно, Вам будет полезно интервью с Саймоном Пейтон-Джонсом (автор/соавтор Haskell) с «Coders at work» [www.ozon.ru/...ail/id/6252312, www.amazon.com/.../dp/1430219483, есть на rutracker].
Там есть и его мысли о сравнении ФП vs ООП.
Он рекомендует для понимания концепции ФП тщательно курить:
— Why Functional Programming Matters
— Can programming be liberated from the von Neumann style?: a functional style and its algebra of programs
.
P.S. Сам ООП-шник, статьи курил, выводы — не в состоянии вербализовать:) Если будете читать статьи — можем сравнить мнения.

Для сравнения концепций ООП vs ФП я бы за минималистическое описание “что такое ООП” взял подход
Peter Wegner “Dimensions of Object-Based Language Design”:
.
object: An object has a set of “operations” and a
“state” that remembers the effect of operations.
Objects may be contrasted with functions, which
have no memory. Function values are completely
determined by their arguments, being precisely the
same for each invocation. In contrast, the value
returned by an operation on an object may depend
on its state as well as its arguments. An object may
learn from experience, its reaction to an operation
being determined by its invocation history.
.
object-based language: A language is object-based
if it supports objects as a language feature.
.
object-oriented language: An object-based
language is object-oriented if its objects belong to
classes and class hierarchies may be incrementally
defined by an inheritance mechanism. That is:
object-oriented = objects + classes + inheritance

Любят апологеты нагнать туману на ровном месте

Если бы искал задачу (а я для себе ищу), то я бы ставил на то, что в типичном ООП-языке (Java) бедная система типов (примитивы + классы с простейшим отношением частичного порядка (иерархии)), а в ФП обычно богаче (Scala/Haskell).
Копнул бы в сторону Hindley—Milner type system и посмотрел где она рулит.
Я пока ставлю на комбинаторы парсеров.
Скажем так — написать быстро и просто полный парсер заголовков HTTP (с куками, multipart/form-data, partial get, ...) для своего карманного HTTP-сервера.
JParsec = порт Haskell -> Java одного из самых популярных parser combinator.
Вот тут они написали весьма хитрый интерпретатор арифметических выражений:


  static Parser<Double> calculator(Parser<Double> atom) {
    Parser.Reference<Double> ref = Parser.newReference();
    Parser<Double> unit = ref.lazy().between(term("("), term(")")).or(atom);
    Parser<Double> parser = new OperatorTable<Double>()
        .infixl(op("+", BinaryOperator.PLUS), 10)
        .infixl(op("-", BinaryOperator.MINUS), 10)
        .infixl(op("*", BinaryOperator.MUL).or(WHITESPACE_MUL), 20)
        .infixl(op("/", BinaryOperator.DIV), 20)
        .prefix(op("-", UnaryOperator.NEG), 30)
        .build(unit);
    ref.set(parser);
    return parser;
  }
.
Решить такую задачу на «чистом ООП» — я просто не знаю как.
.
Задача актуальна, если вы быстро прототипируете свой протокол, скажем поверх WebSocket-ов.
Вот тут они написали весьма хитрый интерпретатор арифметических выражений:
Решить такую задачу на «чистом ООП» — я просто не знаю как.
А вас не смутило что код который вы привели ООПшнее некуда? Например, создание объектов через объекты-билдеры, или код типа «ref.set(parser); // DO NOT FORGET THIS!».

UPD.
Оффтоп.
Прошу прощения за возможно грубое предположение, но
У вас все нормально со ... здоровьем? Вы очень часто отвечаете на свои же сообщение.

Да не жеманничайте Вы так, это называется не грубость, а хамство и невоспитанность. Богдан, Вы взрослый человек, и если хотите плюнуть в незнакомого человека — так плюйте, чего Вы прячетесь за эвфемизмами, вам же не 5 лет.
А пишу посты на свои посты, что бы они были «одной веткой», так как логически связанны.

Да не жеманничайте Вы так, это называется не грубость, а хамство и невоспитанность.
Ах как замечяательно что из всего поста вы ответили только ту часть которая была помечена как оффтоп :)
То есть по делу вас сказать нечего? Тогда бы уж и тусовались в своих меркетинговых темках
А вас не смутило что код который вы привели ООПшнее некуда?
Java — поддерживает только две парадигмы программирования — объектно-ориентированную и процедурную. Поэтому на ней практически любой код использует объекты и/или вызовы «процедур» (статические методы чего-то без полей = Math.sin(), Arrays.binarySearch(), ...), но это не значит, что он «В ООП СТИЛЕ».
Fluent interface — это не ООП-стиль. Это internal DSL в другом стиле.
Fluent interface — это не ООП-стиль. Это internal DSL в другом стиле.
Прочитал бегло, почему ДСЛ не ООП, так и не понял. Расскажите своими словами.
На мой взгляд, вполне ООП — объекты есть, сообщения есть, что еще надо?
JParsec = порт Haskell -> Java
Решить такую задачу на «чистом ООП» — я просто не знаю как.
Секунду, «порт» — это разве не «реализовать логику проекта на другом ЯП/платформе»? JParsec — как раз Java код.
Или из-за <map> в коде это уже не Java как бы?

Это Java код, но не в ООП-стиле. Пришлось перетащить часть сущностей Haskell в Java (JParsec), что бы решить задачу.
Попробуйте решить эту же задачу без JParsec в ООП стиле (классы, объекты, наследование, атрибуты, шаблоны GoF, ...). Задача более чем классическая — интерпретатор выражений.
.
Я привел JParsec, так как решение на Haskell/Scala не могу написать.
.
Хотелось бы разделить сравнение языков и сравнение стилей. Java и Haskell — тьюринг-эквивалентные (оба тьюринг-полные). Так что все что можно сделать на одном — можно сделать и на другом. Так что спор, что такого можно сделать на Haskell чего нельзя сделать на Java — заранее бессмысленен.
Автор то просил ЗАДАЧУ, которую на ООП языке в ООП стиле сделать намного корявее/сложнее/дольше чем на ФП-языке в родном ФП-стиле.
Я стараюсь найти задачу в которой нужны функции высшего порядка, много, сложных. Так как считаю, что именно там проявляется мощь более сложной системы типов ФП-языков в сравнении с ООП языками.

опробуйте решить эту же задачу без JParsec в ООП стиле (классы, объекты, наследование, атрибуты, шаблоны GoF, ...).
Почему JParsec это не ООП как то до сих пор и не раскрыто.

Другая задача: вы хотите свой диалект JavaScript со свой «улучшенной» системой типов (скажем у вас предметная область — пишете браузерные игры под HTML5). Вам нужно:
1. Придумать примочки к JS в терминах предметной области.
2. Написать свой транслятор в обычный JS (с проверкой корректности с точки зрения системы типов ваших новых фишек).
Т.е. вы пишете на этом специальном JS свою логику игры, а потом транслируете это в обычных JS и отсылаете на клиента.
Тут боюсь, вам ООП ничем не поможет.
.
P.S. Ну скажем написать транслятор того же CoffeScript в обычный JavaScript. Или Lua (на нем, говорят, много ИИ для ботов написано) в JavaScript.

Ну скажем написать транслятор того же CoffeScript в обычный JavaScript.
Не поверите но первоначально транслятор с Коффе на ДжС был написан на Руби, дном из самым ОО-языком среди современных, сейчас он переписан на самом себе, так же ОО-языке.
Т.е. вы пишете на этом специальном JS свою логику игры, а потом транслируете это в обычных JS и отсылаете на клиента.
Тут боюсь, вам ООП ничем не поможет.
Частично вы правы. В областях вроде написания парсеров, трансляторов и тд куда важнее знание основных подходов предметной области чем стиль программирования. Но неправы вы в том что (насколько я понял) предполагаете что ООП-стиль тут не уместен, ибо ООП, или ФП, или ЛП в данном случае всего-навсего __инструменты__ для реализации. И их уместность/эффективность определяется сугубо тем насколько хорошо ими владеет человек решающий задачу.
Не поверите но первоначально транслятор с Коффе на ДжС был написан на Руби, дном из самым ОО-языком среди современных, сейчас он переписан на самом себе, так же ОО-языке.
Эээ ... я в замешательстве.
1. Вас, верно, не смущает что Ruby — мультипарадигменный язык (It supports multiple programming paradigms, including functional, object oriented, and imperative.), что он, скажем, поддерживает функции высшего порядка.
2. Не силен в CoffeScript, но разве в нем нет каррирования, частичного применения функций и функций высшего порядка?
1. Вас, верно, не смущает что Ruby — мультипарадигменный язык (It supports multiple programming paradigms, including functional, object oriented, and imperative.), что он, скажем, поддерживает функции высшего порядка.
А вас не смутило то что Smalltalk — это ОО-язык и он поддерживает блоки. Блоки — это то что вы назвали «функции высшего порядка»?
1. Вас, верно, не смущает что Ruby — мультипарадигменный язык (It supports multiple programming paradigms, including functional, object oriented, and imperative.), что он, скажем, поддерживает функции высшего порядка.
А вас не смутило то что Smalltalk — это ОО-язык и он поддерживает блоки. Блоки — это то что вы назвали «функции высшего порядка»?

UPD. Про блоки было не совсем корректное утверджение. Блоки — это то что вы отправляете в то что вы назвали «функции высшего порядка». ... Хотя в общем сами блоки могут быть «функциями высшего порядка».

функций высшего порядка
Лол, а джава не поддерживает?

для меня функциональный код — когда состояние таскается из функции в функцию или же находится в общественном доступе (глобальные переменные, реестр,...)
Даже в нормальных ООП языках так можно писать

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

смотря что считать переменной

И что вы считаете переменной?

Например, название ассоциированное со значением.

Значение изменяемое?

новое значение — новое имя

Тогда это не переменная. Она же не меняется :)

Это Вас путает название. А так вовсе не обязательно

Короче говоря, функциональная парадигма не одобряет использование мутабельных (изменяемых) переменных.

Даже самый распоследний асемблеровский push у меня объект.
Неизлечимо :(

<h2>Почему ФП?</h2>

Мне всё равно ФП это, ООП либо ассемблер. Просто так получилось, что в ФП мире я обнаружил аттрибуты, которых мне не хватал в .NET/Java. Я как пример СТО с поехавшей крышей перешел на Erlang/BEAM с JVM/CLR языков по следующим причинам:

1.Maturity. Более стабильная и неизменяющаяся инфраструктура. Надоело адаптировать свои приложения с выходом каждой новой версии WCF и WPF. Для бизнеса нет ничего более убийственного чем постоянное переписывание. В Java тоже самое постоянное заигрывание с разными OSGi контейнерами, и более новыми и лучшими спрингами и MVC 10. Просто надоело переливать воду из пустого в порожнее.

2. Protopyping. Более быстрая разработка. Действительно прототипировать на Erlang получается быстрее, можно сесть рядом с заказчиком и тут же изменять страницу при нем на стейдже, добавлять чат-окна кнопки и писать логику при нем же. Такое возможно еще только в Clojure, больше нигде такое получить невозможно.

3. Manageability. Более вменяемые программисты, быстрее проходит коде ревью и я могу быстро попоравить все что я считаю упущено. Это происходит во мнгом благодаря тому, что количество кода которое генериурет Erlang программист несоизмеримо мало с Java/.NET языками. Эрланг очень простой язык, мы нанимаем Python, Ruby программистов и они пишут код через 2 недели.

Scala может похвастаться таким размером, но коде ревью скальных проектов делать гораздо труднее. Clojure в принципе тут может сравнится с эрлангом, Clojure код читать приятно, но только если привык к скобочкам.

4. Full Stack. Развитое и полностью самодостаточное окружение. Сначала мы перешли на Riak, RabbitMQ, а потом стали и бизнес логику писать на эрланге и даже Web. У нас все на эрланге, кода стало в 10 раз меньше, управлять проектами стало удобнее, прототипирование продукта делаем за 2 недели. На .NET уходили до 2 месяцев.

5. Capacity. Если нужно байты переложить из одного сокета в другой и делать это в масштабах 10 миллионов коннекций Erlang показывает near to C перформанс (тут пример Flussonic/Erlyvideo котрый стримит десятки гигабит в секунду, что уже говорить об эрланге в вебе или няшных вебсокетах). Линейную алгебру на нем считать не нужно, если все-таки нужно нужно брать сразу Clojure. То для чего мы раньше использовали 10 машин мы сейчас заменяем одной. По перформансу JVM хорошая, Haskell тоже. Но там проблемы управленческого характера. Создать чисто Haskell компанию трудно.

1. maturity — то что вы называете эти словом это простая совместимость. насчет osgi — есть стандарт blueprint и его поддерживают или не поддерживают не в полной мере контейнеры типа virgo, karaf и прочее и нет никакого переписывания компонентов(если вы это имели ввиду), тем более OSGI поддерживает версионность компонента внутри контейнера.А плюсы OSGI — больше чем вы знаете.
2. Protopyping — так это смотря для какого типа приложения. Например если вы пишите чат, стрим сервер — так это возможно Erlang, а если вам нужна распределенная тразнакция так это ява или С#
3. Вообще субъективно — вменяемость не меряется тем на каком языке вы пишите.
4. так на rabbitmq вы пишите поскольку этот JMS вендор поддерживает AMQP протокол, что позволяет связывать ruby и яву, например.
5. здесь вы говорите про то что есть и в яве например, она поддерживает работу с асинхронными сокетами и сделает так же быстро. Так же поддерживается мапинг файлов, off-heap буфера и прочая native хрень.

Ой только не надо мне про Virgo тут :) Я видел и Spring DM, и Virgo, и Glassfish, и бандлинг OSGi приложений. Это ад как он есть. После OTP applications я увидел рай. OSGi — это идея которая абсолютно не работает на практике. Если вы мне будете сейчас тут про Eclipse RCP втирать вот я сразу напоготове держу пост нашего директора: doxtop.livejournal.com/189549.html

Вот пример 2PC имплементации на Erlang которую я нанписал специально для reality_hacker maxim.livejournal.com/422351.html, вот Gen Leader в 70 строчек: github.com/...spot/toy_leader Это только то что писал лично я. PAXOS и RUFT сами в сети найдете. Распределенная транзакция :)

К сожалению вы не знаете о чем вы говорите даже с точки зрения Java программиста. В Java все это есть, но пользоваться этим можно только неспешно, высасывая непрерывно деньги у заказчика.

почему вы здесь упоминаете только elipse RCP ?
Я так понял что ваше знакомство с OSGI — это прочтение этого поста doxtop.livejournal.com/189549.html и всё.
к spring DM — относится только Virgo, и это просто соглашение где искать файл с spring контекстом. Тогда как тотже JBoss имплементит как раз blueprint спецификацию.

То что вы здесь написали maxim.livejournal.com/422351.html, так это вообще не XA, а
скорее всего что-то типа управления лок. траназакцими. Где здесь например recovery?

Вы так же далеки от понимания того что вы пишите, как зверев от сисек семенович.

Мое знакомство с Spring DM и количество лет потраченых на этот бред написано у меня в резюме.

XA — это стандарт интерфейса по которому происходят мессаджинг в рамках 2PC протокола. В данном примере вместо XA используется Erlang RPC. Ядро XA интерфейса это три сообщения:

1. prepare
2. commit
3. rollback

Это все прекрасно и лаконично видно в реализации.

Что бы поддержать дискуссию на нужном уровне нужно хотя бы немного разбираться в вопросе, к сожалению ни reality_hacker ни вы не сможете ее поддержать хотя бы частично. Обычно все скатываются до сисек Семенович и до торговли наркотиками, рассказывая про блокирующие драйвера для Oracle в джаве.

я за конструктивный диалог тоже. И разбираюсь в JavaEE уж получше вас точно.
Да и дело тут в том, что вы тут сидите и чешете свое ЧСВ

Я так понимаю реализации распределенного координатора транзакций на джаве в доказательство своих заявлений, что для этих задач она лучше подходит, от вас не будет?

Что бы поддержать дискуссию на нужном уровне нужно хотя бы немного разбираться в вопросе, к сожалению ни reality_hacker ни вы не сможете ее поддержать хотя бы частично. Обычно все скатываются до сисек Семенович и до торговли наркотиками, рассказывая про блокирующие драйвера для Oracle в джаве.
Версия с другой стороны:
мне понадобилось 200 постов, что бы расчехлить тебя что такое 2PC, потому что твои когнитивные способности не позволили тебе понять этого по статье в википедии: maxim.livejournal.com/...783956#t2783956
После того как ты 10 раз переписывал свой гавнокод, который ты очевидно даже запустить хотя бы раз не удосужился, я тебе ответил что такое может написать даже школьник, но этот код применительно к обсуждаемой задаче применить не удастся, т.к. у тебя нету неблокирующего драйвера к ораклу и MQ.
На что ты начал разговаривать матом, потер мои конменты и забанил меня в своем бложике.

Есть и другие проблемы, например тут какой то человек жаловался что с долгоживущими потоками у ерланга совсем бяда, оно отжирает по 2ГБ РЭМ и благополучно умирает. Или например не факт что эрланг из-за своей тормознутости смог бы показать нужную мне производительност.

Вроде ж нашли были неблокирующий механизм, опять потерялся где-то?

Ну да, потоки эрланга жрут же куда больше потоков ОС. Поэтому Эрланг потрачен.

Та нет, не нашли. Иначе зачем бы ты мои коменты тер и банил в бложике?

Как же, а это что:

1. Oracle. Для построения внешних Транзакшин Менеджеров Ораклом предусмотрен PL/SQL пакадж DBMS_XA, который работает по TCP соединению. www.oracle-base.com/...ms_xa_11gR1.php Документация на этот XA интерфейс для мидл-варе 2PC тут: docs.oracle.com/...xa.htm#BABDCHJJ

Та кто тебя банил, расслабься, все твои каменты на месте иди собери их.

Как же, а это что:
1. Oracle. Для построения внешних Транзакшин Менеджеров Ораклом предусмотрен PL/SQL пакадж DBMS_XA, который работает по TCP соединению. www.oracle-base.com/...ms_xa_11gR1.php Документация на этот XA интерфейс для мидл-варе 2PC тут: docs.oracle.com/...xa.htm#BABDCHJJ
И где там неблокирующий АПИ?
Та кто тебя банил, раслабься.
Ну ты и врун

Ну вот и все, дискуссия вернулась на уровеь DOU. Асинхронный API для внешних транзакшин координаторов оказался блокирующим.

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

Ты пробовал DBMS_XA пакет или как всегда просто каменты для статистики постишь?

Мне лично это все равно. Если ты считаешь что DBMS_XA по TCP соединению может что то блокировать, это твое право так считать. Эрланг гавно, Джава FTW :)

Когда на DOU придет кто-то кто кто знает что такое внешний распределенный координатор транзакций тогда продолжим беседу.

Дискурс OOP vs FP свелся к тому пробовал ли я оракловский PL/SQL пакет DBMS_XA? :) Что-то не видно мощи вашей убогой джавы.

PL/SQL ведь декларативный язык программирования :) Даже 5000 потоков которыми ты заткнул дырку встроенного XA в оракл это заслуга 64-битного пространства ОС.

Где джава павер?

А такой хороший топик был...

Мне лично это все равно. Если ты считаешь что DBMS_XA по TCP соединению может что то блокировать, это твое право так считать.
Вот тебе пример как это делается на уровне АПИ OCI драйвера docs.oracle.com/...2bas.htm#446515 , а теперь пруфлинк пожалуйста что ерланг драйвер на который ты ссылался поддерживает этот режим. И пожалуйста доимплементируй тогда проверку состояния выполнения запроса в своем гавнокоде. И потом если ты его удосужишься хотя бы раз запустить с реальной базой, мы перейдем к MQ, а потом к тестам на производительность. А пока у тебя детский сад какой то получается.

Ще подумай в сторону XSLT компілятора, спробуй написати компілятор для застосування якогось простого XSLT над якимось XML.

Попробуй написати парсер HTML документа на ФП і на ООП, для прикладу береш якийсь сайт, де є, скажем, результати матчів ліги чемпіонів, спробуй їх спарсати і віддати в якомусь іншому форматі, наприклад JSON.

Возможно вы имеете ввиду объект с состоянием и поведением? Поведение — это набор методов(действий), которые вы можете применить к объекту, моделерующему сущность
реального мира(предметной области). После выполнения метода, объект может менять своё состояние. в ФП программа — это набор операций меняющих состояние программы, при этом нет side effects и соблюдается referential transparency. Так же стоит упомянуть, что ООП дизайн предлагает отделать поведения от доменных объектов и реализовать поведение в отдельных сервисах, что по своей сути является процедурным подходом.

Про это много сказано. Если у вас есть задача при виде которой вы стали бы скачивать инсталляцию Скалы или Хаскеля, то приведите её, пожалуйста.

Нужно написать LDAP сервер. Я беру скачиваю Erlang и пишу прототип за пол часа. Нужно написать систему которая превращает программы в Verilog описания для программирования FPGA, я беру скачиваю Scala/Haskell/OCaml. Если я возьму что-то другое я буду просто безумцем.

Хорошо, но мне кажется, что это такая узкая область. Сколько людей в мире занимаются этим?
Меня скорее интересует более камерная задача.
Пожалуй, параллельные вычисления могут быть такой задачей.

Именно поэтому в мире «откопали» ФП из 60-х.
Потому что уперлись в диаметр лазера и размер дорожки при производстве процессоров. Следовательно возникла потребность в канкаренси вычислениях, функциональных алгоритмах без глобального состояния и немутабельных структурах.

Да, что там этот космос, о чем это я, я же на DOU.

Давай кто быстрее веб чат напишет я на Эрланге или ты на ASP.NET.

Я не буду писать, залью готовый из сотни. Дольше выбирать буду. Вопрос не в этом.
Чат чату рознь. Возможно, чат на миллион юзеров действительно гораздо ближе к ФП чем к ООП. Я вот только пока не пойму как его писать что в ООП что в ФП

Для ООП в зависимости от количества юзеров применяются разные подходы ? :)

Разумеется. Каждый объект это память.

Да собственно говоря об этом и речь. Чат на миллион юзеров с их состоянием никто не напишет легко. Если юзер это не объект, а функция — тут дальше мне надо думать.

Отлично вот моя версия:

-module(chat).
-compile(export_all).
-include_lib("n2o/include/wf.hrl").

main() ->
      [ #dtl { file="index", 
           bindings=[{title,"Chat"},{body,body()}] } ].

body() ->
        {ok,Pid} = wf:async(fun() -> loop() end),

      [ #span    { id=title, body="chatroom name: " },
        #textbox { id=userName, body="Anonymous" },
        #panel   { id=chatHistory, class=chat_history },
        #textbox { id=message },
        #button  { id=sendButton, source= 
                          [ userName,message],
                            body="Send",
                            postback={chat,Pid} } ].

event({chat,Pid}) ->
        Username = wf:q(userName),
        Message = wf:q(message),
        Terms = [ #span { text="Message sent" }, #br{} ],
        wf:reg(room),
        Pid ! {message, Username, Message}.

loop() ->
        receive { message, Username, Message} ->
             Terms = [ #span { body=Username }, ": ",
                 #span { body=Message }, #br{} ],
             wf:insert_bottom(chatHistory, Terms),
             wf:flush(room) end, loop().

DTL MVC.
Erlang DSL.
Бродкаст 300 тысяч пользователям за 1с.
WebSockets с фолбеком в XHR.

Это читерство

-module(chat).
-compile(export_all).
-include_lib("n2o/include/wf.hrl").

Тогда это тоже

using Microsoft.AspNet.SignalR.Hubs;

Это тропинка никуда не приведет. Если сравнить SignalR и N2O то тут тоже окажется полный Win.

Я тоже подозреваю, что ASP.NET стек проиграет по производительности и максимальной нагрузке (хотя тут уже решает архитектура, а не технология), но чисто ради интереса — по каким критериям будет полный Win?
(спрашиваю для самообразования, а не с целью холивара)

Давай кто быстрее веб чат напишет я на Эрланге или ты на ASP.NET.
Не зарекайтесь. В MVC 4 нормальная такая поддержка асинхронности.

если кто-то возьметься меряться с функциональщиками, прогоните через MVC 5 или WebApi2 уже лучше)

Нет смысла :) Конечно, WebAPI — это правильное направление движения (уменьшаем накладные расходы по максимуму), но ФП по умолчанию даст фору ООП на параллельных задачах. Другой вопрос, что нужно различать высокую нагрузку и параллельные вычисления.

У меня опыт программирования в .NET больше 10 лет, я писал еще на .NET 1.0 CTP. Ушел с F# по причине очень убогих инструментов, надоело загнивать на загнивающих платформах, где принято переливать из пустого в порожнее. Даже MVC 10 тебе не поможет.

Когда с помощью WebSharper повторишь этот пример и приблизишься по капасити хотя бы в два раза меньше, дай знать.

Характеристики сервера(ов) остались?

Можешь использовать свой ноутбук.

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

Можете коротко дать основные таски?

зачем? если конкретно хотите знать что реализовано на скале гугль вам в помощь.

Мне конкретно хотелось бы знать не что, а почему? Примеров когда за выбором стека стояла поехавшая крыша лида — пруд пруди.

если найдете почему — напишите здесь, будет интересно.

Вот пример возьмите разработку трейдинг системы
Обезьяны не делают различий межу ФП и ООП, но их трейдинг стратегии вполне конкурентоспособны. Какая разница, на чем вести разработку трейдинг системы? Да хоть на бейсике при условии, что за это платят.

В твоей статье не было ни трейдинг систем ни обезьян. Читать учись!

Там же написано что кот тоже переосторожничал и слил ДоуДжонсу и СП500.

Кстати у этого Дениса Попова профайл на ютубе почему то называется Виктория Пахомова. Ахтунг пацаны!

ноги тебе в рот. я — нормальный.

ООП дизайн предлагает отделать поведения от доменных объектов
Тут, как я понимаю, существует две религии:
1. Anemic Domain Model — www.martinfowler.com/...omainModel.html
2. Domain Driven Design.
.
Вы описали первую модель. Для WEB-приложения — это адекватный дизайн, так как запрос проходит 3-5-7 уровней от TCP с клиента до TPC на базу. В итоге логика размазана по этим уровням (валидаторы, DAO-шки, мапперы, ...).
Я не адепт DDD, однако тяжело с Вами согласиться, когда смотришь на внутреннюю структуру (объектно-ориентированную) большого фремворка (Hibernate скажем). Нет там четкого уровня сервисов.

Да вам впору романы писать, батенька (а не функции)

Современные технологии написания того и другого неотличимы практически.

Ви тільки що описали суть ООП і чому воно так часто нагадує графоманство, а не інженерний підхід.

Якщо серйозно: об’єкт об’єднує в собі забагато речей, які часто краще розділити (стан, значення, поведінку, ефекти і т. д.), які мають бути ортогональними, а не поєднуватись в одній сутності, яка веде себе в різних ситуаціях по-різному і вимагає від програміста додаткової дисципліни (якою в випадку ООП наділені тільки генії, а нам потрібні не генії, а software engineers, які можуть застосовувати усталене наукове знання, а не тільки фольклор). «Підвищення рівня абстракції», сподіваюсь, для вас не порожній звук?

ФП дозволяє явно відділити нові грані абстракції, зробити їх більш ортогональними, застосовувати лише той інструмент, який потрібен для задачі, а не, для прикладу, тягнути абстрактні класи із усім GOOP для того, щоб визначити лише поведінку.

Аргумент про те, що ФП «не користуються» — це казати приблизно те саме, що «я і на асемблері так напишу, покажіть мені цих упоротих ООП-ників, які вважають, що треба щось абстрагувати і зав’язли у своїх високолобих абстракціях».

Я это всё понимаю и сам мог бы написать. Но мне нужна конкретная, серебренная пуля в виде задачи. Пока ближе всего это параллельные вычисления.
Что касается многоэтажных абстракция — то, полагаю, они никуда не исчезнут независимо от подхода, не?

Не плутайте abstraction і complexity. Те, що в ООП називається «абстракцією» — це насправді часто багатоповерхова complexity. Побачити ж різні грані в самій семантиці, а не намагатись класичною механікою описати квантовий об’єкт — це те, про що ФП.

Щодо задач, то всі ці ООП-шні ентерпрайзні монстри мені нагадують те, як писали операційні системи для IBM у 60-их роках на асемблері, аж поки люди не зрозуміли, наскільки це простіше і продуктивніше на Сі. Там, де сотні програмістів колись мучились над заморочками бездонної Job Control Language і керуванням пам’яттю із оверлеями, тепер було все просто і ОС із юзерспейсом могли написати двоє-троє людей.

Я аж пустив скупу чоловічу сльозу, це як «Страждання молодого Вертера», а можливо, і сильніше.

Я признаю своё поражение и свою слабость — весь окружающий мир, вся его красота и бесконечность, для меня это лишь объекты и состояния и ничего более.
Для моделирования ООП подходит гораздо лучше ФП. Но есть задачи оторванные от окружающего мира.

Я ФП понимаю как набор инструментов и концепций, которые позволяют избегать лишних сущностей и взаимодействий => упрощают код.

Вот например задача: Из массива интов выбрать все элементы больше 10, умножить их на два и выбрать из получившегося элемнты больше 30.

Функциональное решение:

var result = arr.Where(i => i > 10).Select(i => i * 2).Where(i => i > 30).ToArray();

Императивное решение:

var tempArr = new List<int>(); foreach(var i in arr) { if(i > 10) arrGreater10.Add(i); } foreach(var i in arrGreater10) { i *= 2; } var result = new List<int>(); foreach(var i in tempArr) { if(i > 30) result.Add(i); }

трошка не про то здається.

Я тоже думаю что трошки не то. Есть ли короткий код который мог бы показать ту разницу в подходах?

Нет. Есть задачи, для которых ООП подходит лучше и аналогичный ФП код будет уродлив. Есть наоборот. Кроме того, многое зависит от возможностей языка. В ОКамле есть удобные составные типы и паттерн матчинг, но нет причин считать их чисто функциональной фичей (хотя в императивных языках я не встречал аналогов).

Очень грубо: в ФП отсутствует изменение состояния программы. То есть, программа — это последовательность функций, которые что то принимают на входе, передают друг-другу и возвращают. Очень удобно для юнит тестирования и многопоточности.

Приведённый тобой первый код является синтаксическим сахаром над вторым кодом. Во всяком случае, в величайшем языке всех времён и народов C#. По моему скромному мнению, использование методов расширения с интерфейсами и синтаксического сахара для делегатов не может являться сущностным отличием двух столь громко провозглашённых парадигм программирования.

Да при чём тут это?!

Так, ладно. Какого типа аргумент принимает Where?

Лямбду покрывающую обобщённый делегат.

А делегат — это без пяти минут функция первого класса. В чём собсно и выражается суть ФП — манипуляция функциями вместо манипуляцией состоянием.

Формально ты прав, но если всё это развернуть, то мы увидим ООПэшную примитивщину вместо сияющих вершин ФП.
И задачи по прежнему нет. Перенос синтаксиса из компилятора в мозг программиста не является богоугодным делом.

Формально ты прав, но если всё это развернуть, то мы увидим ООПэшную примитивщину вместо сияющих вершин ФП.
Да какая разница? Ты ещё до ассемблера разверни, где ООПешная примитивщина превратится в процедурную примитивщину. Мне по барабану, что происходит на низком уровне, это — и есть смысл языков высокого уровня.

Ну ладно, типичная задача — сделать парсер текста.

Ну скажем парсер формул. Тебе дают формулу — и аргумент — ты вычисляешь. Попробуй решить на C# в чисто ООП стиле, а потом на F# в чисто ФП стиле.

Я думаю это не туда. Формула это дерево операций — его нельзя парсить независимо.

Вот текст возможно ближе к нужной задаче. У парсера текста фактически может не быть состояния, а только результат.

Хотя, может и дерево/формулу тоже можно.

Ну суть. В общем парсеры часто пишут на ФП. В том числе — компиляторы.

код и так короткий же, просто 3 трансформации вместо одной, нету соблазна заюзать перменные блокеры при распаралеливании и лишних обьявлений нет.

Сделать код менее читаемым — это не может быть настоящей задачей для функционального языка программирования.

Относительно блокеров — задумался.

Почитайте статью Евгения Кирпичева про Мутабельное состояние все-таки, перед тем, как отвечать в своем иронически-саркастическом стиле. Этот стиль хорош для людей, которые хоть что-то знают, вам он не подходит.

Дорогой друг, я точно знаю, что бесплатная раздача характеристик окружающим не самая конструктивная манера ведения диалога. В ваших ответах есть только намёки и ссылки на тот ответ который я интуитивно считаю правильным, но также нет конкретики. А по намёкам и ссылкам я сам большой мастер, что, как вы правильно заметили, не делает меня профессионалом. Кроме того, если вы кого-то считаете сущеглупым и никчемным, то нет никакого смысла метать тут бисер. Удачного дня.

Функциональное решение:
var result = arr.Where(i => i > 10).Select(i => i * 2).Where(i => i > 30).ToArray();
Во-первых, не функциональное решение, а вполне ООП-шное (цепочка объектов, оплучающие сообщения :) )
Императивное решение:
var tempArr = new List<int>(); foreach(var i in arr) { if(i > 10) arrGreater10.Add(i); } foreach(var i in arrGreater10) { i *= 2; } var result = new List<int>(); foreach(var i in tempArr) { if(i > 30) result.Add(i); }
Проблема этого кода не в императивности, а в том что код структурирован по другому. По факту, оно не сильно отличаетсо от вашего «функционального решения».
Функциональное решение не начиналось бы с «arr.Where», а выглядело бы как применение __компизиции функций__ к данным (arr)
Во-первых, не функциональное решение, а вполне ООП-шное (цепочка объектов, оплучающие сообщения :) )
Э? Я им функции передаю.
Функциональное решение не начиналось бы с «arr.Where», а выглядело бы как применение __компизиции функций__ к данным (arr)
Согласен, но я не могу написать такое на C#. А на F# - мог бы:

arr |> Array.filter (fun i -> i > 10) |> Array.map (fun i -> i * 2) |> Array.filter (fun i -> i > 30)

или так

let method = Array.filter (fun i -> i > 10) >> Array.map (fun i -> i * 2) >> Array.filter (fun i -> i > 30)
method arr
(нет компилятора под рукой, что бы проверить)

Но Альберт такое не поймёт.

Э... я кажется перемудрил с литературной частью. Я юзаю F# и R, бро.

Тогда к чему ненужные вопросы?

К тому что C# не даёт мне его использовать, несмотря на явную необходимость. Ничего кроме сокращения синтаксиса и кучи либ я пока не увидел.
Если алгоритм параллельный, то какая разница на чём его писать, а если нет то и F# не поможет.

Да, C# ФП слабовато поддерживает.

Если алгоритм параллельный, то какая разница на чём его писать
Иммутабельность.
а если нет то и F# не поможет.
Лады. Абстрактная задача — реализовать бинарное дерево. Попробуй на C# и F#.

Почему абстрактная? Вполне конкретная. Ок.

Э? Я им функции передаю.
Что-то мне подсказывает что передаете вы им таки объекты (с одним методом) :)
let method = Array.filter (fun i -> i > 10) >> Array.map (fun i -> i * 2) >> Array.filter (fun i -> i > 30)
method arr
(нет компилятора под рукой, что бы проверить)
Но Альберт такое не поймёт.
А тут дело не конкретно в ТСе.
Дело в способо мышления, при раблоте с ФП оно у вас должно быть просто другим.
Посмотрите на библиотеку underscorejs.org , ее считают как бы «ФП утилитами для джаваскрипта». И в общем это правда. От только писали ее люди не с ФП мышление, банально функциональщик бы первым аргументом передавал бы функцию, а не данные.
Я вам даже больше скажу, гадая по фотографии и по постам местных лидеров ФП тусовки, __мышление__ у них так же не ФПшное, они просто пишут на ФЯП и этот ЯП накладывает на них некоторые ограничения.
Что-то мне подсказывает что передаете вы им таки объекты (с одним методом) :)
Да чи не пофиг, что там передаётся под капотом. На моём уровне я им передаю функции, а вот что это превратит компилятор меня не касается. Любой ФП код разложится до имеративного ассемблера.

Принимая во внимание тот факт, что Альберт Толоконников интересуется биоинформатикой и нейронными сетями, данный вопрос звучит как минимум сранно.

1. www.youtube.com/...h?v=GUmcl36K73U
2. www.slideshare.net/...vin/ss-15351640

Ведь всем известно, что объем вычислений, как сам автор рассказывает в своих рефератах, колоссальный, а следственно должен хорошо параллелится между громадным количеством вычислителей и памятью. Именно здесь до неприличия хорошо показывают себя массивные парралельные и конкурентные вычисления и функциональная парадигма.

В условиях невозможности обработки всех вычислений в огранниченном пространстве одного вычислительного устройства и памяти приходится прибегать к распределенному состоянию и равнораспределенным назрузкам с применением map/reduce алгоритмов которые не владеют информацией о глобальном состоянии.

Поскольку количество вычислений громадное и даже всем известная система о 5000 потоках и семафорах не справится с такой задачей приходится признать, что конкрутные системы основанные на исчислении процессов и незаслуженно забытая теория массового обслуживания, что называться do the job по координации вычислительных коммуникаций. Особенно это важно именно при моделировании больших нейронных сетей, как в Blue Gene, а также в задачах фолдинга протеинов.

Несмотря на то, что большинство фреймворков используют OpenMPI (Blue Gene), все то мы прекрасно знаем. что на самом деле старый добрый мессадж пассинг для С++, рожденный из исчисления процессов.

Список рекомендованной литературы для самостоятельного ознакомления:
-----------------------------
[1]. fprog.ru/...-mutable-state
[2]. www.amazon.com/...e/dp/1461444624

Я конечно мог бы сказать, что отрицание формальной логики является отличительной чертой всех апологетов функционального программирования, поскольку если кто-то интересуется нейросетями и биоинформатикой то именно ему как раз и следовало бы задаться вопросом о возможных вариантах моделирования своих вычислений, но в нашем примитивном ООП мире, добродетель это не пустой звук, и поэтому я просто скажу — спасибо.

дуже крута стаття www.flyingmachinestudios.com/...-hickeys-brain десь троха в тему. щодо задач — то підходить будь яка задача, в котрій треба шарити якісь ресурси між потоками.

Підписатись на коментарі