Еще раз про SCXML
Возможно, это предвзятое мнение, но мне кажется, что в рунете негласно решили, дескать, .Net - единственный эффективный framework и Стив Балмер - пророк его. Спору нет, фреймворк хорош и коммерчески успешен. Альтернативные средства разработки постепенно маргинализируются и есть угроза, что в недалеком времени они могут остаться только в арсенале гиков. Однако, "Мир интереснее, чем вам кажется" (с) Галилео. Прежде всего, это заключается в том, что .Net - это всего лишь один из вариантов реализации известных идей.
Недавно я опубликовал перевод статьи из английской Википедии о SCXML. Не буду останавливаться на технологических преимуществах: часть из них очевидна, другая часть описана в тексте. Давайте поговорим про глобальное.
Честно говоря, меня немного удивило, что про "родственников" SCXML в тексте так мало сказано. А ведь они не из бедных, судите сами: диаграмма автоматов UML, BPML и еще ряд формализмов. В действительности, стандарт предусматривает не только способ описания передачи управления между состояниями, но и наличие некоторого исполняемого кода у состояния и, даже, у переходов (заложились по полной, что и говорить). А теперь скажем, что код, соответствующий состояниям есть замыкание - и получим почти полноценный язык программирования. Входящие и исходящие параметры - это события, соответствующие входящим и исходящим дугам.
Однако, есть момент, который меня смущает. Для всех известных исчислений результат обработки информации напрямую следует из формул, записанных по их правилам. Графические же языки описывают лишь последовательность действий, не затрагивая сущности самих действий. Вот и получается, что результат обработки не следует из структуры графа. Иначе говоря, лямбда - исчисление - это автомобиль, который доставит вас из пункта А в пункт Б, в то время, как SCXML - это всего лишь двигатель автомобиля, который может осуществить такую транспортировку. Но, с другой стороны, если не нацеливаться на мировое господство гордое звание исчисления, то получается неплохой движок.
Недавно я опубликовал перевод статьи из английской Википедии о SCXML. Не буду останавливаться на технологических преимуществах: часть из них очевидна, другая часть описана в тексте. Давайте поговорим про глобальное.
Честно говоря, меня немного удивило, что про "родственников" SCXML в тексте так мало сказано. А ведь они не из бедных, судите сами: диаграмма автоматов UML, BPML и еще ряд формализмов. В действительности, стандарт предусматривает не только способ описания передачи управления между состояниями, но и наличие некоторого исполняемого кода у состояния и, даже, у переходов (заложились по полной, что и говорить). А теперь скажем, что код, соответствующий состояниям есть замыкание - и получим почти полноценный язык программирования. Входящие и исходящие параметры - это события, соответствующие входящим и исходящим дугам.
Однако, есть момент, который меня смущает. Для всех известных исчислений результат обработки информации напрямую следует из формул, записанных по их правилам. Графические же языки описывают лишь последовательность действий, не затрагивая сущности самих действий. Вот и получается, что результат обработки не следует из структуры графа. Иначе говоря, лямбда - исчисление - это автомобиль, который доставит вас из пункта А в пункт Б, в то время, как SCXML - это всего лишь двигатель автомобиля, который может осуществить такую транспортировку. Но, с другой стороны, если не нацеливаться на мировое господство гордое звание исчисления, то получается неплохой движок.