Все же она не про параллелизм, как таковой, а про то, как избавиться от "параллелизма" потоков и корутин.
Смотрим на название статьи: "Как избежать кошмара параллелизма в IoT: автоматы вместо потоков и корутин"
Т.е. в заголовке вы обозначаете наличие некого "кошмара параллелизма" и обещаете рассказать про некий способ его избежать. В самой же статье сперва очень много наукообразных слов о том, что считалось короутинами в 1970-х. И не менее наукообразные, но совершенно бесполезные рассуждения о КА из тех же самых, если не более ранних времен. Потом еще немного про какой-то стремный оторванный от жизни пример с сылками на еще более стремную в своей реализации библиотеку. И все.
Поэтому хочется спросить: о каком именно кошмаре параллелизма вы собирались нам, читателям, рассказать?
Или заголовок следует воспринимать как чистой воды кликбейт?
Ну такое себе. Из статьи никак не следует, что овчинка стоила выделки. Возможно, вам следовало бы в начале больше уделить времени тому, как "плохо" при подходах "в лоб" и как же "хорошо" при использовании вашего решения.
Решил написать комментарий чтобы хоть какая-то активность у вашей статьи появилась. Но впечатление от написанного очень странное. Вроде бы и проблема серьезная обозначена, и материал структурирован. Но при этом совершенно не цепляет. Не знаю почему и, к сожалению, не могу посоветовать что бы можно было улучшить чтобы привлечь больше внимания.
Но в любом случае спасибо, что поделились результатами своего труда.
Вот есть мои слова: "Зато связка из Command и Visitor-а там вот прям типичное ООП, да еще в варианте со статической типизаций."
Вы хотите сказать, что это не мое мнение, а значит неправда?
Или вот другие мои слова: "Если вы хотите кого-то убедить в том, что здесь именно функциональное программирование, а не ООП, то флаг вам в руки. К содержимому статьи это не имеет отношения. А вот ваше желание кого-то именно в этом убедить и есть то самое доколупывание, о котором я и сказал."
Вы хотите сказать, что это опять не мое мнение, а значит неправда?
Во-первых, я вам не возражаю, а указываю о том, что вы здесь доколупываетесь до статьи, в которой описываются обычные ООП подходы с желанием доказать, что это всего лишь частный случай функционального подхода. Непонятно зачем.
Во-вторых, отправляю вас к хорошему труду по ООП, чтобы вы просветились, а не принимали за "абстрактную модель ООП" непойми что из собственных заблуждений.
Просто я точно не смогу описать взаимосвязь между абстрактными типами данных и ООП лучше, чем это сделал Мейер в своей фундаментальной работе. Если вы не знакомы с тем, что Мейер описывал, то, боюсь, выши знания об абстрактной модели ООП могут быть крайне неадекватными.
А в абстрактной модели ООП что-то где-то к каким-то данным должно быть привязано?
Если вы хотите кого-то убедить в том, что здесь именно функциональное программирование, а не ООП, то флаг вам в руки. К содержимому статьи это не имеет отношения. А вот ваше желание кого-то именно в этом убедить и есть то самое доколупывание, о котором я и сказал.
Вроде, идеология ООП нас учит, что методы должны быть привязаны к данным?
ООП учит, что данные конкретного ReadCommand не могут быть выставлены наружу в нарушение инкапсуляции. ООП не препятствует тому, чтобы пользователь знал, что за Command может скрываться ReadCommand, CloseCommand или еще что-то.
Хотя сами используемые паттерны ООП являются эмуляцией ФП.
Так я и говорю: вы зачем-то доколупываетесь. К описанной задаче ваш взгляд на то, является ли ООП эмуляцией чего-то или нет, не имеет отношения.
Сама “задача применения M методов обработки к K вариантам данных” – это чисто функциональная постановка.
Это, вообще-то говоря, просто общая постановка задачи. Которая может решаться по разному в зависимости от выразительных возможностей языка, которым мы располагаем. И степени упоротости разработчика.
Статья демонстрирует типичный ООП-шный подход, что, собственно, так и декларировалось. Зачем доколупываться с претензией на то, что "описали чисто функциональные конструкции" -- вот ХЗ.
В статье Command и Visitor решают задачу применения M методов обработки к K вариантам данных. В ООП-стиле это делается через Visitor, в декларации которого приходится перечислять все K вариантов (а во всех Command приходится делать accept для Visitor-а).
В функциональных языках с sum-типами и паттерн-матчингом эта же задача решается без каких-либо Visitor-ов.
Зато связка из Command и Visitor-а там вот прям типичное ООП, да еще в варианте со статической типизаций. Или вы скажете что подобные вещи в функциональном подходе аналогичным образом решаются?
Не очень понятно от какой именно копипасты вы избавлялись посредством deducing this. Насколько я понимаю, вы не избавились от необходимости в каждом наследнике Command переопределять метод accept, просто сейчас он у вас выглядит как-то так (не увидел в статье итогового примера, поэтому высказываю свое предположение):
class ReadCommand : public Command {
sptr<Command> accept(Visitor& visitor) override {
return visitor.visit(get_shared_from_this()));
}
};
Но практически такого же эффекта можно было бы достичь и в рамках предыдущих стандартов C++ без использования deducing this, просто определив вспомогательный метод в базовом классе Command:
Могу предположить, что у вас есть другое место, где приходится заниматься копипастой -- это классы визиторов. Т.е. там под каждый конкретный тип команды приходится писать метод visit:
причем выглядит так, что большинство таких visit-ов будут однотипными, т.е. return cmd. И когда вы добавляете новую команду, то приходится добавлять новый visit в каждый Visitor. Пробовали ли вы как-то решить эту проблему? Или сочли, что это и не проблема вовсе?
но получается что, почему-то ваше фи должны все поддержать
нет
и ставить только плюсики
нет
а оказалось что с вами просто не согласны
это более чем ожидаемо, особенно на таком ресурсе, как Хабр
или вы хотите запретить ставить минусы?
Мне не нравится цветовая дифференциация штанов, реализованная на Хабре, когда набирающие минусы комментарии специально пессимизируются визуальными эффектами.
Простите не вижу смысла отвечать на очередной набор нерелевантных банальностей, ибо если вы декларируете "не ошибается тот, кто ничего не делает", то это автоматически должно подразумевать и то, что в делаемом сейчас (в рефлексии в частности) могут быть ошибки. Но указывать на них, судя по количеству собранных мной здесь минусов нельзя.
Так что я понял: если ты обычный пользователь языка, то не смей говорить "фи" если тебе вдруг что-то не понравилось. По крайней мере на Хабре, с его системой минусования кармы.
Я вижу проблему в том, что никто не знает чьего именно вкуса. Сделали бы авторы пропозала глобальный опрос -- было бы лучше понятно, большинству это нравится или меньшинству.
Ну и [@ @] тоже не идеал. Просто пример того, что заменив всего один символ можно сделать связанный с рефлексией фрагмент кода гораздо заметнее.
В идеале подобные "операторные скобки" должны быть еще больше, типа <<[[ и ]]>>. Чтобы даже мимолетный взгляд указывал, что здесь у нас не обычный код, а связанный с рефлексией.
Смотрим на название статьи: "Как избежать кошмара параллелизма в IoT: автоматы вместо потоков и корутин"
Т.е. в заголовке вы обозначаете наличие некого "кошмара параллелизма" и обещаете рассказать про некий способ его избежать. В самой же статье сперва очень много наукообразных слов о том, что считалось короутинами в 1970-х. И не менее наукообразные, но совершенно бесполезные рассуждения о КА из тех же самых, если не более ранних времен. Потом еще немного про какой-то стремный оторванный от жизни пример с сылками на еще более стремную в своей реализации библиотеку. И все.
Поэтому хочется спросить: о каком именно кошмаре параллелизма вы собирались нам, читателям, рассказать?
Или заголовок следует воспринимать как чистой воды кликбейт?
Сложилось впечатление, что содержание статьи ни разу не соответствует заголовку. Тема параллелизма не раскрыта от слова совсем.
Написать столько кода для того, чтобы затем выписывать вот такое вот вручную:
Ну такое себе. Из статьи никак не следует, что овчинка стоила выделки. Возможно, вам следовало бы в начале больше уделить времени тому, как "плохо" при подходах "в лоб" и как же "хорошо" при использовании вашего решения.
Решил написать комментарий чтобы хоть какая-то активность у вашей статьи появилась.
Но впечатление от написанного очень странное. Вроде бы и проблема серьезная обозначена, и материал структурирован. Но при этом совершенно не цепляет. Не знаю почему и, к сожалению, не могу посоветовать что бы можно было улучшить чтобы привлечь больше внимания.
Но в любом случае спасибо, что поделились результатами своего труда.
Здесь нет, вероятно, и 10-й части возможностей C++.
Покажите как достичь такого же результата без виртуальных методов и докажите, что это так же просто и эффективно.
Ваш код где-нибудь в открытом доступе посмотреть можно?
Неправда в чем состоит?
Вот есть мои слова: "Зато связка из Command и Visitor-а там вот прям типичное ООП, да еще в варианте со статической типизаций."
Вы хотите сказать, что это не мое мнение, а значит неправда?
Или вот другие мои слова: "Если вы хотите кого-то убедить в том, что здесь именно функциональное программирование, а не ООП, то флаг вам в руки. К содержимому статьи это не имеет отношения. А вот ваше желание кого-то именно в этом убедить и есть то самое доколупывание, о котором я и сказал."
Вы хотите сказать, что это опять не мое мнение, а значит неправда?
O_o
А я написал свое о том, что вы здесь со своим "функциональным анализом" как не пришей кобыле хвост. После чего вы стали от меня требовать что-то еще.
Во-первых, я вам не возражаю, а указываю о том, что вы здесь доколупываетесь до статьи, в которой описываются обычные ООП подходы с желанием доказать, что это всего лишь частный случай функционального подхода. Непонятно зачем.
Во-вторых, отправляю вас к хорошему труду по ООП, чтобы вы просветились, а не принимали за "абстрактную модель ООП" непойми что из собственных заблуждений.
Просто я точно не смогу описать взаимосвязь между абстрактными типами данных и ООП лучше, чем это сделал Мейер в своей фундаментальной работе. Если вы не знакомы с тем, что Мейер описывал, то, боюсь, выши знания об абстрактной модели ООП могут быть крайне неадекватными.
Почитали бы Бертрана Мейера, его книгу про объектно-ориентированное конструирование программ.
А в абстрактной модели ООП что-то где-то к каким-то данным должно быть привязано?
Если вы хотите кого-то убедить в том, что здесь именно функциональное программирование, а не ООП, то флаг вам в руки. К содержимому статьи это не имеет отношения. А вот ваше желание кого-то именно в этом убедить и есть то самое доколупывание, о котором я и сказал.
ООП учит, что данные конкретного ReadCommand не могут быть выставлены наружу в нарушение инкапсуляции. ООП не препятствует тому, чтобы пользователь знал, что за Command может скрываться ReadCommand, CloseCommand или еще что-то.
Так я и говорю: вы зачем-то доколупываетесь. К описанной задаче ваш взгляд на то, является ли ООП эмуляцией чего-то или нет, не имеет отношения.
Это, вообще-то говоря, просто общая постановка задачи. Которая может решаться по разному в зависимости от выразительных возможностей языка, которым мы располагаем. И степени упоротости разработчика.
Статья демонстрирует типичный ООП-шный подход, что, собственно, так и декларировалось. Зачем доколупываться с претензией на то, что "описали чисто функциональные конструкции" -- вот ХЗ.
Что список?
В статье Command и Visitor решают задачу применения M методов обработки к K вариантам данных. В ООП-стиле это делается через Visitor, в декларации которого приходится перечислять все K вариантов (а во всех Command приходится делать accept для Visitor-а).
В функциональных языках с sum-типами и паттерн-матчингом эта же задача решается без каких-либо Visitor-ов.
Зато связка из Command и Visitor-а там вот прям типичное ООП, да еще в варианте со статической типизаций. Или вы скажете что подобные вещи в функциональном подходе аналогичным образом решаются?
Да здесь вообще мизер возможностей C++ зайдействован, непонятно с чего вы вдруг так возбудились.
Из тонкостей разве что в глаза отстутвие виртуального деструктора в Command в глаза бросается. Вот это наверняка не все считают.
Не очень понятно от какой именно копипасты вы избавлялись посредством deducing this. Насколько я понимаю, вы не избавились от необходимости в каждом наследнике Command переопределять метод accept, просто сейчас он у вас выглядит как-то так (не увидел в статье итогового примера, поэтому высказываю свое предположение):
Но практически такого же эффекта можно было бы достичь и в рамках предыдущих стандартов C++ без использования deducing this, просто определив вспомогательный метод в базовом классе Command:
Могу предположить, что у вас есть другое место, где приходится заниматься копипастой -- это классы визиторов. Т.е. там под каждый конкретный тип команды приходится писать метод visit:
причем выглядит так, что большинство таких visit-ов будут однотипными, т.е.
return cmd. И когда вы добавляете новую команду, то приходится добавлять новый visit в каждый Visitor. Пробовали ли вы как-то решить эту проблему? Или сочли, что это и не проблема вовсе?нет
нет
это более чем ожидаемо, особенно на таком ресурсе, как Хабр
Мне не нравится цветовая дифференциация штанов, реализованная на Хабре, когда набирающие минусы комментарии специально пессимизируются визуальными эффектами.
Простите не вижу смысла отвечать на очередной набор нерелевантных банальностей, ибо если вы декларируете "не ошибается тот, кто ничего не делает", то это автоматически должно подразумевать и то, что в делаемом сейчас (в рефлексии в частности) могут быть ошибки. Но указывать на них, судя по количеству собранных мной здесь минусов нельзя.
Так что я понял: если ты обычный пользователь языка, то не смей говорить "фи" если тебе вдруг что-то не понравилось. По крайней мере на Хабре, с его системой минусования кармы.
Я вижу проблему в том, что никто не знает чьего именно вкуса. Сделали бы авторы пропозала глобальный опрос -- было бы лучше понятно, большинству это нравится или меньшинству.
Ну и
[@ @]тоже не идеал. Просто пример того, что заменив всего один символ можно сделать связанный с рефлексией фрагмент кода гораздо заметнее.В идеале подобные "операторные скобки" должны быть еще больше, типа
<<[[и]]>>. Чтобы даже мимолетный взгляд указывал, что здесь у нас не обычный код, а связанный с рефлексией.