This I don't understand: Seems like whenever functional paradigms are discussed, the whole same stuff is always repeated without failure: on one hand fuzzy generalizations like "pure functions", "no side effects", "no state"... on the other, all examples always talking about using map, filter, fold, flat, zip. One would think that "functional programming" _is_ using those functions. That FP is all about Iterators and what things you can do with them.<p>But I never see contrived real-world examples, those that <i>really</i> show how things are different from imperative or procedural programming. I want to see how you use stateless functional programming to control a garage door actuator. Or how you model a Car which can have their doors open or closed either by the class itself or external actors. How do you receive UDP packets, including a buffer implementation that is able to sort out-of-order packets and send retransmission requests for missing ones? That kind of stuff.<p>Are there any resources that show these kind of "here is a list of problems, how they are typically solved, and how you could solve with FP" style examples?<p>EDIT: This message was actually to say thank you and that TFA is an awesome resource to help understand how the Iterator methods work! And then I got lost in my semi-rant and forgot to actually say thanks :)
Cool game!<p>Headline here might be a little grandiose. Author has "A puzzle game inspired by functional programming" on the project's Github. I find this more apt
This reminds me of the tree diagrams I wrote during the Term Rewriting Systems course at the Vrije Universiteit [1].<p>Functional programming really started to resonate with me at that time. Properties like confluence were very useful to understand distributed systems algorithms later on, and e.g. how eventual consistency plays out.<p>[1] The teacher was awesome too. If you'd like to learn more about term rewriting systems, go take a peek at his slides <a href="http://joerg.endrullis.de/teaching/#trs" rel="nofollow">http://joerg.endrullis.de/teaching/#trs</a> (Note, just noticed that they are behind a password. A gentle email will probably get you the slides though :)
Cool game, but I don't think it is actually a good idea to see this as "learning functional programming".<p>After all, this shows some very convoluted ways of getting a simple end result ;-)<p>Also, I've only played the first few easy levels, so I guess there will be more than "map" later on? Otherwise I would just leave the "map" word out of it.
The biggest challenge with teaching functional programming is that people tend to take the word <i>function</i> or the concept way to seriously. They start mandating restrictions on input/output, what functions should be used for, and all kinds of other unnecessary nonsense. It’s like they need some sort of self imposed guardrails to qualify making better or more common use of functions. Like they need an official invitation before joining the party.<p>Perhaps some of that stupidity is bound to a developer’s understanding of their language at hand. Some languages are more expensive than others. This is where the sad confused developer mandates that functional programming must be declarative... until you point out the languages <i>Red</i> and <i>Rebol</i> are functional imperative languages. It’s not some shallow wishful opinion. That is how those languages describe themselves and it’s what they look like.<p>When you take all the stupidity, assumptions, and restrictions away functions are most universally a bag of instructions, as are classes and various other things. Functions are unique from other instruction bags in that they execute. That creates potential for instruction reuse and thus portability.<p>Different languages impose different restrictions on where or how functions may present. In JavaScript functions are first class citizens which means they can be used anywhere a primitive may be used, which is almost everywhere. Functions can also be nested in that language which just means subdivided layers of portability/reuse. In this case, in a highly imperative way, functional programming can mean programming with a mindset of functions first, as opposed to other means of structure or extension. Again that interpretation of functional programming tends to make people uncomfortable as there are no restrictive guardrails or super specific defining rules.
Good idea but I was able to solve most of the puzzles without ever thinking about what my program was actually doing, especially in the "math" levels. In the sense that I knew what was going on, I got the concepts but I never "evaluated" the program in my head. I just made some educated guesses based on what I thought the patterns might turn into. Maybe that's deliberate here but I thought that's usually not what puzzle games want.
Since the model is an array of pillars, the visualization has a wall is confusing. Would be better to add some space between columns, and remove the 3D/isometric effect.<p>The mathematical problems break the "visual" model. They are harder to understand when you have to spend most of your energy doing 8 simultaneous mental conversions to base 8 while solving.
I love it. It goes to show why I love/hate Haskell. . Im pretty sure most of you just look at signatures(colors) only, further I think most of you just tried a couple of different options until "type" clicks.<p>It is pretty evident that during this you involve yourself in code puzzle / code golf. Rather than understanding the problem at hand. This is fine - until some of your "low-level" stuff leaks or your understanding of it leaks. There is also third possibility for failure - trusting the system too much, despite types being expressive they hide away a lot of "internal" logic, sometimes something looks the same, but it's not and type system doesn't capture it.
I had fun playing through all the challenges. But I don't think I walked away with a better idea of functional programming. This is closer to "learn LINQ", seeing as we're only chaining functions.<p>I would be interested in seeing this expanded to include passing functions to functions (that is, make the user build a tree of functions, not a list). And yes, that might put you into hot water regarding how to communicate signatures and such.
This game reminds me of Infinifactory by Zachtronics
<a href="https://store.steampowered.com/app/300570/Infinifactory/" rel="nofollow">https://store.steampowered.com/app/300570/Infinifactory/</a>
This is cool. It would be improved by adding the CSS <i>#controls { user-select: none }</i> (with various vendor prefixes). A bit of refinement to how dragging is detected wouldn't hurt either.
In case you are looking for the answers -> <a href="https://pastebin.com/tbrJreNn" rel="nofollow">https://pastebin.com/tbrJreNn</a>
This is really cool but I am not sure it helps a person devising a plan towards the solution. It's more of an exploratory stumble-upon-solution activity.
What is the programming equivalent of stack equal columns?<p>I get the map and filter operations but I can’t remember ever coming across a function like that before.