Hacker News new | ask | show | jobs
by ChrisRus 3491 days ago
I have been working on a moon-shot project for more than a decade that seeks to model distributed systems as if they were digital logic circuits. One of the natural areas of interest is of course FSM's - in particular declarative specifications of FSM's. I continue to believe (although it's a wildly unpopular notion among some of my machine learning friends) that this obsession with the mechanics of declaring design intent with models and then synthesizing runtime code will fundamentally transform software engineering over time. But, declarative FSM's aren't enough to make it practical IMHO.

I wrote a short essay about this work in which I argue that the software engineering community needs to embrace the design methodologies and rigour of hardware designers: https://medium.com/@alpinelakes/on-monday-i-learned-i-got-ac...

See also: http://blog.encapsule.org/early-encapsule-project-history/20... (old code but same ideas as what I'm building now in Node.js/HTML5 @Encapsule).

Several things I believe are actually essential to make use of any of these ideas at scale:

- There needs to be an ad-hoc extensible standard for notating serialized data with markers, tags, semantics, metadata (whatever you care to call it). It is not practical to do unsupervised feature extraction on internal message streams. And, it's _insanity_ to write/test/maintain custom validation/normalization logic.

- Given the above, FSM declarations must be encoded with labels (as above) so that generic code can easily affect interop.

- Small FSM's are reasonably easy to comprehend. But, very few systems can be modeled with simple FSM's. Rather, real systems can be modeled as complex directed graphs where edges represent the flow of observable state from one FSM to another (vertices represent individual FSM).

- Given that real systems can be modeled using non-trivial graph models of FSM (as above), building reusable components by splicing and dicing the graph up is logically possible. But, this is not something that mortals can do by hand. Considerable tooling is required to make it practical to design systems like this.

If you're interested in these topics, and want to help, look me up @Encapsule.

2 comments

You're about 30 years late. The programming with visual state machines started with Harel and Booch and led to UML (see https://en.wikipedia.org/wiki/Shlaer%E2%80%93Mellor_method#/...). Executable UML (xUML) is a thing. It just never caught on.
UML Statecharts are definitely an interesting model , being HFSMs, and thus modular/extensible. But I think there is a lot to be said about context and application - this kind of thing needs to have a revolutionary 'right place, right time' opportunity.

Kind of like Hypertext and Hypermedia, which languished as an academic pipe dream for decades with occasional commercial moments of brilliance (Hypercard), until Tim Berners Lee figured out the right mix.

i have a project dating back around maybe ten or 15 years that could read the text format (xml iirc) of dia drawings and execute them.

the main problems included being actually very hard to understand visually, very ugly, and subject to all sorts of edge case errors when running. basically easier to write code then compile uml from that for anyone crazy enough to want it.

the crux of the problems is verbosity. Once systems start to get to a reasonable level of complexity the uml diagrams can cover the walls of a large room.

vs 1 page of a4 for pseudocode.

I tend to agree with you on this, my focus has been on the application of declarative Hierarchical FSMs, Behaviour Trees, and/or Hierarchical Task Networks (using automated planning) as a way of describing FSMs declaratively and yet handling the state explosion problem. The intent is to enabling better integration and interoperability on the Web - basically, getting rid of Twitter, Facebook, etc. centralized monopolies of "write" functionality on the Web. ("Read" functionality, i.e. web crawling / HTTP GET / Google is also monopolized but that's less due to architectural problems and more economic)

I have given a couple of keynotes on this topic at the W3C and RESTfest over the years, but just haven't done a lot of the grunt work since I have a day job.

See - http://www.slideshare.net/StuC/ill-see-you-on-the-write-side...

Also - http://www.slideshare.net/StuC/linking-data-and-actions-on-t...

And per your point about how you need serialized data notation + FSMs, see http://web.archive.org/web/20160410102032/http://www.stuchar...

I have felt this train of thought could be useful for a general purpose approach to software engineering beyond distributed systems interop. Unfortunately this has been a hobby horse of mine for about 10 years that I don't have a lot of time to dedicate to....

Cool! Thanks for the links and the reply.

> I have felt this train of thought could be useful for a general purpose approach to software engineering beyond distributed systems interop

One of the best articles I've read in recent years on the topic is 'On the Industrial Adoption of Model Driven Engineering. Is your company ready for MDE?': http://www.uajournals.com/ijisebc/journal/1/4.pdf

> Unfortunately this has been a hobby horse of mine for about 10 years that I don't have a lot of time to dedicate to....

It's a fun horse to ride if not a bit of a wild and tiring.