Обсуждение: Practical Statecharts in C/C++: Quantum Programming for Embedded ...

[RXL]

https://forum.shelek.ru/index.php/topic,26526.msg281665.html#msg281665
Practical Statecharts in C/C++: Quantum Programming for Embedded Systems.


Еще не читал, но описание очень заинтриговало. Конечно первой мыслью было: "а нет ли переводного издания?". Жаль, но такие вещи редко переводят, даже не смотря на прошедшее с выхода книги десятилетие.

Кстати, в сети книга доступна в PDF.

[Dimka]

RXL, и где ты её в сети видел, кроме Амазона и т.п.?

[Finch]

Dimka, Дай гуглу фразу "Practical Statecharts in C/C++: Quantum Programming for Embedded Systems."  У меня вышла 2 ссылка на PDF

[RXL]

В Бразилии
http://www.google.ru/search?source=ig&hl=ru&rlz=&=&q=Practical+Statecharts+in+C%2FC%2B%2B%3A+Quantum+Programming+for+Embedded+Systems.+PDF&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA+%D0%B2+Google

Залито в нашу библиотеку: тут.

[Dimka]

Finch, ссылок на PDF я видел много: и всё либо за денюжку, либо "своим" - зарегистрированным юзерам, либо вовсе битые ссылки.

RXL, вот тут я вижу сам PDF, а не ссылку на него .

Добавлено через 1 час, 42 минуты и 13 секунд:
Как я и ожидал, за громким названием с претензией на оригинальность не стоит ровным счётом никаких концептуальных новшеств.

Просто очень подробно, хорошо, со знанием дела расписаны автоматы и приёмы их программирования на C/C++, а также изобретённый автором framework. Тем разработчикам, которые постоянно программируют автоматы, это будет полезно.

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

Ну и, конечно, отсутствует главное: методологические приёмы систематического использования автоматов для описания моделей в предметных областях. Впрочем, проблема декомпозиции предметной области на автоматы ничем не проще проблемы декомпозиции на классы. У Шалыто, кстати, в его "автоматном программировании" большая часть внимания уделена как раз проблеме анализа предметных областей и выявления иерархии автоматов, получение автоматов с минимальным количеством состояний и переходов. Без этого неплохой framework становится малополезной игрушкой, годной лишь в программировании там, где кто-то иными средствами уже разработал качественную автоматную модель. Без качественной автоматной модели с этим framework у новичка выйдет точно такая же каша, как из без framework - с багами и глюками.

[Dale]

В наше время, когда уничтожают вредных насекомых, стерилизуя самцов, мы должны поднять уровень спора до абстрактной высоты. Давайте рассуждать о крахе и подъеме Голливуда, не видя ни одного фильма. Давайте сталкивать философов, не читая их работ. Давайте спорить о вкусе устриц и кокосовых орехов с теми, кто их ел, до хрипоты, до драки, воспринимая вкус еды на слух, цвет на зуб, вонь на глаз, представляя себе фильм по названию, живопись по фамилии, страну по "Клубу кинопутешествий", остроту мнений по хрестоматии.

