4 ms·

How is a nine-nines reliability record (as achieved, for example, by Erlang http://stackoverflow.com/questions/8426897/erlangs-99-9999999-nine-nines-reliability

How is a nine-nines reliability record (as achieved, for example, by Erlang http://stackoverflow.com/questions/8426897/erlangs-99-9999999-nine-nines-reliability http://stackoverflow.com/questions/8426897/erlangs-99-999999...) not relevant to safety-critical applications? In the second example, you stand on firmer ground though.

merb 11y ago
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.
- eru 11y ago
  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.
OopsCriticality 11y ago
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?
- eru 11y ago
  > 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.
- lectrick 11y ago
  > problematic viz. stack consumption Not if one codes towards TCO (Tail Call Optimization): http://stackoverflow.com/questions/310974/what-is-tail-call-optimization http://stackoverflow.com/questions/310974/what-is-tail-call-...
  - OopsCriticality 11y ago
    TCO doesn't address unpredictable system load or execution time. Recursion doesn't lead to predictable systems.

merb 11y ago

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.

eru 11y ago
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.

OopsCriticality 11y ago

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?

eru 11y ago
> 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.
lectrick 11y ago
> problematic viz. stack consumption Not if one codes towards TCO (Tail Call Optimization): http://stackoverflow.com/questions/310974/what-is-tail-call-optimization http://stackoverflow.com/questions/310974/what-is-tail-call-...
- OopsCriticality 11y ago
  TCO doesn't address unpredictable system load or execution time. Recursion doesn't lead to predictable systems.