Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Admitting That Functional Programming Can Be Awkward (2007)

prog21.dadgum.com

Post reply on HN
Print view View original

61–70 of 148 posts

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

#61

Post by mannykannot »

Deadron wrote: post #34
mannykannot wrote: post #28

Earlier quoted context omitted.

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 proble…

Until you attempt to multithread the logic and everything breaks.

When your problem domain has changing global state, do you not have synchronization issues - ensuring that stale data is not used, for example - regardless of how you program it? I recall an article making this point, possibly by the same author.

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

#62

Post by pyrale »

dustingetz wrote: post #19
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…

I think it's called functional because it emerges from the lambda calculus (truly just lambdas at the bottom) – but note this definition excludes javascript-with-immutability as well as clojure, not sure if lisp counts

They all count. It's like an athletics competition: everyone is an athlete even if not all people compete in the same discipline, or reach the same performances.

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

#63

Post by mattgreenrocks »

scarmig wrote: post #49
shaan7 wrote: post #30

Earlier quoted context omitted.

> 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 HT…

Even if it's suboptimal from a technical standpoint, a company that went all in on an HTML/JS Frankenstein is likely to have seen more success than one that went all in on a more appropriate native desktop client. There's a reason we see a lot of the former and not much of the latter.

How do you argue that based on technical choices alone? Seems quite reductive.

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

#64

Post by DangitBobby »

dehrmann wrote: post #26
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.

Inheritance is valuable and gets a bad wrap, IMO. I just think about Django's `Model` class and how much time that's saved me and probably tens of thousands of other people. It doesn't even really seem to have any foot guns to speak of, it's just a great use of the abstraction to build up database models without mucking about in the stuff you wish was already written.

The downside to them is that there is that the base class in the inheritance chain (BaseModel -> Model -> YourModel) has some magic that is difficult to reason about (the upside being the other side of that same token!). Thankfully, it's reliable and there's rare occasion to dive in.

Maybe this is a me problem. I don't know how to make a nice abstraction layer like that without inheritance, so I think inheritance is sometimes the answer.

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

#65

Post by tsimionescu »

gnulinux wrote: post #32
fiddlerwoaroof wrote: post #29

Earlier quoted context omitted.

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.

Lisp runtime implicitly runs each top-level expression as statement. When you run (def x y) it's not only true that this expression returns 'x, it's also true that it alters the static state of the program by adding 'x to the scope. To make a purely statementless language, I think you need to make everything happen in a single monadic computation. E.g. in pseudo-Haskell-ish: main : Scope -> StaticIO Scope main scope0…

At least in all of the discussions I have seen, the difference between statements and expressions is whether they return a value, not whether they have side-effects. So (def x b) is an expression, because it returns a value. {} in C is a statement, even though it has no side effects.

Now, there are some statements in CL as far as I remember - I believe (declaim x integer) is a kind of statement, at least in the sense above.

But you can write a CL program that doesn't use a single statement.

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

#66

Post by FpUser »

Of course it can be awkward as it is very specific and opinionated paradigm. It may help to solve some problems while being totally unsuitable to solve others in a sane manner. There are no silver bullets in life.

I personally always shied away from adopting/committing myself to any strict concept. My long experience taught me that as soon as you do there it will likely blow up in your face one or the other way some time down the road.

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

#67

Post by kibwen »

pyrale wrote: post #50
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…

> there is no other first-class language feature common to all the self-described "functional" languages. This line of speech usually serves to corner FP in a self-contradicting definition that can be wrestled with, and it is really aggravating. Functional programming as a concept is well defined, and it's not merely "first-order functions". The reason why many functional languages don't have the same feature set is…

> Functional programming as a concept is well defined, and it's not merely "first-order functions".

Then, sincerely, what is the definition? Does that definition succeed in excluding languages that are not considered functional, e.g. C++, Java, Python, Go? And if it doesn't, and the definition is so broad as to encompass every language, then what is the useful purpose of going out of one's way to label a language as "functional"?

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

#68

Post by pyrale »

mrkeen wrote: post #22

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 d…

> 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.

There's always going to be limits to what you can do in a browser using Elm, but you may be interested in this talk from 2019: https://www.youtube.com/watch?v=_flFAV0_TeY

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

#70

Post by question000 »

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.

Yeah but the question is which one of these types are more "program-y"

Functional programming while a valid form, is inherently better expressed by constraining the possible use cases. It's closer to electrical engineering or mechanics then "programming."

"Programming" inherently rewards extendability, interoperability and readability, therefore it rewards OOP. Now obviously computers have Both mechanical and extendable use cases so it's up in the air.

Stuff that's written better functionally tends to be optimized into oblivion very quickly, it becomes more of a hardware/math/physics problem. But you know that's fun too.

Post reply on HN