3 ms·

Haskell doesn't seem to be a very good language for doing hard or soft realtime, or simulation (realtime games, flight simulation, robotics, industrial control

Haskell doesn't seem to be a very good language for doing hard or soft realtime, or simulation (realtime games, flight simulation, robotics, industrial control etc.). On the other hand, given appropriate memory management which looks to be in the works, native Scala seems a pretty good fit. It seems to me Scala is potentially much more "general purpose" than Haskell. In other words, "more practical".

the_af 10y ago
I've no experience with hard realtime systems, so I won't debate about that (I'll just say I doubt Scala is suitable for that either), but Haskell can be used to write simulators and games. Haskell is currently a practical general purpose language. I don't see any evidence Scala is any better at this. Are you speaking from experience?
- Recurecur 10y ago
  "I've no experience with hard realtime systems, so I won't debate about that (I'll just say I doubt Scala is suitable for that either)," Hard and soft realtime both require deadlines to be met, the difference being that in soft realtime a missed deadline is not considered a fatal error, just highly undesirable. Examples: Soft realtime: A game where 60 FPS is desired for smooth animation. Lower frame rates degrade the experience but are tolerated. Hard realtime: Flight surface control software in a fly-by-wire aircraft. Missed deadlines potentially result in a crashed plane - a true "fatal error". Any ahead of time compiled language with deterministic memory performance may be used for hard realtime. Absolute performance isn't required, although it is desirable. As long as memory primitives are available for native Scala that permit pre-allocation, and the GC can be turned off (trivial), it should work fine even for hard realtime. As an aside, I expect for many things native Scala will equal C++ in performance. On the JVM is extremely close to Java in performance. "but Haskell can be used to write simulators and games." Realtime simulations and games? It seems hard to reconcile immutable state with time-based simulation in any efficient way. Then there are garbage collection cycles and laziness to deal with. "Haskell is currently a practical general purpose language. I don't see any evidence Scala is any better at this. Are you speaking from experience?" GC based languages in general aren't good choices for the types of systems discussed above. GC is also a problem on smaller hardware (embedded systems for instance) since there should be a much larger memory pool than actually used for good performance. Haskell also throws in laziness, which leads to non-determinism. Scala also supports mutable state and the OO paradigm if they are better or more convenient for a particular system.
  - the_af 10y ago
    Thanks, I know what hard realtime means, I just meant I didn't have experience with those systems to really debate about them. Do you have practical experience building hard realtime systems? > As an aside, I expect for many things native Scala will equal C++ in performance Are you familiar with Haskell performance? > [can Haskell be used for] realtime simulations and games? Yes. As I said, I can't speak for hard realtime, but then again, most sims and games seldom require it. > GC based languages in general aren't good choices for the types of systems discussed above. You seem to be arguing out of theory (which is why I asked you if you were speaking from experience). We're also not discussing GC based languages "in general"; we are discussing Haskell, which is a very practical language which can and has been used successfully in a variety of real-world applications, and which qualifies as a general purpose language. If in doubt, talk to an actual Haskell practitioner instead of arguing out of theoretical positions, and you'll be surprised. Many such practitioners frequent HN, and I'm sure they are eager (no pun intended) to discuss the systems they've worked in. For that matter, will Scala Native not be a GC language? > Scala also supports mutable state and the OO paradigm if they are better or more convenient for a particular system. As I argued before, in practice this means Scala is not a great language for OOP or FP. It's understandable that experienced practitioners of either style will prefer cleaner & better languages. I don't predict a particularly great outcome for Scala outside the JVM, since I think the JVM is its main selling point. Once you remove this point, other languages become distractingly attractive :)

the_af 10y ago

I've no experience with hard realtime systems, so I won't debate about that (I'll just say I doubt Scala is suitable for that either), but Haskell can be used to write simulators and games. Haskell is currently a practical general purpose language. I don't see any evidence Scala is any better at this. Are you speaking from experience?

Recurecur 10y ago
"I've no experience with hard realtime systems, so I won't debate about that (I'll just say I doubt Scala is suitable for that either)," Hard and soft realtime both require deadlines to be met, the difference being that in soft realtime a missed deadline is not considered a fatal error, just highly undesirable. Examples: Soft realtime: A game where 60 FPS is desired for smooth animation. Lower frame rates degrade the experience but are tolerated. Hard realtime: Flight surface control software in a fly-by-wire aircraft. Missed deadlines potentially result in a crashed plane - a true "fatal error". Any ahead of time compiled language with deterministic memory performance may be used for hard realtime. Absolute performance isn't required, although it is desirable. As long as memory primitives are available for native Scala that permit pre-allocation, and the GC can be turned off (trivial), it should work fine even for hard realtime. As an aside, I expect for many things native Scala will equal C++ in performance. On the JVM is extremely close to Java in performance. "but Haskell can be used to write simulators and games." Realtime simulations and games? It seems hard to reconcile immutable state with time-based simulation in any efficient way. Then there are garbage collection cycles and laziness to deal with. "Haskell is currently a practical general purpose language. I don't see any evidence Scala is any better at this. Are you speaking from experience?" GC based languages in general aren't good choices for the types of systems discussed above. GC is also a problem on smaller hardware (embedded systems for instance) since there should be a much larger memory pool than actually used for good performance. Haskell also throws in laziness, which leads to non-determinism. Scala also supports mutable state and the OO paradigm if they are better or more convenient for a particular system.
- the_af 10y ago
  Thanks, I know what hard realtime means, I just meant I didn't have experience with those systems to really debate about them. Do you have practical experience building hard realtime systems? > As an aside, I expect for many things native Scala will equal C++ in performance Are you familiar with Haskell performance? > [can Haskell be used for] realtime simulations and games? Yes. As I said, I can't speak for hard realtime, but then again, most sims and games seldom require it. > GC based languages in general aren't good choices for the types of systems discussed above. You seem to be arguing out of theory (which is why I asked you if you were speaking from experience). We're also not discussing GC based languages "in general"; we are discussing Haskell, which is a very practical language which can and has been used successfully in a variety of real-world applications, and which qualifies as a general purpose language. If in doubt, talk to an actual Haskell practitioner instead of arguing out of theoretical positions, and you'll be surprised. Many such practitioners frequent HN, and I'm sure they are eager (no pun intended) to discuss the systems they've worked in. For that matter, will Scala Native not be a GC language? > Scala also supports mutable state and the OO paradigm if they are better or more convenient for a particular system. As I argued before, in practice this means Scala is not a great language for OOP or FP. It's understandable that experienced practitioners of either style will prefer cleaner & better languages. I don't predict a particularly great outcome for Scala outside the JVM, since I think the JVM is its main selling point. Once you remove this point, other languages become distractingly attractive :)