Admitting That Functional Programming Can Be Awkward (2007) • Hacker News Board

Re: Admitting That Functional Programming Can Be Awkward (2007)

#21

Post by dsabanin » Sat, Oct 24, 2020, 4:34 PM UTC

kibwen wrote: post #6

I think it's time we stop using the phrase "functional" to describe this paradigm; at this point, every imperative language made in the past 30 years has first-class functions, and there is no other first-class language feature common to all the self-described "functional" languages. IMO, a more accurate term would be stateless programming. This paradigm is about minimizing state. Of course, as the OP mentions, state…

Functional programming was never about first-class functions. It was always about programming with pure and total functions in their mathematical version.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#22

Post by mrkeen » Sat, Oct 24, 2020, 4:34 PM UTC

This article implies that functional languages cannot run imperative statements, even though it takes for granted that imperative languages can call functions. Google "world's finest imperative language" for a different take on this.

> And each of these is messier than it sounds, because there are so many counters and thresholds and limiters being managed and sounds being played in all kinds of situations, that the data flow isn't clean by any means. > What's interesting is that it would be trivial to write this in C.

You could make the same argument about dealing with git and all its crazy branching, rebasing, and reflogs, compared to just editing your source code in place. Or double-entry bookkeeping versus just keeping track of how much money you have. It gets awkward.

I loved the elegance of game programming in Elm a few years back, but the performance was dogshit - in my case at least - so I probably wouldn't do it again.

The real reason to stick to C/C++ in game programming is speed.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#23

Post by emteycz » Sat, Oct 24, 2020, 4:35 PM UTC

nicolashahn wrote: post #2

> admit that functional programming is the wrong paradigm for some types of problems. Absolutely. Some problems are just so much simpler in an imperative style that it's worth the lack of confidence you get with the functional solution in its correctness and robustness. That's why I love languages that have fairly powerful functional features but have an imperative escape hatch. I think more and more languages are be…

IMHO TypeScript is getting really good now, in the 4.1.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#24

Post by gnulinux » Sat, Oct 24, 2020, 4:35 PM UTC

Avshalom wrote: post #13

kibwen wrote: post #6

I think it's time we stop using the phrase "functional" to describe this paradigm; at this point, every imperative language made in the past 30 years has first-class functions, and there is no other first-class language feature common to all the self-described "functional" languages. IMO, a more accurate term would be stateless programming. This paradigm is about minimizing state. Of course, as the OP mentions, state…

It's a bit more subtle but the lack of statements that is, everything returns a value, is an important feature/quality.

Functional languages do have statements.

   a : Int -> Int

   a x = x + 2

both `:` and `=` are statements, not expressions.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#25

Post by dexwiz » Sat, Oct 24, 2020, 4:36 PM UTC

The middle part about insects, their spawn rates, types, and mutating values is all about state. No matter how much you try to go "stateless", there will be some state implied by your data. Functional programming as the author describes it is good at calculating state, but bad at accessing it. The only for functions to access state is through parameters, which have a final single value in your closure (no out parameters please). They don't have registers/variables/properties to modify.

Functional programming says values like spawn rate or type should be the output of an expression. Monads try to solve this, but storage must be the output of an expression, and is always more complex than simple assignment.

There is one more secret about programming that functional tries to ignore, that it runs on physical machines. Even though some would like to describe programs pure mathematically, they still are bound by physical mechanisms. Most of those mechanisms are for storing state in memory or transferring state to another location. Abstracting over this fact makes programming painful once performance is taken into account.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#26

Post by dehrmann » Sat, Oct 24, 2020, 4:38 PM UTC

voodootrucker wrote: post #9

I wrote an exercise once while I was teaching: "pure functional pacman". Really I did it to teach myself Redux, and it was a pretty fun way to learn. Totally agree with the article: sometimes functional is the right tool for the job, sometimes OOP. A more recent example: parsing USB descriptors in Rust. The parser would have been trivial and easy to understand if I could have multiple mutable references to nodes, but…

> sometimes OOP.

I think OOP is taught somewhat wrong because people will dwell on contrived examples of inheritance when its real value as a paradigm is coupling state with functions. What we've learned from FP is immutability is easier to reason about, but when it isn't is when OOP shines because it gives you a sane way for managing state.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#27

Post by gnulinux » Sat, Oct 24, 2020, 4:39 PM UTC

kibwen wrote: post #6

I think it's time we stop using the phrase "functional" to describe this paradigm; at this point, every imperative language made in the past 30 years has first-class functions, and there is no other first-class language feature common to all the self-described "functional" languages. IMO, a more accurate term would be stateless programming. This paradigm is about minimizing state. Of course, as the OP mentions, state…

Eh, syntactically it hides the state as in `f x` has the same value every time, but calling functional programming stateless is a stretch, I consider it a half-truth told the newcomers to understand the concept. Functional languages still have state but they're abstracted out to function call. E.g. if you have a recursive descent parser written in Haskell, your program will still have state, not every time you're in `expr` function you'll have the same conceptual state.

I think lack of mutation is a lot more pronounced, since it has very important implications to runtime (necessary O(logn) slow down) and requires a more sophisticated type system (linear type system) in order to emulate safe mutation.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#28

Post by mannykannot » Sat, Oct 24, 2020, 4:39 PM UTC

kibwen wrote: post #6

I think it's time we stop using the phrase "functional" to describe this paradigm; at this point, every imperative language made in the past 30 years has first-class functions, and there is no other first-class language feature common to all the self-described "functional" languages. IMO, a more accurate term would be stateless programming. This paradigm is about minimizing state. Of course, as the OP mentions, state…

Before reading this article and its follow-on, I would have completely endorsed the view that global mutable state is the worst, but for the sorts of issues the author is writing about, it seems that global mutable state is precisely the thing that makes procedural solutions more straightforward. In this case, it seems to be an intuitive and straightforward model for how both the programmer and player view the problem.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#29

Post by fiddlerwoaroof » Sat, Oct 24, 2020, 4:40 PM UTC

gnulinux wrote: post #24

Avshalom wrote: post #13

Earlier quoted context omitted.

It's a bit more subtle but the lack of statements that is, everything returns a value, is an important feature/quality.

Functional languages do have statements. a : Int -> Int a x = x + 2 both `:` and `=` are statements, not expressions.

This is sometimes true, the `=` equivalent in Clojure is an expression, though:

   user=> (def a (def b 2))
   user=> a
   #'b

Lisps generally only have expressions (every form returns a value.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#30

Post by shaan7 » Sat, Oct 24, 2020, 4:41 PM UTC

belval wrote: post #5

atty wrote: post #3

I think anyone who has coded long enough would recognize that OOP, functional, imperative, etc all have their strengths and weaknesses, and all have problem domains they are better suited for. Unfortunately, this sometimes gets lost in the language fan wars - it’s easy to lose nuance when discussing something you are passionate about, I have made this mistake myself.

I'd go one step further and say that most people should care little about language features when doing an actual production project, as there are aspects such as how proficient your team is in a given language and how easy it will be to maintain afterwards that are simply more important. That does not mean having a favorite paradigm or language is useless, of course I love Rust and I find functional programming elega…

> how proficient your team is in a given language and how easy it will be to maintain afterwards that are simply more important.

That is a double-edged sword. On one hand it makes sense because it allows teams to be more productive. Otoh, it leads to this decade where it has become okay to create a desktop application using HTML/JS (while more performant tooling exist) simply because a lot of people happen to know HTML/JS than C#/.NET, Qt/C++ etc.

What should be just one of the factors has become the most influencing factor.