OOSMOS, the Object Oriented State Machine Operating System, Is Now Open Source • Hacker News Board

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

#11

Post by merb » Wed, Nov 04, 2015, 11:07 PM UTC

lectrick wrote: post #10

OopsCriticality wrote: post #9

Earlier quoted context omitted.

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.

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

#12

Post by seivan » Wed, Nov 04, 2015, 11:31 PM UTC

lectrick wrote: post #8

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!

Or a behavior tree :>

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

#13

Post by eru » Wed, Nov 04, 2015, 11:57 PM UTC

merb wrote: post #11

lectrick wrote: post #10

Earlier quoted context omitted.

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.

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

#14

Post by OopsCriticality » Thu, Nov 05, 2015, 12:52 AM UTC

lectrick wrote: post #10

OopsCriticality wrote: post #9

Earlier quoted context omitted.

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.

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?

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

#15

Post by e12e » Thu, Nov 05, 2015, 1:08 AM UTC

odc wrote: post #2

So this is just a fancy 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.

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

#16

Post by chubot » Thu, Nov 05, 2015, 1:16 AM UTC

avmich wrote: post #3

odc wrote: post #2

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.

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

#17

Post by TeMPOraL » Thu, Nov 05, 2015, 1:36 AM UTC

seivan wrote: post #12

lectrick wrote: post #8

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!

Or a behavior tree :>

Which is yet another time someone reinvented Lisp in XML.

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

#18

Post by pathelectronica » Thu, Nov 05, 2015, 2:56 AM UTC

zzglenm wrote: post #7

kqr2 wrote: post #5

Earlier quoted context omitted.

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

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.

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

#19

Post by gregwebs » Thu, Nov 05, 2015, 3:16 AM UTC

lectrick wrote: post #8

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!

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.

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

#20

Post by eru » Thu, Nov 05, 2015, 6:10 AM UTC

OopsCriticality wrote: post #14

lectrick wrote: post #10

Earlier quoted context omitted.

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.

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…

> 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.