Почему возлгал то? На офф.сайт зайдите, там последняя новость в январе была. По-моему, это маркетинговая недоработка… мало что-то делать, надо не забывать об этом писать.
Ну, как ни странно, ООП начала активно пробираться в веб как раз через PHP 5, ещё 12 лет назад. А потом уже Ruby и Python подтянулись )))
ООП действительно появилось гораздо раньше и на момент, когда веб-сайты стали превращаться в веб-приложения и им стал нужен нормальный бэкенд в ходу были C++, Delphi, Java, C#. Все ООЯП.
И по сути был двусторонний процесс, с одной стороны разработчики популярных языков для обычных приложений заметили веб. А с другой стороны веб стал усложняться и требовать подходов для борьбы с этой сложностью. Поэтому недолго думая решили, что и для web ООП пойдёт не хуже, чем для desktop. Ну и экономический фактор тоже сыграл роль, дело даже не в пороге входа, а в том, что ОО-языки уже много кто знал по работе с desktop-приложениями.
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 парадигм программирования :-)
И Вы правы, разные парадигмы не должны мешаться друг с другом, но их можно использовать в разных частях программы.
Почему возлгал то? На офф.сайт зайдите, там последняя новость в январе была. По-моему, это маркетинговая недоработка… мало что-то делать, надо не забывать об этом писать.
Ну, как ни странно, ООП начала активно пробираться в веб как раз через PHP 5, ещё 12 лет назад. А потом уже Ruby и Python подтянулись )))
ООП действительно появилось гораздо раньше и на момент, когда веб-сайты стали превращаться в веб-приложения и им стал нужен нормальный бэкенд в ходу были C++, Delphi, Java, C#. Все ООЯП.
И по сути был двусторонний процесс, с одной стороны разработчики популярных языков для обычных приложений заметили веб. А с другой стороны веб стал усложняться и требовать подходов для борьбы с этой сложностью. Поэтому недолго думая решили, что и для web ООП пойдёт не хуже, чем для desktop. Ну и экономический фактор тоже сыграл роль, дело даже не в пороге входа, а в том, что ОО-языки уже много кто знал по работе с desktop-приложениями.
По вышеназванным языкам это книги:
Elixir — Programming Phoenix
Erlang — N2O — No Bullshit Sane Framework for Wild Web
Clojure — Web Development with Clojure
Haskell — Developing Web Applications with Haskell and Yesod
Вообще для всех кто выбирает язык для веб-разработки, я бы посоветовал такой алгоритм:
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 парадигм программирования :-)
И Вы правы, разные парадигмы не должны мешаться друг с другом, но их можно использовать в разных частях программы.