Я расцениваю минусы к предыдущему комментарию как признание в неспособности написать программу по мотивам указанного в статье рецепта.
Если так сложно на императивном языке написать, то попробуйте перевести с функционального: пример
Это для конкурентного то выпекания? Ну да мьютекс на миску — это так похоже на реальный мир, не то, что сообщение от одного пекаря другому, что миска освободилась :-D
Запускается 4 актора (печь, противень и 2 миски) и всё прекрасно записывается при помощи отправки им сообщений.
Да, эта задача вертится вокруг состояний, но не надо думать, что функциональные языки не могут работать с состояниями. Просто они не используют для этого классы.
плохо подходят для прямого описания последовательных шагов.
Почему же, для описания последовательных шагов в виде цепочки функций ФП отлично подходит. Но хуже подходит для описания нескольких взаимовлияющих на разделяемое состояние последовательностей. Впрочем, до абсурда можно что угодно довести… давайте печь пирог при помощи ООП и классов Духовка, Противень, Миска, Мука, Сода, Соль, Масло, Сахар, Яйцо, Кефир, Банан, Орех, Полотенце.
Автор тупо хитрит, когда приводит рецепт из кулинарной книги в качестве императивной программы. Рецепт — это далеко ещё не программа.
Насколько я понимаю, в классической реализации View был больше похож на то, как это сделано в AngularJS. А возможность вызывать модель из View — это совсем о другом, и скорее это как раз нежелательная возможность.
Так я ж не говорю, что это всегда плохо, для базовых классов при желании можно найти плюсы. Но это не только в базовых классах, это в принципе по коду всего фреймворка встречается.
А человек был в неведении, что в любом Rails-приложении есть десятки классов, размазанных на несколько файлов.
По другому можно делать, но это грести против сообщества. Поэтому 'любовь к «размазыванию» классов на кучу файлов' — это факт, имеющий место в Ruby-сообществе. Поэтому странно видеть утверждения, что приложение, в котором это встречается, априори ненормальное.
По-моему наоборот, Ruby сейчас на пике моды… Появляются курсы типа «Врубиться в Ruby. Научим кодить с нуля». Люди далёкие от программирования начинают интересоваться как освоить Rails. В общем, настолько моден, что невольно вспоминается байка про банкира и чистильщика обуви.
Что Вы имеете в виду?
В самом приложении не должно быть Rails или гемов, расширяющих существующие классы?
Или если Вы выносите такие случаи в гемы — то это ok, а вот если в коде самого приложения — то это фу? Это ж двоемыслие какое-то...
Ни разу не видел чтобы в нормальном приложении класс "размазывался" на несколько файлов.
A Вы код самого Rails смотрели? Тот же ActiveRecord::Base — просто гигантский класс, размазанный на десятки файлов внутри самого фреймворка и ещё сотни файлов из сторонних гемов расширяют его же.
Да, реализация там была действительно неважная. Хотя говорят, что сейчас уже лучше.
Вы больше говорите о программистах, которые сразу начали с PHP, мой опыт не сильно репрезентативен, но я таких почти не встречал. Разве что видел их по вопросам на форумах.
Когда ООП добавили в PHP, это была уже знакомая для многих парадигма. Поэтому наверно и добавили.
Даже фреймворки типа CodeIgniter стали появляться. Хотя он тоже отличался весьма оригинальным видением ООП.
По поводу вопросов, специалистов по ООП в начале 00-х было на порядки больше, чем специалистов по ФП. Опять же благодаря моде, т.к. именно ООП преподавали во всех ВУЗах, а ФП касались на редких факультетах. Да и до сих пор ФП в виду непопулярности остаётся тем конкурентным преимуществом, про которое писал Пол Грэм. Инертность мышления ещё долго будет останавливать людей от изучения чего-то кроме ООП.
Почему возлгал то? На офф.сайт зайдите, там последняя новость в январе была. По-моему, это маркетинговая недоработка… мало что-то делать, надо не забывать об этом писать.
Ну, как ни странно, ООП начала активно пробираться в веб как раз через 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) Интеграция обеих парадигм в рамках одного языка и так уже идёт, причём давно уже
Если так сложно на императивном языке написать, то попробуйте перевести с функционального: пример
Вот, например, выпекание пирога на Elixir:
http://pastie.org/10879491
Запускается 4 актора (печь, противень и 2 миски) и всё прекрасно записывается при помощи отправки им сообщений.
Да, эта задача вертится вокруг состояний, но не надо думать, что функциональные языки не могут работать с состояниями. Просто они не используют для этого классы.
Автор тупо хитрит, когда приводит рецепт из кулинарной книги в качестве императивной программы. Рецепт — это далеко ещё не программа.
А человек был в неведении, что в любом Rails-приложении есть десятки классов, размазанных на несколько файлов.
По другому можно делать, но это грести против сообщества. Поэтому 'любовь к «размазыванию» классов на кучу файлов' — это факт, имеющий место в Ruby-сообществе. Поэтому странно видеть утверждения, что приложение, в котором это встречается, априори ненормальное.
Что Вы имеете в виду?
В самом приложении не должно быть Rails или гемов, расширяющих существующие классы?
Или если Вы выносите такие случаи в гемы — то это ok, а вот если в коде самого приложения — то это фу? Это ж двоемыслие какое-то...
A Вы код самого Rails смотрели? Тот же ActiveRecord::Base — просто гигантский класс, размазанный на десятки файлов внутри самого фреймворка и ещё сотни файлов из сторонних гемов расширяют его же.
Да, реализация там была действительно неважная. Хотя говорят, что сейчас уже лучше.
Вы больше говорите о программистах, которые сразу начали с PHP, мой опыт не сильно репрезентативен, но я таких почти не встречал. Разве что видел их по вопросам на форумах.
Когда ООП добавили в PHP, это была уже знакомая для многих парадигма. Поэтому наверно и добавили.
Даже фреймворки типа CodeIgniter стали появляться. Хотя он тоже отличался весьма оригинальным видением ООП.
По поводу вопросов, специалистов по ООП в начале 00-х было на порядки больше, чем специалистов по ФП. Опять же благодаря моде, т.к. именно ООП преподавали во всех ВУЗах, а ФП касались на редких факультетах. Да и до сих пор ФП в виду непопулярности остаётся тем конкурентным преимуществом, про которое писал Пол Грэм. Инертность мышления ещё долго будет останавливать людей от изучения чего-то кроме ООП.
Почему возлгал то? На офф.сайт зайдите, там последняя новость в январе была. По-моему, это маркетинговая недоработка… мало что-то делать, надо не забывать об этом писать.
Ну, как ни странно, ООП начала активно пробираться в веб как раз через 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) Интеграция обеих парадигм в рамках одного языка и так уже идёт, причём давно уже