Learning FP the hard way: Experiences on the Elm language
gist.github.com
Learning FP the hard way: Experiences on the Elm language
1–10 of 13 posts
Re: Learning FP the hard way: Experiences on the Elm language
#2Well explained, thanks!
Re: Learning FP the hard way: Experiences on the Elm language
#3Really nice explanation and code samples. I'm glad to see more accessible materials emerge for explaining what signals are. The Elm website already does a good job, but I think the extra detail in this article will help more people grok it.
I have done my own exploration in this area. I hack on a game engine written in Scheme that includes a signal implementation, a declarative scene graph, and a live coding environment via a REPL server. It's not as glamorous as Elm, but I'm quite proud of it and I plan to make the first release soon.
http://dthompson.us/pages/software/sly.html
An older blog post I did with code samples and a quick screencast when the project had a different name:
http://dthompson.us/functional-reactive-programming-in-schem...
Re: Learning FP the hard way: Experiences on the Elm language
#4I think this is the first time the concept of currying has solidly clicked for me; most explanations focus on the "your function should take one argument" aspect more than the "your function should return a new function" aspect, which meant that, until now, currying looked more like an obstacle than a tool.
Thanks!
Re: Learning FP the hard way: Experiences on the Elm language
#5I think this is the first time the concept of currying has solidly clicked for me; most explanations focus on the "your function should take one argument" aspect more than the "your function should return a new function" aspect, which meant that, until now, currying looked more like an obstacle than a tool. Thanks!
That's great to hear! I also had some trouble finding the gist of currying. As you said, the _why_ is often missing in the explanations. Glad I could help you in that regard.
Re: Learning FP the hard way: Experiences on the Elm language
#6Really nice explanation and code samples. I'm glad to see more accessible materials emerge for explaining what signals are. The Elm website already does a good job, but I think the extra detail in this article will help more people grok it. I have done my own exploration in this area. I hack on a game engine written in Scheme that includes a signal implementation, a declarative scene graph, and a live coding environm…
Thank you! "Accessible" is precisely what I wanted the post feel like.
Sly seems very cool too, I hope it will help popularizing these ideas!
Re: Learning FP the hard way: Experiences on the Elm language
#7So when I update ship, that means a new ship was created right? What happens to the old ship? and how is recreating the universe for every iteration efficient? Is there something tricky going on in the background?
Re: Learning FP the hard way: Experiences on the Elm language
#8So when I update ship, that means a new ship was created right? What happens to the old ship? and how is recreating the universe for every iteration efficient? Is there something tricky going on in the background?
Consider that in many cases, you don't need to recreate the whole universe--lots of stuff may stay the same.
Also, to get to the old ship, you just rewind the events, because the state can be fully reconstructed (no weird side-effects).
Re: Learning FP the hard way: Experiences on the Elm language
#9So when I update ship, that means a new ship was created right? What happens to the old ship? and how is recreating the universe for every iteration efficient? Is there something tricky going on in the background?
A new ship is created and the old ship is sailing towards garbage-collection unless other objects are still holding references to that value.
This is going to add more pressure on the garbage-collector for sure.
Re: Learning FP the hard way: Experiences on the Elm language
#10So when I update ship, that means a new ship was created right? What happens to the old ship? and how is recreating the universe for every iteration efficient? Is there something tricky going on in the background?
There is indeed something tricky going on: Elm uses persistent data structures behind the scenes.
See this previous HN discussion about Elm's persistent data structures: https://news.ycombinator.com/item?id=7686272