3 ms·

Yeah, I don't understand what the "liability" here is. I never claimed it was going to be optimal, and I already pointed out C/C++ as the only reasonable choice

by grg0 1y ago

Yeah, I don't understand what the "liability" here is. I never claimed it was going to be optimal, and I already pointed out C/C++ as the only reasonable choice if you actually want to run games on the thing and get as much performance as possible. But manipulating the machine state in Haskell is otherwise perfect. Code will look like equations, everything becomes trivially testable and REPLable, and you'd even get a free time machine from the immutability of the data, which makes debugging easy.

wk_end 1y ago
If you're effectively always in a stateful monad, Haskell's purity offers nothing. Code doesn't look like equations, things aren't trivially testable and REPLable, you don't get a free time machine, and there's syntactic overhead from things like lifting or writes to deeply nested structures and arrays, since the language doesn't have built-in syntactic support for them.
- kqr 1y ago
  On the other hand, it does have support for things like side-effectful traversals, folds, side effects conditional on value existing, etc. In most other languages you have to write lower-level code to accomplish the same thing.
- grg0 1y ago
  Even if you use a stateful monad (not necessarily the State monad), you can take snapshots of the state of the machine and literally produce a log. You haven't lost immutability or the time machine, and you can 'deriving Show' the hell out of everything and get human-readable output for free. Fuck, you could even lift functions in such a way that they produce a trace of assertions that each function of (state -> state) must satisfy. A state-debugger-log monad. Not that you'd need a monad for something like this anyway.
deterministic 1y ago
It is a pain to update a deep state in Haskell. C++: game.level.unit[10].position += 5; Haskell: way too much code here (unless you use lenses of course but then you are effectively turning Haskell into an imperative language).
- tome 1y ago
  What's wrong with that? Haskell is, after all, the "world's finest imperative language". https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...

by grg0 1y ago

wk_end 1y ago

If you're effectively always in a stateful monad, Haskell's purity offers nothing. Code doesn't look like equations, things aren't trivially testable and REPLable, you don't get a free time machine, and there's syntactic overhead from things like lifting or writes to deeply nested structures and arrays, since the language doesn't have built-in syntactic support for them.

kqr 1y ago
On the other hand, it does have support for things like side-effectful traversals, folds, side effects conditional on value existing, etc. In most other languages you have to write lower-level code to accomplish the same thing.
grg0 1y ago
Even if you use a stateful monad (not necessarily the State monad), you can take snapshots of the state of the machine and literally produce a log. You haven't lost immutability or the time machine, and you can 'deriving Show' the hell out of everything and get human-readable output for free. Fuck, you could even lift functions in such a way that they produce a trace of assertions that each function of (state -> state) must satisfy. A state-debugger-log monad. Not that you'd need a monad for something like this anyway.

deterministic 1y ago

It is a pain to update a deep state in Haskell. C++: game.level.unit[10].position += 5; Haskell: way too much code here (unless you use lenses of course but then you are effectively turning Haskell into an imperative language).

tome 1y ago
What's wrong with that? Haskell is, after all, the "world's finest imperative language". https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...