5 ms·
> I started writing a game in Haskell and found that the scaffolding necessary to do randomness in the "right" way was just too painful. It could be that I hadn
by waqf 15y ago
> I started writing a game in Haskell and found that the scaffolding necessary to do randomness in the "right" way was just too painful. It could be that I hadn't learned the idioms well-enough to see a better way of doing things; but if I had trouble, I think it's fair to say that most people would.
This. My current opinion as to what would constitute a perfect language is: something built on top of Haskell which would, in some as-yet-unconceived-of way, make it easy to thread mutable state exactly where it needed to go in your code.
Like monads were supposed to do, except readable.
Frankly, the code contains all the information you need to do this already, so perhaps we just need a source-code übereditor that marks it up so that you can see the dataflow.
- michaelochurch 15y agoMonads are not unreadable. When you finally get do-notation and realize that you can use the same idioms for (a) list comprehensions, (b) imperative-style programming, and (c) error-handling and option-chaining, there's a "Wow" moment. However, we can give up on selling monads to the masses. The name alone... The concept of the monad is beautiful and awesome, but it's too different to succeed with the masses.
- deleted 15y ago[deleted]
- SkyMarshal 15y ago>However, we can give up on selling monads to the masses. The name alone... A monad is just a monoid in the category of endofunctors, what's the problem? (for anyone not familiar with the in-joke: http://stackoverflow.com/questions/3870088/a-monad-is-just-a-monoid-in-the-category-of-endofunctors-whats-the-problem http://stackoverflow.com/questions/3870088/a-monad-is-just-a...)
- Periodic 15y agoCan you explain a little more what you mean about the dataflow? When I was writing some game simulations I ended up creating a few different monads for different execution contexts. I would have my main world monad which contained configuration data, world state, information about all the actors, the random number seed. Then I would have other contexts like AI which is where the AI would figure out what to do, having handy stuff like all the current actor's data easily accessible, and which would return actions on the World. Then there would be the monad for Actions themselves, which would have a source and a maybe a target. In short, I found using a few monads to clearly segment how different things interacted with each other actually made the program fairly clear. The Monads were all just stacks of State, Reader, Writer, and Maybe monads. It seemed like a very natural way to write something where the primary goal is to iterate on a function of type "World -> World", i.e. "Game ()".
- stonemetal 15y agoThat sounds interesting. Any chance the code is open sourced somewhere? I would love to read it.
- malkia 15y agoNot entirely the same, but check Mozilla's rust (still in progress) - https://github.com/graydon/rust/wiki https://github.com/graydon/rust/wiki
- wladimir 15y agoFrankly, the code contains all the information you need to do this already, so perhaps we just need a source-code übereditor that marks it up so that you can see the dataflow. Yes please! I'd love an uber-editor in which I can visualize the dataflow, control flow, and other static analysis output on-the-fly (for any language). Computers are fast enough to do it. It would aid in understanding and be a code maintainer's dream. Imagine that you change something and get immediate feedback on changes in control flow and data flow, and directly see if it was correct without going through any test cycle.
- jules 15y ago> My current opinion as to what would constitute a perfect language is: something built on top of Haskell which would, in some as-yet-unconceived-of way, make it easy to thread mutable state exactly where it needed to go in your code. What's the difference between that and an imperative language?
- waqf 15y agoThe difference is that it only makes well-defined, encapsulatable dependencies on your mutable state easy. It doesn't make totally screwing up easy.
- jules 15y agoI have a hard time imagining how such a thing would actually work. How would the compiler decide that mutable state somewhere is encapsulatable and somewhere else it is not? A compiler can (very easily in fact) monadify all code for you, but what you get is an inefficient imperative language. It seems to me that a much better approach is to allow mutable state everywhere, but to inform the programmer of the consequences via the editor/IDE by showing the result of a static analysis that analyzes which functions are pure and which are not.