OOSMOS, the Object Oriented State Machine Operating System, Is Now Open Source | Hacker News Reader

OOSMOS, the Object Oriented State Machine Operating System, Is Now Open Source

oosmos.com

83 pointszzglenm23 comments

For background on the semantics of statecharts and a bit of computer science history, see the following papers and book by Prof. David Harel (the inventor of statecharts) and his collaborators:

The STATEMATE Semantics of Statecharts, 1996

http://www.wisdom.weizmann.ac.il/~harel/SCANNED.PAPERS/Seman...

Modeling Reactive Systems with Statecharts: The STATEMATE Approach, 1998

http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.htm...

The Rhapsody Semantics of Statecharts (or, On the Executable Core of the UML), 2004

http://www.wisdom.weizmann.ac.il/~harel/papers/RhapsodySeman...

Statecharts in the Making: A Personal Account, 2007

http://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.H...

Any software tool recommendations (preferably open source) for creating statecharts?

http://oosmos.com/tools-used#id_UmLet

Not open source but this is an excellent free drawing tool that lets you draw very good looking state charts: http://www-03.ibm.com/software/products/en/ratimode

that's the first time I've ever seen a Rational tool recommended by a user.

It amazes me how often programmers can talk about state machines and functions while concurrently pretending that mathematics is, largely, something that either need not be discussed or is of secondary concern.

Just in time for people realizing that holding onto lots of state is actually a code-design smell and that functional paradigms should be used as much as possible instead!

Not in safety critical applications, nor resource-constrained embedded systems (which this project is targeting).

How is a nine-nines reliability record (as achieved, for example, by Erlang http://stackoverflow.com/questions/8426897/erlangs-99-999999...) not relevant to safety-critical applications?

In the second example, you stand on firmer ground though.

internally message passing, futures and actors are all about state. especially in erlang and scala. the libraries just wrapping that state so you don't need to care about.

also there is always state. look at the io front there your application needs to deal with state, if you are using fp your program maybe doesn't contain state. but the public api mostly deals with it.

Functional programming is about carefully managing your state. Ideally, you want to separate the pieces with the complicated logic, from the pieces that do the state persisting. Then each piece can do one thing and do it well.

There are lots of useful stateless services. But that's the nirvana, and not possible with all things you might want to offer.

Predictable reliability is relevant, certainly. Safety critical systems are frequently hard real-time,[0] by definition resource-constrained.

Aspects of functional paradigms are good for safety critical systems, e.g., using pure functions when possible, when it leads to more predictable and testable systems. Recursion and non-strict evaluation, however, are clearly problematic viz. stack consumption, system load, and execution time; ditto for purely functional data structures and associated functions.

[0] I'm hedging here with frequently, but I'm having trouble thinking of safety critical systems that aren't hard real-time off the cuff… perhaps supervised expert systems, say an automated pathology platform, might count?

> Recursion and non-strict evaluation, however, are clearly problematic viz. stack consumption, system load, and execution time; ditto for purely functional data structures and associated functions.

What you'd want is not a Turing complete language by default, but one that's guaranteed to halt. (And only have Turing complete bits as a fallback, just like unsafePerformIO today.)

Primitive Recursion might be a good limited but useful model of computation. Or something along the lines of Agda.

With such a more restricted notion, recursion doesn't necessarily have to be compiled to a stack.

> problematic viz. stack consumption

Not if one codes towards TCO (Tail Call Optimization): http://stackoverflow.com/questions/310974/what-is-tail-call-...

TCO doesn't address unpredictable system load or execution time. Recursion doesn't lead to predictable systems.

Or a behavior tree :>

Which is yet another time someone reinvented Lisp in XML.

I have done functional programming (FP) with Haskell (including professionally) for years, and I think this notion is misguided.

One of the core principles of FP is about state. However, I believe it is to think very carefully about state and be very explicit about how you handle it rather than performing ad-hoc mutations. That often means avoiding state, but many problems require maintaining state.

State machines can be a great tool to be explicit about state management to the point that you can have a specification for how state behaves.

Thanks for the clarification.

Also, constraint of side effects at the language level allows powerful things like... time-traveling debuggers (does GHC provide anything like this, btw? Because it probably could...)

http://elm-lang.org/blog/time-travel-made-easy

So this is just a fancy event loop?

As every operating system is, right?

I know fairly little about it, but Linux seems to use kernel threads all over the place, so it's not just an event loop.

Actually, it looks like it's a rather plain event loop. I think that's the point, a really, really simple incarnation of (a set of) state machine(s) in C code.

Reply on news.ycombinator.com