(М. Жванецкий, "Стиль спора".

Интересно, приходила ли мысль Добролюбову (тому самому, оригинальному, еще до клонирования) публиковать мнение о произведениях, которые он не удосужился прочитать? Судя по факту из малость утихомирившейся Википедии ("За один 1858 год он напечатал 75 статей и рецензий."), не исключено - кабы писал не гусиным пером, играючи выдал бы и все 750. Значит, его наследникам и подавно не стоит обращать внимание на такие мелочи, размениваясь на чтение. Читать нынче любой дурак умеет, в школе учат, а вот поди напиши, да еще и многабукав, да высоким штилем...

Просто на всякий случай для тех, кто склонен верить всему написанному: одна из глав книги так и называется - "Chapter 5: State Patterns" (стр. 102). В ней подробно описываются пять паттернов, которые я затрудняюсь найти в других источниках (нечто подобное, но не идентичное, я встречал разве что у Брюса Дугласа). Представлен также метапаттерн Behavioral Inheritance, который также трудно отнести к чересчур широко известным и популярным.

Ну и напоследок маленькая, но любопытная деталь: на то, чтобы выдать рецензию, мне понадобилось примерно полтора месяца работы над книгой. Альтернативная, так сказать, рецензия появилась спустя два часа после того, как RXL опубликовал ссылку на текст. Либо я неправильно читаю, либо...

"Методологические приемы" из книги, конечно же, вряд ли пригодятся строителям полиморфных перцептронов имени Декарта Картезия - не тот размах. Для реактивных приложений же они - самое то, что доктор прописал. Впрочем, устрицы и кокосы лучше все же пробовать лично. Поэтому читайте книгу, составляйте собственное мнение и при желании делитесь им в данной теме. Только, пожалуйста, именно в этом порядке, а не в обратном, а то опять конфуз выйдет, чего доброго...

[Dimka]

одна из глав книги так и называется - "Chapter 5: State Patterns"

Да хоть горшком назови. Это такие же patterns (в общепрограммистском смысле), как и всё вместе - quantum programming. Имеют смысл только в рамках изложенной методики.

А если ковырнуть, в корне лежат: команда, стратегия, компоновщик, хранитель и т.п. Просто приспособлены под автоматы и по-своему названы.

Для реактивных приложений же они - самое то

А кто спорит?

[Dale]

Да хоть горшком назови. Это такие же patterns (в общепрограммистском смысле), как и всё вместе - quantum programming. Имеют смысл только в рамках изложенной методики.

Хорошо. Смотрим, что такое "паттерны проектирования", у классиков:

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

(Кристофер Александер)

Смысл паттерна - предложить решение определенной задачи в конкретном контексте.

("Паттерны проектирования" "банды четырех").

Сравним с доморощенным определением:

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

(текст выделен мной - Dale)

С точки зрения последнего определения - да, действительно, никаких паттернов там нет. Более того, в этом смысле их вообще в природе не существует, поскольку универсальных среди них нет ни одного, все ориентированы на "решение определенной задачи в конкретном контексте". С точки же зрения классиков их там предостаточно.

Кстати, на полке передо мной стоят книги "Шаблоны тестирования xUnit" и "Шаблоны интеграции корпоративных приложений". Меня пытаются провести какие-то проходимцы? Уж эти шаблоны наверняка "специфичны для методологической области и не переносимы в приложения, построенные на иных принципах".

[Dimka]

Смотрим, что такое "паттерны проектирования", у классиков

С К. Александером я согласен - он понимает роль теории в практике. "Банда четырёх" создала чисто практический каталог. На самом деле их 20 с лишним шаблонов сокращаются до нескольких меташаблонов, по-разному используемых в разных контекстах, но имеющих инвариантную структуру и динамику поведения. Причём они сами об этом знают, указывая, что некоторые их шаблоны работают в связке друг с другом или часто сопутствуют друг другу.

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

Единственное, что я отметил дополнительно - в ней нет никаких новых концепций, являющихся новым словом в программировании. Любая теория опирается на принцип, известный как "бритва Оккама" - новые сущности не вводятся без необходимости. Когда некий квантовый физик начинает заниматься программированием и создаёт свою "теорию", переиначивая на свой лад чужие или заново открывая ранее известные концепции, тем самым либо умножая сущности без необходимости, либо создавая свою собственную терминологию, это радовать не может.

Уж коль мы тут обращаемся к цитатам, хорошей иллюстрацией различий между коллекцией практических приёмов и теоретическим багажом будет следующая:

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

Как я уже как-то упоминал, мастер и новатор - это люди, у которых голова работает совершенно по-разному.

[Dale]

Конечно, мнение мастера жанра советского производственного романа Гранина в данной теме очень ценно. Ближе к теме могут быть лишь цитаты из "Мурзилки". Не существующий нигде более, кроме воображения автора, "закон Никольса" оставим на его совести - Гугля в те времена не было, а люди, понимающие смысл слова "интерферометр", подобную макулатуру вряд ли читали, поэтому вероятность попасться на явной профанации для автора была крайне невелика. Шедевр же "и  с  помощью  своего Никольса вскрыл все секреты" напоминает старый добрый анекдот:

Двое чукчей сидят перед телевизором и смотрят программу новостей. Один другому говорит с озабоченным выражением лица:
- Что-то меня Гондурас беспокоит...
Второй глубокомысленно отвечает:
- А ты его не чеши!

Впрочем, оставим эту тему - писал, как мог, в меру отпущенного таланта. А вот что пишет в своей рецензии Майкл Барр (если кто не в курсе - один из корифеев в области встраиваемых систем, автор нескольких книг и множества статей, главный редактор и постоянный автор журнала Embedded Systems Programming), которому в наличии таланта отказать трудно:

...

Книга Миро Самека называется " Practical Statecharts in C/C++" (издательство CMP Books). Впрочем, название книги звучит чересчур скромно. Наибольшее впечатление на меня произвел не столько практический аспект решения постоянно возникающей проблемы, сколько истинно революционные идеи, стоящие за этим решением.

Так называемое "квантовое программирование" автора может полностью изменить сам подход к разработке встроенного ПО.  До сих пор не было сколь-либо жизнеспособной альтернативы традиционной проблеме "main()+ISR vs. RTOS". Вытесняющая мультизадачность хороша лишь для определенных сценариев, тогда как подход main()+ISR несет с собой собственные проблемы, как только вы попытаетесь его масштабировать. Необходим третий путь.

...

До квантового программирования было три основных подхода к реализации конечных автоматов: оператор switch, таблицы указателей на функции и конструкции объектно-ориентированного программирования. Обработка подсостояний иерархических конечных автоматов затруднительна при всех трех подходах. ... В лучшем случае результирующий код напоминает спагетти.

Вкратце технология квантового программирования представояет собой паттерн проектирования непосредственной эффективной реализации плоских либо иерархических конечных автоматов. Он использует известные и проверенные временем диаграммы состояний UML в качестве графического языка спецификаций и оставляет выбор языка программирования разработчику.

...

(полностью можно прочитать здесь).

Попробуем сопоставить это с:

Единственное, что я отметил дополнительно - в ней нет никаких новых концепций, являющихся новым словом в программировании. ... Когда некий квантовый физик начинает заниматься программированием и создаёт свою "теорию", переиначивая на свой лад чужие или заново открывая ранее известные концепции, тем самым либо умножая сущности без необходимости, либо создавая свою собственную терминологию, это радовать не может.

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

[RXL]

https://forum.shelek.ru/index.php/topic,28810.msg281676.html#msg281676
Сохранено и заскладировано.

Добавлено через 14 минут и 5 секунд:
Не, на "битву титанов" смотреть прикольно и цитаты интересные... Только вот ничего конкретного для себя в обсуждении не увидел, кроме того, что книгу стоит прочесть.

Dale, без иронии, могло ли за прошедшие 10 лет суждение Майкл Барр "устареть"?

[Dimka]

Конечно, мнение мастера жанра советского производственного романа Гранина в данной теме очень ценно.

Наравне с мнением Жванецкого в этой теме.

сколько истинно революционные идеи, стоящие за этим решением.
Так называемое "квантовое программирование" автора может полностью изменить сам подход к разработке встроенного ПО.

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

могло ли за прошедшие 10 лет суждение Майкл Барр "устареть"?

Всё когда-то было передовым и оригинальным. Например, применение конечных автоматов как самостоятельный подход в программировании (при разработке компилятора) описал Питер Наур в 1960-х годах. Но, конечно, средства борьбы с так называемым комбинаторным взрывом, к коим относятся как раз иерархия вложенных состояний и параллельные состояния, появились несколько позже.

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

[Dale]

ничего конкретного для себя в обсуждении не увидел, кроме того, что книгу стоит прочесть.

В обсуждении типа "не читал, но точно знаю, что читать там нечего" никогда не бывает ничего конкретного. Чтобы обсуждать по существу, нужно работать в данном направлении.

Dale, без иронии, могло ли за прошедшие 10 лет суждение Майкл Барр "устареть"?

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

В данной области пока что реальных альтернатив QF не вижу. Реальных - в смысле доведенных до продукта, как в случае Самека. Прочитал книгу, скачал фреймворк - и вперед. Всякой заумной чуши публикуется навалом, но она никуда не ведет, только аспирантам идет в зачет публикаций.

Правда, в 2008 году вышло второе издание книги: http://www.state-machine.com/psicc2/index.php . Надо бы почитать. Эта версия существенно больше по объему (728 страниц против 279 в первом издании). Пока знаю только, что изложение там построено на чистом С без плюсов. Не исключено, что там будет что-то новое.

[RXL]

UPD: second edition

[Dale]

Наравне с мнением Жванецкого в этой теме.

Вот мнение Жванецкого как раз очень в тему: он сам не говорит о вещах, которых не знает (в отличие от Гранина), и другим не советует.

Меня иной раз посещает мысль, что "встроенное ПО" - это аналог какой-то дальней деревни в программировании.

Не совсем так. Скорее там еще больше разброс между лучшими и худшими, чем в других областях. Лучшие отлично владеют всем арсеналом программирования, плюс способны укрощать аппаратуру, и все это на фоне жесточайших ограничений по ресурсам. Худшие же порой откалывают такие номера, что по сравнению с ними "социальное программирование" покажется настоящим мастерством. Доводы те же - "зато работает" (или, скорее, они убеждают себя, что работает).

Впрочем, ты сам сокрушался, что новшества со скрипом осваиваются в среде embedded-разработчиков. Даже ООП.

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

Просто я особенно заинтересован в развитии embedded, поэтому быдлокод в памяти микропроцессора волнует меня больше, чем быдлокод в скрипте PHP или в пристройке к 1С. Но, если о проблеме не говорят, это не значит, что ее нет.

Тогда не удивительно, что автоматы и их иерархии выглядят для embedded чем-то революционным.

Допустим. За пределами деревни embedded можете назвать повседневный рабочий инструмент для реализации иерархических автоматов? Шалытинские поделки не в счет, они идут в аккурат по тем граблям, о которых говорил Барр. Для распила грантов и защиты диссертаций (преимущественно в области синтеза распределенных прототипов) это вполне годится, для практической работы - нет.

средства борьбы с так называемым комбинаторным взрывом, к коим относятся как раз иерархия вложенных состояний и параллельные состояния, появились несколько позже.

Реализация иерархических автоматов действительно представляет ряд проблем (именно их изящное решение выгодно выделяет книгу и фреймворк Самека на фоне разных шалыт), но комбинаторного взрыва среди них нет и в помине. Тут - мимо.

[Dimka]

RXL, вторая подробнее и систематичнее первой. Это уже не сборник методических приёмов, а продукт - framework, да ещё и адаптированный под разные условия эксплуатации. И вводная часть написана об использовании этого framework. С одной стороны, там присутствует хорошую практика Страуструпа объяснять ход мысли автора: почему сделано так, а не иначе; с другой стороны, мне это живо напоминает книжку по Delphi, которую я читал лет 12 назад: берутся примеры, и демонстрируется, как их реализовать в рабочей среде.

И конечно во второй редакции так и не появился теоретический фундамент. Более того, автор специально подчёркивает, что у него тут никакой воды и теоретической мути, а всё только жизненные сугубо практические вещи. Это жанр такой: "сразу к делу".

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

А корневой вопрос: в каких случаях event-driven подход к программированию работает, а в каких не работает - так и остался за кадром. Автор с увлечением разбирает калькулятор, бомбу с часовым механизмом, встречается аркадная игрушка - в общем, всё вещи специфические, далёкие, например, от перемножения матриц размером 100 Мб каждая и оптимизации загрузки кэша процессора в этом процессе. Т.е. автор предлагает повернуть мозги программиста от алгоритмов к автоматам, но забывает сказать, в каких случаях это делать стоит, а в каких нет.

Вот тот же Шалыто убеждён, что автоматное программирование годится везде и всюду, но он хотя бы работает над тем, как применить автоматы там, где их ранее не применяли - т.е. не избегает корневого вопроса, а последовательно его решает, углубляя знания. Этот же автор, видимо, считает зазорным обсуждать такие вещи, или же считает, что "народу это не нужно".

Реализация иерархических автоматов действительно представляет ряд проблем (именно их изящное решение выгодно выделяет книгу и фреймворк Самека на фоне разных шалыт), но комбинаторного взрыва среди них нет и в помине.

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