На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
  
> ООП vs %name% , размышления о проектировании
    Буэнос диас, амигос!

    Понемногу изучая Rust, я столкнулся с тем, что привычные приемы проектирования "не работают". Конечно же я об ООП и его паттернах проектирования. Некоторые "коллеги по цеху" уже разочаровались по стопицот раз, переписывая С++ код на Rust.

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

    Собственно вопросы к обсуждению

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

    1) А как быть если полной поддержки ООП в ЯП нет?
    2) Есть ли приемы/методики проектирования не менее удобные чем объектно-ориентированное?
    3) А есть ли для них свои "паттерны проектирования", которые есть для ООП?

    :-?

    ЗЫ: Аббревиатуру "ООП" читаем как "Объектно-ориентированное программирование" или "Объектно-ориентированное проектирование" по контексту.
      Цитата JoeUser @
      Понемногу изучая Rust, я столкнулся с тем, что привычные приемы проектирования "не работают". Конечно же я об ООП и его паттернах проектирования.

      Например?

      Добавлено
      Цитата JoeUser @
      1) А как быть если полной поддержки ООП в ЯП нет?
      2) Есть ли приемы/методики проектирования не менее удобные чем объектно-ориентированное?
      3) А есть ли для них свои "паттерны проектирования", которые есть для ООП?

      1) Не использовать ООП. Не использовать такой язык. Использовать ООП через кастомные/библиотечные решения для языка.
      На самом деле последний вариант вполне реален. Просто "шаблоны ООП" расширяются вначале самыми примитивными - "объект", "класс" и т.п.
      2) Что значит "не менее удобные"? :)
      Есть старое структурное/процедурное программирование. Есть функциональное.
      3) Ну конечно есть. Паттерны есть вообще почти во всем :) Вопрос в том, описаны ли они так же хорошо, как для ООП. Для функциональщины вроде видел литературу, но сам не читал.

      Добавлено
      Конкретно в rust, по-моему можно вполне соответствовать SOLID, а что ещё нужно? Наследование реализации? Не уверен, что это большое препятствие.
        Цитата D_KEY @
        Например?

        Давай для начала посмотрим простейшее, к примеру паттерн "Фабричный метод", как это будет смотреться на Rust?

        Пример реализации этого на С++ из вики:
        ExpandedWrap disabled
          #include <iostream>
          #include <string>
          using namespace std;
           
          class Product {
            public:
              virtual string getName() = 0;
              virtual ~Product() = default;
          };
           
          class ConcreteProductA: public Product {
            public:
              string getName()override {return "ConcreteProductA";}
          };
           
          class ConcreteProductB: public Product {
            public:
              string getName()override {return "ConcreteProductB";}
          };
           
          class Creator {
            public:
              virtual Product* factoryMethod() = 0;
              virtual ~Creator() = default;
          };
           
          class ConcreteCreatorA: public Creator {
            public:
              Product* factoryMethod()override {return new ConcreteProductA();}
          };
           
          class ConcreteCreatorB: public Creator {
            public:
              Product* factoryMethod()override {return new ConcreteProductB();}
          };
           
          int main() {
            ConcreteCreatorA CreatorA;
            ConcreteCreatorB CreatorB;
            // An array of creators
            Creator*creators[] = {&CreatorA, &CreatorB};
            // Iterate over creators and create products
            for(auto&& creator: creators) {
              Product* product=creator->factoryMethod();
              cout << product->getName() << endl;
              delete product;
            }
            return 0;
          }


        Цитата D_KEY @
        Есть старое структурное/процедурное программирование. Есть функциональное.

        Ну понятия "программирование" и "проектирование" - несколько разные все ж вещи. Результатом программирования является программа или отдельные ее части. Результатом проектирования является математическая модель, имеющая структуру, характеристики и свойства.

        Меня интересует сейчас только варианты проектирования - не ООП.
          Цитата JoeUser @
          как это будет смотреться на Rust

          Точно так же и будет.

          Добавлено
          Можно, пожалуй, согласиться, что существующие подходы к проектированию gui фреймворков на раст укладываются плохо - до сих пор нет вменяемых gui библиотек. Но ООП тут вообще никаким боком.
            Паттерны проектирования программисту не нужны. Они нужны только писателям книг про паттерны проектирования.
            Сообщение отредактировано: applegame -
              Цитата applegame @
              Паттерны проектирования программисту не нужны. Они нужны только писателям книг про паттерны проектирования.

              Спорное утверждение. Пару лет назад я писал "монстра" на Qt в одно лицо. Столько времени ушло на организацию взаимодействия элементов интерфейса на основе сигналов-слотов, просто ппц. А просто по-тому, что изначально все писал "в лоб", не сильно заботясь про создание структуры, где каждый объект или совокупность выполняют только свойственные ему/ей функции. Гораздо позже прочел книгу по паттернам проектирования ООП. А мог бы сэкономить время разработки в разы.
                Цитата OpenGL @
                Точно так же и будет.

                :good: Как считаешь, все ли паттерны ООП проектирования можно так же перевести на Rust, или могут быть проблемы?
                  Цитата JoeUser @
                  Гораздо позже прочел книгу по паттернам проектирования ООП. А мог бы сэкономить время разработки в разы.
                  У меня было не так. Когда я первый раз прочитал о паттернах, то выяснил, что я их и так уже использую, не зная что они имеют какие-там названия. Они же примитивны.
                    Цитата JoeUser @
                    Цитата D_KEY @
                    Есть старое структурное/процедурное программирование. Есть функциональное.

                    Ну понятия "программирование" и "проектирование" - несколько разные все ж вещи. Результатом программирования является программа или отдельные ее части. Результатом проектирования является математическая модель, имеющая структуру, характеристики и свойства.

                    Меня интересует сейчас только варианты проектирования - не ООП.

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

                    Добавлено
                    Цитата applegame @
                    Когда я первый раз прочитал о паттернах, то выяснил, что я их и так уже использую, не зная что они имеют какие-там названия.

                    Так в этом и суть паттернов, что они дают каталогизированный и систематизированный список стандартных подходов, позволяя экономить время при обсуждении и работе в командах(и последующей поддержки возможно даже другими людьми).
                    Ну а новичкам действительно дают правильную справку. Хотя я бы не торопился паттерны давать джунам :)
                      Цитата applegame @
                      Когда я первый раз прочитал о паттернах, то выяснил, что я их и так уже использую, не зная что они имеют какие-там названия.

                      +1. Мне разве что visitor в новинку был, но скорей всего только потому, что на момент прочтения я не сталкивался с задачей, где нужна динамическая диспетчирезация по двум параметрам, а если бы столкнулся, то, полагаю, сам бы пришёл к похожему решению.

                      Цитата D_KEY @
                      позволяя экономить время при обсуждении и работе в командах

                      Хз, по моему опыту всегда достаточно своими словами описать, что ты хочешь это сделать. Умные слова из книжки для этого не сильно нужны.

                      Цитата JoeUser @
                      Как считаешь, все ли паттерны ООП проектирования можно так же перевести на Rust, или могут быть проблемы?

                      Я не вижу каких-либо подводных камней. Сложности BC, которые непременно будут поначалу при программировании на расте, будут относиться скорей к конкретному применению того или иного паттерна и конкретной ситуации, а не к паттерну как таковому.
                        Цитата OpenGL @
                        Хз, по моему опыту всегда достаточно своими словами описать, что ты хочешь это сделать. Умные слова из книжки для этого не сильно нужны.

                        Так можно не описывать, если все понимают термин сразу. Что, неужели никогда не используешь слова "фабрика", "визитор", "фасад" или ещё чего? Или разъясняешь каждый раз их?
                        Не верю :)

                        Да и в коде если соответствующие классы имеют в своих именах соответствующие названия, то читать и вникать проще.
                          Цитата D_KEY @
                          Что, неужели никогда не используешь слова "фабрика", "визитор", "фасад" или ещё чего?

                          Если я скажу, что не использую - ты поверишь? :D Фабрику бывает что использую, всё остальное же использовал только для того, чтобы выпендриться сказать что данное решение носит такое название.
                            Цитата applegame @
                            Паттерны проектирования программисту не нужны. Они нужны только писателям книг про паттерны проектирования.
                            Два чая этому гражданину
                            Цитата D_KEY @
                            Что, неужели никогда не используешь слова "фабрика", "визитор", "фасад" или ещё чего? Или разъясняешь каждый раз их?
                            Не верю
                            я эти слова использую настолько редко, что уже и забыл слово "визитор". Наверное, спасибо, что напомнил:)
                              Цитата OpenGL @
                              Фабрику бывает что использую

                              Ну вот видишь. В этом и смысл. В твоём случае устоялся один паттерн. Для других этот список будет более полным.

                              Добавлено
                              Цитата negram @
                              я эти слова использую настолько редко, что уже и забыл слово "визитор".

                              Ну хоть фабрику-то используешь? :D
                              И вообще, насколько часто обсуждаешь решения при проектировании/архитектурные решения с коллегами? Насколько часто копаешься в чужом коде?
                                Цитата D_KEY @
                                Насколько часто копаешься в чужом коде?

                                При копании в чужом коде все равно не поможет. Какой-нибудь "наблюдатель" можно реализовать сто и одним способом, и когда поймешь, что смотришь именно на него, только в профиль, тогда будет уже поздно - из глаз будут течь кровавые слезы, а уши завернутся в трубочку от мата :D
                                  Цитата Астарот @
                                  Цитата D_KEY @
                                  Насколько часто копаешься в чужом коде?

                                  При копании в чужом коде все равно не поможет. Какой-нибудь "наблюдатель" можно реализовать сто и одним способом, и когда поймешь, что смотришь именно на него, только в профиль, тогда будет уже поздно - из глаз будут течь кровавые слезы, а уши завернутся в трубочку от мата :D

                                  А тебе не кажется, что одна из причин этого - отсутствие знаний о паттернах у писавшего код и, как следствие, отсутствие в документации, комментариях и коде всем понятных названий и обозначений? :)
                                  Сообщение отредактировано: D_KEY -
                                    Цитата D_KEY @
                                    А тебе не кажется, что одна из причин этого - отсутствие знаний о паттернах у писавшего код и, как следствие, отсутствие в документации, комментариях и коде всем понятных названий и обозначений? :)

                                    Так может он и написал, просто не там, где ты копаешься :-?

                                    Добавлено
                                    Вообще, если понимать "наблюдатель", как что-то вроде "издатель-подписчик", а этот паб-саб понимать еще шире, то получится, что в какой-то мере аспектно-ориентированный подход в целом реализует этот самый паттрен :D

                                    Добавлено
                                    Цитата D_KEY @
                                    Паттерны есть вообще почти во всем :) Вопрос в том, описаны ли они так же хорошо, как для ООП. Для функциональщины вроде видел литературу, но сам не читал.

                                    Да ну? Вспоминай, что за зверь, потому что кроме "композиция функций", "рекурсия" и "карринг" фиг что встретишь, не говоря уже о полноценных паттернах :)
                                      Цитата D_KEY @
                                      Паттерны есть вообще почти во всем

                                      Есть мнение, что, если твой язык не позволяет реализовать паттерн один раз в виде библиотечной функции/класса/whatever, то это дерьмовый язык.

                                      Цитата JoeUser @
                                      1) А как быть если полной поддержки ООП в ЯП нет?

                                      Что значит «полная поддержка ООП»? В каком языке есть «полная поддержка ООП»?

                                      Цитата JoeUser @
                                      2) Есть ли приемы/методики проектирования не менее удобные чем объектно-ориентированное?

                                      Есть. Тысячи их. Например:

                                      Прикреплённая картинка
                                      Прикреплённая картинка


                                      Цитата JoeUser @
                                      3) А есть ли для них свои "паттерны проектирования", которые есть для ООП?

                                      Есть. Монады, например.Аппликативные функторы. CSP. Сотни их.
                                        Цитата korvin @
                                        Цитата D_KEY @
                                        Паттерны есть вообще почти во всем

                                        Есть мнение, что, если твой язык не позволяет реализовать паттерн один раз в виде библиотечной функции/класса/whatever, то это дерьмовый язык.

                                        Возможно оно и так, но деньги, как правило, платят за код на дерьмовых языках :D
                                          Цитата D_KEY @
                                          Возможно оно и так, но деньги, как правило, платят за код на дерьмовых языках

                                          Ну, это уже другой вопрос, вне этого холивара =) Впрочем, в любом случае, паттерны — это не правила, а примеры, не нужно возводить их в абсолют, а то придёт Оби-Ван Кеноби =)
                                            Цитата

                                            Есть. Тысячи их.

                                            Это очень плохая и манипулятивная картинка.
                                              Ох уж эти мне монады. Забавно, что несмотря на то, что, в отличие от хаскеля, в эликсире нет встроеного каррирования и ленивости, некоторые господа все равно тащат в эликсир эти ваши монады в виде странных библиотек делающих странные вещи. Такое впечатление, что многие любители функциональных языков давно перестали страдать от этих костылей монад и начали ими наслаждаться :)
                                              Сообщение отредактировано: applegame -
                                                Цитата D_KEY @
                                                В твоём случае устоялся один паттерн.

                                                "Устоялся" это слишком громко сказано. Просто "фабрика" достаточно удобное название. А вот в случае с другими думать о том, является вот эта вот штука мостом или адаптером тупо лениво, так что для них находятся более удобные названия. Например, "враппер" - по-моему это самое универсальное слово, описывающее почти что угодно и которое все понимают :D
                                                  Цитата OpenGL @
                                                  "Устоялся" это слишком громко сказано. Просто "фабрика" достаточно удобное название.

                                                  Ну вот на мой взгляд в этом и заключается польза от любого паттерна. Удобное название для некоторого вида архитектурных решений, которые прошли проверку временем и в том или ином виде встречаются чуть ли не в любой программной системе.
                                                    Цитата applegame @
                                                    Ох уж эти мне монады. Забавно, что несмотря на то, что, в отличие от хаскеля, в эликсире нет встроеного каррирования и ленивости, некоторые господа все равно тащат в эликсир эти ваши монады в виде странных библиотек делающих странные вещи. Такое впечатление, что многие любители функциональных языков давно перестали страдать от этих костылей монад начали ими наслаждаться :)

                                                    Учитывая что монады как бы совсем не из функциональщины - да :D
                                                      Цитата D_KEY @
                                                      Ну вот на мой взгляд в этом и заключается польза от любого паттерна. Удобное название для некоторого вида архитектурных решений, которые прошли проверку временем и в том или ином виде встречаются чуть ли не в любой программной системе.

                                                      Ну хз. По-моему эти названия нифига неудобные потому что они не говорящие абсолютно. Вот, допустим, ты забыл, что такое "мост" или "посетитель" - вспомнишь, для чего они, зная только их название?
                                                        Цитата OpenGL @
                                                        Вот, допустим, ты забыл, что такое "мост" или "посетитель" - вспомнишь, для чего они, зная только их название?

                                                        Раз забыл, значит редко используешь. Значит да, лучше обсудить детали. И значит в этом конкретном случае от паттерна толку не было.
                                                        Но я таки видел большие монолитные системы, которые жили лет по 10 минимум и там паттернов применялось много(как правило по делу), а их знание упрощало жизнь во всех смыслах(как минимум - поддержка кода и обсуждения).

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

                                                        Добавлено
                                                        Цитата Астарот @
                                                        Учитывая что монады как бы совсем не из функциональщины - да :D

                                                        Раскрой мысль, плиз :)

                                                        Добавлено
                                                        Цитата Астарот @
                                                        Цитата D_KEY @
                                                        Паттерны есть вообще почти во всем :) Вопрос в том, описаны ли они так же хорошо, как для ООП. Для функциональщины вроде видел литературу, но сам не читал.

                                                        Да ну? Вспоминай, что за зверь, потому что кроме "композиция функций", "рекурсия" и "карринг" фиг что встретишь, не говоря уже о полноценных паттернах :)

                                                        Сходу не нашел. В процессе наткнулся на статью на хабре
                                                        Вот ещё что-то

                                                        Последняя ссылка может быть интересна автору темы :)

                                                        Но мне почему-то кажется, что была или книжка или прям серия статей на буржуйском. Но видимо глючит память :(
                                                          Цитата D_KEY @
                                                          Раскрой мысль, плиз :)

                                                          Монада - это такой хитросделанный пальцем зверек, который по сути про точки. То есть монада Try выглядит как-то так:
                                                          Цитата
                                                          Try.of(...)
                                                          .success(....)
                                                          .failure(....)

                                                          А функциональщина она как раз про бесточечную нотацию, кажется. Почему монады постоянно относят к ФП для меня загадка :-? Да и слышно про них только при слове "хаскель".

                                                          Добавлено
                                                          Цитата D_KEY @
                                                          Сходу не нашел. В процессе наткнулся на статью на хабре

                                                          Ее видел, там вообще статья странная. Вон та картинка в ней тоже встречается. Народ в комментариях матерится :D

                                                          Добавлено
                                                          Кстати, тут спрашивали про монады в эрланге - http://erlang.org/pipermail/erlang-questio...rch/042557.html
                                                            Есть такое паттерн "Цепочка обязанностей", а не монада ли это случаем? :blink:
                                                              Цитата Астарот @
                                                              Монада - это такой хитросделанный пальцем зверек, который по сути про точки. То есть монада Try выглядит как-то так
                                                              Монады и точки - это взаимно перпендикулярные сущности.
                                                              Цитата Астарот @
                                                              Почему монады постоянно относят к ФП для меня загадка Да и слышно про них только при слове "хаскель".
                                                              Потому что в императивщине монады используются достаточно редко и всегда можно обойтись и без них, а в Хаскеле, наоборот, без монад вообще невозможно жить.
                                                              В последнее время, монады активно применяются в C# и JS для асинхронного I/O, просто многие не знают, что это монады. Я говорю о Promise и async/await. Но это тоже костыли на самом деле.
                                                              Цитата JoeUser @
                                                              Есть такое паттерн "Цепочка обязанностей", а не монада ли это случаем?
                                                              Нет.
                                                              Сообщение отредактировано: applegame -
                                                                Цитата
                                                                Монады и точки - это взаимно перпендикулярные сущности.

                                                                Ну фиг знает. Цепочка вычеслений и цепочка вычеслений.
                                                                  Цитата D_KEY @
                                                                  Раз забыл, значит редко используешь. Значит да, лучше обсудить детали. И значит в этом конкретном случае от паттерна толку не было.

                                                                  Почему? Юзать паттерны не зная что из них чем является - нормальное явление для программиста.
                                                                    Цитата OpenGL @
                                                                    Юзать паттерны не зная что из них чем является - нормальное явление для программиста.

                                                                    Я под паттерном понимаю в данном случае именно устоявшийся каталогизированный способ и соответствующий ему термин.
                                                                    А то, что твое решение совпадает с паттерном - это уже другой вопрос :)
                                                                    Думаю, что у всех программистов такое бывает и читая тот же GoF впервые они видят там свои же решения, пусть и чуть в другом виде иногда.
                                                                      Разговор про монады напомнил мне, как я тут развлекался когда-то в одной из тем
                                                                      Монады и C++
                                                                      Часть 2(списки)
                                                                      Часть 3(монада IO)
                                                                      Цитата D_KEY @
                                                                      ХЗ зачем я все это делал, но было интересно :D

                                                                      Вот уж действительно :)

                                                                      Добавлено
                                                                      Я думал меньше времени прошло :'(
                                                                        Цитата Астарот @
                                                                        Ну фиг знает. Цепочка вычеслений и цепочка вычеслений.
                                                                        Всякая монада - это действительно цепочка вычислений. Но не всякая цепочка вычислений - это монада.
                                                                          Цитата applegame @
                                                                          Цитата Астарот @
                                                                          Ну фиг знает. Цепочка вычеслений и цепочка вычеслений.
                                                                          Всякая монада - это действительно цепочка вычислений. Но не всякая цепочка вычислений - это монада.

                                                                          Что никак не объясняет почему они "перпендикулярны".
                                                                            Цитата Астарот @
                                                                            Что никак не объясняет почему они "перпендикулярны".
                                                                            Я хз как ещё объяснять. "Монады - это точки" это примерно как "студенты - это программисты". Так вот, студенты и программисты взаимно ортогональны. Есть такая аллегория.
                                                                            Сообщение отредактировано: applegame -
                                                                              Цитата applegame @
                                                                              Я хз как ещё объяснять. "Монады - это точки" это примерно как "студенты - это программисты". Так вот, студенты и программисты взаимно ортогональны. Есть такая аллегория.

                                                                              Очевидно же, что когда я говорю "монада - это точки", то рассчитываю, что все тут присутствующие все же программисты, и смогут развернуть это колхозное определение во что-то вроде "объекты содержащие логику и состояние и поддерживающие цепочечные вызовы", или как-то так. Вообще говоря какой-нибудь "билдер" на все возвращающий сам себя, а на build() результат - тоже монада :crazy:
                                                                                Цитата Астарот @
                                                                                "объекты содержащие логику и состояние и поддерживающие цепочечные вызовы"

                                                                                Любой класс, в котором есть логика и состояние и в котором есть метод возвращающий тип-объект подходит под это определение. :-?
                                                                                  Цитата applegame @
                                                                                  в Хаскеле, наоборот, без монад вообще невозможно жить.

                                                                                  Можно, но не нужно, ибо с ними удобней.

                                                                                  Цитата Астарот @
                                                                                  А функциональщина она как раз про бесточечную нотацию, кажется.

                                                                                  Point-free notation не про '.'
                                                                                    Цитата korvin @
                                                                                    Можно, но не нужно, ибо с ними удобней.
                                                                                    Как ты себе представляешь приложение без I/O? Без монад можно разве что либы писать.
                                                                                      Более того, именно ради I/O программа и пишется :D
                                                                                        Цитата applegame @
                                                                                        Цитата korvin @
                                                                                        Можно, но не нужно, ибо с ними удобней.
                                                                                        Как ты себе представляешь приложение без I/O? Без монад можно разве что либы писать.

                                                                                        Возможно, есть другие способы сделать ввод/вывод в haskell. Без монад.
                                                                                          Цитата applegame @
                                                                                          Как ты себе представляешь приложение без I/O? Без монад можно разве что либы писать.

                                                                                          Монады не про IO. Берёшь unsafePerformIO и вперёд. Альтернативный вариант — unique types в Clean.
                                                                                            Цитата korvin @
                                                                                            Монады не про IO.
                                                                                            Монады не про IO, зато IO про монады.
                                                                                            Цитата korvin @
                                                                                            Берёшь unsafePerformIO и вперёд.

                                                                                            Там все равно присутствует монада IO:
                                                                                            Цитата
                                                                                            This is the "back door" into the IO monad, allowing IO computation to be performed at any time.

                                                                                            И всякие операторы вроде >>= и do-нотация - это тоже использование монад.
                                                                                            Монады в Хаскеле - это не прикольная дополнительная возможность, а суровая необходимость.
                                                                                              Цитата applegame @
                                                                                              Там все равно присутствует монада IO:

                                                                                              Ок, про unsafePerformIO я погорячился, думал, это кое-что другое.

                                                                                              Цитата applegame @
                                                                                              И всякие операторы вроде >>= и do-нотация - это тоже использование монад.

                                                                                              Оператор >>= — это монадическая функция bind, да, она в определении монады. do-нотация — просто синтаксический сахар для монад.

                                                                                              Монады можно использовать для любых типов вида * => * (т.е. для любых типов, имеющих один тип-параметр).
                                                                                              Например для списков.

                                                                                              Конкретно тип IO инкапсулирует RealWorld. Инкапсуляция нужна, чтобы не создавать дубликатов мира и прочие неожиданные эффекты. Монада (тайпкласс Monad) выбрана в качестве удобного интерфейса для манипуляций над IO, не более того.

                                                                                              Поэтому монады в Хаскелле — это таки прикольная фича, оказавшаяся ещё и удобной в качестве интерфейса к IO, более удобной чем unique types.

                                                                                              Вот тут рассказывается, как устроено IO в pure-FP вообще, и в Хаскелле в частности:
                                                                                              https://www.youtube.com/watch?v=fCoQb-zqYDI
                                                                                              Сообщение отредактировано: korvin -
                                                                                                Цитата korvin @
                                                                                                Поэтому монады в Хаскелле — это таки прикольная фича,
                                                                                                Ты, видимо, как раз один из тех, кто перестал страдать от монад и начал ими наслаждаться. :)
                                                                                                  Цитата applegame @
                                                                                                  Ты, видимо, как раз один из тех, кто перестал страдать от монад

                                                                                                  Никогда от них не страдал, как и любой, кто ими пользовался.
                                                                                                  0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                                                                                  0 пользователей:


                                                                                                  Рейтинг@Mail.ru
                                                                                                  [ Script execution time: 0,1209 ]   [ 18 queries used ]   [ Generated: 29.03.24, 11:34 GMT ]