Nim логичнее сравнивать с Go, Rust, Crystal.
Язык интересный, но стабильной версии пока нет, да и библиотек пока тоже немного. Причём ощущение, что разработчики слегка подзабили в этом году… После выхода версии 0.13 уже 5 месяцев никаких новостей от них не слышно. Коммиты есть, но активность в разы меньше, чем в прошлом году.
Я этого и не говорил. Я говорил про то, что веб-разработка пошла сначала по пути ООП, а не сразу по ФП, и это во многом было именно веяние моды. Сейчас мода поутихла и появляются более уместные решения. Ну не является обработка потока изолированных входящих запросов задачей, подходящей для ООП, т.к. у них тупо нет никакого shared state в памяти.
Только вот теперь непонятно, зачем такое громкое название было давать — ФП, когда большинство улучшений (по сравнению с ООП) можно было бы реализовать в рамках несколько видоизмененного ООП
1) ФП появилось лет на 10-15 раньше, чем ООП
2) то, что на ОО-ЯП можно писать в функциональном стиле не меняет ОО-парадигму, просто код перестаёт ей следовать
3) Интеграция обеих парадигм в рамках одного языка и так уже идёт, причём давно уже
но если забыть на секундочку ФП, то без ООП становится совсем сложно
Это от масштаба проекта зависит на самом деле. 80% сайтов вообще просты до безобразия… просто мы тут их не обсуждаем :-)
ООП успешно дает доступ к долгоживущему глобальному состоянию, такому, как база данных, такими средствами, как ORM
По факту, ORM — это ещё одно следствие моды на ООП. Данные в реляционной БД — это данные, а не объекты. Как следствие OR impedance mismatch и разнообразные статьи типа "ORM is an anti-pattern".
За эти миллисекунды веб-приложение успевает пропустить запрос по конвейеру прослоек различных предварительных обработчиков...
И вот Вы перечислили больше десятка действий и ни одного объекта. Когда задача описывается через действия — это как раз признак того, что она больше подходит для ФП, чем для ООП. В случае обработки веб-запросов объекты создаются только чтобы вызвать какие-то их методы, а потом напрячь GC. Советую Вам книгу Programming Phoenix, чтобы посмотреть как эта задача решается без объектов.
ООП здесь помогает упаковать все в удобный объект.
точнее вместо того, чтобы функцию поставить в очередь, требует сначала обернуть её в класс
А если закрыться в своей коморке и ни с кем не общаться, то да, можно не использовать никаких абстракций и каждый проект писать с нуля.
Абстракции и повторное использование — это вещи, слабо связанные с ЯП и с парадигмами программирования. И возможны они везде, было бы желание. А если нет желания, то и в ООП их не будет.
При том, что ООП хорош для задач, где нужно управлять глобальным состоянием программы в оперативной памяти. Взять тот же GUI, как его инстанцировали при открытии программы, так он и продолжает существовать пока программу не закроешь, и у каждого контрола свои атрибуты и обработчики событий. Удобно для ООП? Конечно!
Проблема в том, что ООП превратили в культ карго и создают объекты везде где ни попадя, просто потому что так принято.
Я понимаю, хотя списочек там реально заслуживающий внимания, я несколько новых для себя нашёл.
Дело не в обобщении алгоритмов, а в том, как определяется тип объекта.
Дело как раз в том, что можно написать обобщенный метод/функцию, без явного указания типа/интерфейса параметров в сигнатуре метода. В ООП для подобных методов придётся использовать явные интерфейсы.
Функциональные примеси, они не в ООП. Они в языках программирования.
Верно, я имел в виду ООП-языки.
Это говорит лишь о том, что ОО-парадигма не является ответом на все вопросы
+1, у любой парадигмы есть свои границы применимости.
И даже там где одна парадигма применима, другая может иметь более удобные средства. Так что по-хорошему программист должен быть знаком с многими парадигмами, чтобы делать осознанный выбор под конкретную задачу, а не просто по привычке.
Я возможно Вас слегка расстрою, но утиная типизация — это часть парадигмы обобщённого программирования, к ОО-парадигме она никаким боком не относится :-)
Метапрограммирование — это тоже не ООП, строго говоря. Вообще рекомендую ознакомиться со списком парадигм программирования, там много интересной информации.
Что касается ООП, попробуйте хотя бы для себя, абстрагируясь от привычек, ответить на вопрос: при каких условиях неудобно применять ООП?
Много раз замечал, как и я, и другие, познакомившись в теории с новой технологией или языком, не знают как к ним подступиться.
Мне кажется, проблема статьи в том, что большинство читателей ещё не познакомились с Elm. Лучше про сам язык расскажите и в чём преимущество его использования по сравнению с другими технологиями типа AngularJS, ReactJS и т.д..
Само по себе ООП — не решение. Важно то, как оно реализовано в конкретном языке.
Насколько я помню, есть всего 3 реализации ООП — на основе классов, на основе прототипов и на основе акторов.
C# ранних версий — это шикарный пример реализации ООП на основе классов, а вот начиная с 3-й версии туда начали добавлять ФП и прочие не ООП-концепции.
Из различий реализаций ООП на основе классов, Вы упомянули только множественное наследование, которое по холиварности не уступает goto, поэтому в большинстве реализаций отсутствует )))
сколько абстракций он держит в той же Джанге, и, наверное, в этих ваших рельсах…
А задумайтесь сколько из этих абстракций реально нужны, чтобы обработать запрос? именно из-за усложнения простых вещей "за долю секунды происходит столько всего, что в голове не удержишь". Вы догадываетесь сколько объектов создаётся для обработки тривиального GET /page/permalink? Хотя по сути Вам нужен 1 объект класса Page и то он сам Вам нафиг не нужен, Вам нужны данные из БД, но как же, без ORM никуда..
@Cryvage пишет о том, что можно ОО-язык использовать в функциональном стиле. Т.е. данные о состоянии объекта передавать только конструктору и объявлять на них только геттеры, чтобы даже у методов объекта не было возможности повлиять на его состояние. Тогда получится своеобразное замыкание как в ФП.
Но чтобы так писать на ОО-языке всё равно надо уже расширить своё мышление функциональной парадигмой :-)
Вы во многом правы, но не считаете ли Вы, что функциональные примеси в ООП демонстрируют слабость ОО-парадигмы? По сути даже создатели языков программирования, признают чистое ООП недостаточно удобным. Остался ли хоть один современный ЯП, в котором есть только чистое ООП и ничего больше? Так чтоб никаких лямбд (только Strategy), никаких foreach (только Iterator) и т.д.
Но он далек от серебрянной пули и уж точно не замена ООП
Что Вы как ребёнок всё в серебряные пули верите…
ФП — это парадигма программирования и она предоставляет свои инструменты для решения задач. ООП — другая парадигма, в идеале их области применения могли бы не пересекаться, но на практике одну и ту же задачу можно решать в рамках и той и другой парадигмы.
Мы тут обсуждаем конкретно веб-разработку, а не всё подряд. Если вспомнить как ООП попало в веб-разработку, то очевидно, что это было мотивированно больше всего модой на ООП, т.к. весь практический смысл этой парадигмы теряется для программ, которые отрабатывают за долю секунды.
А чего его представлять то, на самом деле полно мультипарадигмальных языков.
Особо отличился Oz — он одновременно поддерживает 7 парадигм программирования :-)
И Вы правы, разные парадигмы не должны мешаться друг с другом, но их можно использовать в разных частях программы.
Rails сам по себе тоже поддерживает многопоточность, ещё с 2008 года. А толку то? Вопрос в том какой процент людей пишет сторонние библиотеки и свои приложения в расчёте на многопоточность.
Так что это не преимущество ФП, а недостаток конкретного ОО языка.
Могу с Вами поспорить на эту тему… проблема именно в ООП, а языки подстраиваются, тупо встраивая некоторые паттерны непосредственно в синтаксис. Классический пример — паттерн Iterator от GoF, сейчас уже сложно найти язык в котором не ввели его поддержку на уровне синтаксиса. Что касается, Python, то он, как и Ruby, не является строгим ОО-языком, а поддерживает множество парадигм. Поэтому Вы можете решать на нём задачи в том числе и в функциональном стиле (возможно даже не подозревая об этом). Чисто ОО-подход — это применение паттернов: GoF, PoEAA, Applying UML and Patterns и т.д.
Код очень простой: скобки в скобках. Но все равно ничего не понятно, я не могу визуально отделить код от данных.
это в Lisp-подобном языке то? там в принципе нет разделения на код и данные by design :-)
Но одно поверхностное знакомство с Erlang ошарашило меня таким количеством фич, что сложно ожидать простоты.
Erlang простой, но весьма непривычный язык. Elixir выглядит привычнее, поэтому и осваивать легче.
Может просто взять любимый Python и нелюбимый JS, и программировать на них в функциональном стиле? :)
Почему бы и нет, они это позволяют )))
С примерами не всё так просто… Чтобы ОО-пример был нечитабелен, он должен быть достаточно большой по размеру. Т.е. по-хорошему в качестве примера нужен какой-то OpenSource проект или хотя бы ощутимый кусочек проекта, который переписали с ООП на ФП. К тому же чтобы код на функциональном языке стал для Вас читабельным, надо всё-таки привыкнуть в определённым нотациям.
А то с непривычки даже тривиальный вызов стратегии
(&Strategy.add/2) |> Context.execute(3, 4)
может сложночитаемым оказаться по сравнению с привычным
Context context = new Context();
context.setStrategy(new ConcreteStrategyAdd());
context.executeStrategy(3, 4);
Фанатизм везде плох. Делать из ФП культ — так же плохо, как делать культ из ООП или из Rails :-)
О какой потокобезопасности может идти речь в классе Message, предназначенном исключительно для однопоточной работы с объектами с коротким жизненным циклом.
При разработке на Rails по факту всё подгоняется под однопоточную работу.
Хочешь параллельно обрабатывать запросы — запусти N инстансов однопоточного unicorn, хочешь фоновые задачи — запусти ещё 1 инстанс для sidekiq и т.д. Не знаю, как обстоят дела в Django, но что-то мне подсказывает, что аналогично.
А Вы имеете опыт работы с ООП?
Конечно, 10 лет… А разве сейчас бывают программисты без опыта работы с ООП?
Преимущество ФП ещё в том, что оно проще. В ООП частенько за деревьями не видно леса. Потому что кругом паттерны, замудрённые абстракции и т.д., а что по факту делает код понять сложно. В ФП программу рассматривают как своеобразный конвеер по преобразованию данных, где каждый этап конвеера — это просто функция.
Это очень непривычно после ООП, но когда начинаешь въезжать в идею, понимаешь, что большая часть ОО-паттернов — это костыли, подпирающие изначально непродуманную парадигму.
Чем меньше концепций заложено в код, тем он проще, а значит и надёжнее. Это не значит, что ООП теперь нельзя использовать, просто если Вы можете представить задачу, решаемую вашим кодом, в качестве конвеера по преобразованию данных, то в функциональном стиле ваш код будет гораздо легче и понятнее.
Вы же предлагаете всю предметную область положить в AR
Я в этом треде вообще ничего не предлагаю. Я просто констатирую определение этого паттерна и прямые следствия из него.
А то, что Вы по факту не используете паттерн Active Record — это даже хорошо. Путаница возникает из-за того, что Вы думаете, что Вы успешно и повсеместно применяете данный паттерн, хотя по факту отходите от него безумно далеко, и при этом пытаетесь других убедить, что 2+2=5.
Nim логичнее сравнивать с Go, Rust, Crystal.
Язык интересный, но стабильной версии пока нет, да и библиотек пока тоже немного. Причём ощущение, что разработчики слегка подзабили в этом году… После выхода версии 0.13 уже 5 месяцев никаких новостей от них не слышно. Коммиты есть, но активность в разы меньше, чем в прошлом году.
Я этого и не говорил. Я говорил про то, что веб-разработка пошла сначала по пути ООП, а не сразу по ФП, и это во многом было именно веяние моды. Сейчас мода поутихла и появляются более уместные решения. Ну не является обработка потока изолированных входящих запросов задачей, подходящей для ООП, т.к. у них тупо нет никакого shared state в памяти.
1) ФП появилось лет на 10-15 раньше, чем ООП
2) то, что на ОО-ЯП можно писать в функциональном стиле не меняет ОО-парадигму, просто код перестаёт ей следовать
3) Интеграция обеих парадигм в рамках одного языка и так уже идёт, причём давно уже
Это от масштаба проекта зависит на самом деле. 80% сайтов вообще просты до безобразия… просто мы тут их не обсуждаем :-)
По факту, ORM — это ещё одно следствие моды на ООП. Данные в реляционной БД — это данные, а не объекты. Как следствие OR impedance mismatch и разнообразные статьи типа "ORM is an anti-pattern".
И вот Вы перечислили больше десятка действий и ни одного объекта. Когда задача описывается через действия — это как раз признак того, что она больше подходит для ФП, чем для ООП. В случае обработки веб-запросов объекты создаются только чтобы вызвать какие-то их методы, а потом напрячь GC. Советую Вам книгу Programming Phoenix, чтобы посмотреть как эта задача решается без объектов.
точнее вместо того, чтобы функцию поставить в очередь, требует сначала обернуть её в класс
Абстракции и повторное использование — это вещи, слабо связанные с ЯП и с парадигмами программирования. И возможны они везде, было бы желание. А если нет желания, то и в ООП их не будет.
При том, что ООП хорош для задач, где нужно управлять глобальным состоянием программы в оперативной памяти. Взять тот же GUI, как его инстанцировали при открытии программы, так он и продолжает существовать пока программу не закроешь, и у каждого контрола свои атрибуты и обработчики событий. Удобно для ООП? Конечно!
Проблема в том, что ООП превратили в культ карго и создают объекты везде где ни попадя, просто потому что так принято.
Lisp появился ещё до того как все эти парадигмы были сформулированы. Формально, он в первую очередь гомоиконный. Но всё ФП началось именно с него.
В принципе, да, остаётся их разделять разве что по обязательности к-л части.
Я понимаю, хотя списочек там реально заслуживающий внимания, я несколько новых для себя нашёл.
Дело как раз в том, что можно написать обобщенный метод/функцию, без явного указания типа/интерфейса параметров в сигнатуре метода. В ООП для подобных методов придётся использовать явные интерфейсы.
Верно, я имел в виду ООП-языки.
+1, у любой парадигмы есть свои границы применимости.
И даже там где одна парадигма применима, другая может иметь более удобные средства. Так что по-хорошему программист должен быть знаком с многими парадигмами, чтобы делать осознанный выбор под конкретную задачу, а не просто по привычке.
Я возможно Вас слегка расстрою, но утиная типизация — это часть парадигмы обобщённого программирования, к ОО-парадигме она никаким боком не относится :-)
Метапрограммирование — это тоже не ООП, строго говоря. Вообще рекомендую ознакомиться со списком парадигм программирования, там много интересной информации.
Что касается ООП, попробуйте хотя бы для себя, абстрагируясь от привычек, ответить на вопрос: при каких условиях неудобно применять ООП?
Мне кажется, проблема статьи в том, что большинство читателей ещё не познакомились с Elm. Лучше про сам язык расскажите и в чём преимущество его использования по сравнению с другими технологиями типа AngularJS, ReactJS и т.д..
Нет, это будет называться ФП на ОО-языке. Нужно, если у Вас задача идеально подходящая для ФП, а язык проекта позволяет только ООП.
Насколько я помню, есть всего 3 реализации ООП — на основе классов, на основе прототипов и на основе акторов.
C# ранних версий — это шикарный пример реализации ООП на основе классов, а вот начиная с 3-й версии туда начали добавлять ФП и прочие не ООП-концепции.
Из различий реализаций ООП на основе классов, Вы упомянули только множественное наследование, которое по холиварности не уступает goto, поэтому в большинстве реализаций отсутствует )))
А задумайтесь сколько из этих абстракций реально нужны, чтобы обработать запрос? именно из-за усложнения простых вещей "за долю секунды происходит столько всего, что в голове не удержишь". Вы догадываетесь сколько объектов создаётся для обработки тривиального GET /page/permalink? Хотя по сути Вам нужен 1 объект класса Page и то он сам Вам нафиг не нужен, Вам нужны данные из БД, но как же, без ORM никуда..
@Cryvage пишет о том, что можно ОО-язык использовать в функциональном стиле. Т.е. данные о состоянии объекта передавать только конструктору и объявлять на них только геттеры, чтобы даже у методов объекта не было возможности повлиять на его состояние. Тогда получится своеобразное замыкание как в ФП.
Но чтобы так писать на ОО-языке всё равно надо уже расширить своё мышление функциональной парадигмой :-)
Вы во многом правы, но не считаете ли Вы, что функциональные примеси в ООП демонстрируют слабость ОО-парадигмы? По сути даже создатели языков программирования, признают чистое ООП недостаточно удобным. Остался ли хоть один современный ЯП, в котором есть только чистое ООП и ничего больше? Так чтоб никаких лямбд (только Strategy), никаких foreach (только Iterator) и т.д.
Что Вы как ребёнок всё в серебряные пули верите…
ФП — это парадигма программирования и она предоставляет свои инструменты для решения задач. ООП — другая парадигма, в идеале их области применения могли бы не пересекаться, но на практике одну и ту же задачу можно решать в рамках и той и другой парадигмы.
Мы тут обсуждаем конкретно веб-разработку, а не всё подряд. Если вспомнить как ООП попало в веб-разработку, то очевидно, что это было мотивированно больше всего модой на ООП, т.к. весь практический смысл этой парадигмы теряется для программ, которые отрабатывают за долю секунды.
А чего его представлять то, на самом деле полно мультипарадигмальных языков.
Особо отличился Oz — он одновременно поддерживает 7 парадигм программирования :-)
И Вы правы, разные парадигмы не должны мешаться друг с другом, но их можно использовать в разных частях программы.
Ну что ж, возможно в Django мире с многопоточностью чуть получше, чем в Rails мире, где Puma ещё только набирает популярность.
Удачи с ФП :-)
Rails сам по себе тоже поддерживает многопоточность, ещё с 2008 года. А толку то? Вопрос в том какой процент людей пишет сторонние библиотеки и свои приложения в расчёте на многопоточность.
Могу с Вами поспорить на эту тему… проблема именно в ООП, а языки подстраиваются, тупо встраивая некоторые паттерны непосредственно в синтаксис. Классический пример — паттерн Iterator от GoF, сейчас уже сложно найти язык в котором не ввели его поддержку на уровне синтаксиса. Что касается, Python, то он, как и Ruby, не является строгим ОО-языком, а поддерживает множество парадигм. Поэтому Вы можете решать на нём задачи в том числе и в функциональном стиле (возможно даже не подозревая об этом). Чисто ОО-подход — это применение паттернов: GoF, PoEAA, Applying UML and Patterns и т.д.
это в Lisp-подобном языке то? там в принципе нет разделения на код и данные by design :-)
Erlang простой, но весьма непривычный язык. Elixir выглядит привычнее, поэтому и осваивать легче.
Почему бы и нет, они это позволяют )))
С примерами не всё так просто… Чтобы ОО-пример был нечитабелен, он должен быть достаточно большой по размеру. Т.е. по-хорошему в качестве примера нужен какой-то OpenSource проект или хотя бы ощутимый кусочек проекта, который переписали с ООП на ФП. К тому же чтобы код на функциональном языке стал для Вас читабельным, надо всё-таки привыкнуть в определённым нотациям.
А то с непривычки даже тривиальный вызов стратегии
может сложночитаемым оказаться по сравнению с привычным
Картинка, кстати, не моя, она как раз из презентации Functional Programming Patterns
Фанатизм везде плох. Делать из ФП культ — так же плохо, как делать культ из ООП или из Rails :-)
При разработке на Rails по факту всё подгоняется под однопоточную работу.
Хочешь параллельно обрабатывать запросы — запусти N инстансов однопоточного unicorn, хочешь фоновые задачи — запусти ещё 1 инстанс для sidekiq и т.д. Не знаю, как обстоят дела в Django, но что-то мне подсказывает, что аналогично.
Конечно, 10 лет… А разве сейчас бывают программисты без опыта работы с ООП?
Преимущество ФП ещё в том, что оно проще. В ООП частенько за деревьями не видно леса. Потому что кругом паттерны, замудрённые абстракции и т.д., а что по факту делает код понять сложно. В ФП программу рассматривают как своеобразный конвеер по преобразованию данных, где каждый этап конвеера — это просто функция.
Это очень непривычно после ООП, но когда начинаешь въезжать в идею, понимаешь, что большая часть ОО-паттернов — это костыли, подпирающие изначально непродуманную парадигму.
Чем меньше концепций заложено в код, тем он проще, а значит и надёжнее. Это не значит, что ООП теперь нельзя использовать, просто если Вы можете представить задачу, решаемую вашим кодом, в качестве конвеера по преобразованию данных, то в функциональном стиле ваш код будет гораздо легче и понятнее.
Я в этом треде вообще ничего не предлагаю. Я просто констатирую определение этого паттерна и прямые следствия из него.
А то, что Вы по факту не используете паттерн Active Record — это даже хорошо. Путаница возникает из-за того, что Вы думаете, что Вы успешно и повсеместно применяете данный паттерн, хотя по факту отходите от него безумно далеко, и при этом пытаетесь других убедить, что 2+2=5.