Functional Programming Is Hard, That's Why It's Good • Hacker News Board

Re: Functional Programming Is Hard, That's Why It's Good

#21

Post by BDFL_Xenu » Sat, Aug 20, 2011, 7:21 PM UTC

stmartin wrote: post #5

This is the lie that every functional programmer has perpetuated for the last 50 years since the dawn of Lisp - that somehow, automagically, productivity or effectiveness of programmers increase with the use of functional languages. It's the biggest lie in the programming world, and it was designed to make the uber-geeks of this world, those people that you walk around the block just to avoid saying hello to because…

Two things: this is one of the trolliest posts I have seen on HN on a while, save for my own (now deleted) counter-troll. The fact that it keeps getting upvoted is astounding. Seriously, associating a certain technique with uber geeks/neckbeards/nerds is actually a valid argument for discounting it?

It's true that FP is presented too often as a remedy for the common ailment of programming of not producing software that you can understand quickly enough. Also known as 'productivity'. But just because it's over-enthusiastically promoted it doesn't mean there's no truth to the claims. It's mostly that

  a. you can compose your software nicely from parameterizable operations over common structures (map, reduce, filter, take, etc.)

  b. mutable state can make programs messy so you should avoid it

But of course you don't care. At all. After all, if you did, you wouldn't be quickly hand waiving the whole issue with a fleeting reference to 'recursion', as if it was the dominant instrument in functional programming. You learn _very_ early that writing recursive functions is just more work than throwing together a bunch of functions over a sequence or some such if needed.

Re: Functional Programming Is Hard, That's Why It's Good

#22

Post by Cushman » Sat, Aug 20, 2011, 7:22 PM UTC

Spyro7 wrote: post #17

tumult wrote: post #13

Earlier quoted context omitted.

The title of this article, for example. The idea of this article is that functional programming is hard, because it forces you to think in a new way. But here, calling functional programming hard is just used to pat oneself on the back. Great, this article says you can map a function over a collection and then sum it. You don't need to think of yourself as some elite programmer that casts a shadow over procedural pro…

"Functional programming is just the general notion of using more functions, and less computer-architectury things, to express your ideas." Umm, no, that is not what functional programming is. Functional programming is, basically, programming without side-effects. A purely functional language will have variables that are completely immutable. This is a bit of a shift away from the way things are done in C or C++. Spea…

I don't ninja downvote, but if I had to guess I'd say it's because if you're finding functional programming incredibly difficult, you maybe shouldn't be lecturing on what it is.

As my cousin points out, it's true that it's easy to think of functions as just being macros in a language like C. If you call a function which doesn't have a return value, and which modifies some global state, that's not a "real" function, just a stored procedure.

However, if you write a C function which doesn't modify global state, but simply takes an input and returns an output, as even novice programmers do all the time, hey presto— that's the functional paradigm! There's nothing mystical about it, and what the GP is saying is that telling people who have done this that functional programming is something different is fundamentally confusing.

Re: Functional Programming Is Hard, That's Why It's Good

#23

Post by profquail » Sat, Aug 20, 2011, 7:22 PM UTC

tptacek wrote: post #15

tumult wrote: post #13

Earlier quoted context omitted.

The title of this article, for example. The idea of this article is that functional programming is hard, because it forces you to think in a new way. But here, calling functional programming hard is just used to pat oneself on the back. Great, this article says you can map a function over a collection and then sum it. You don't need to think of yourself as some elite programmer that casts a shadow over procedural pro…

I'm not expert enough to call you out on this, but isn't "function", the way it's used in "functional programming", working from a different and more strict definition of the word "function" that (say) a C programmer is used to? I don't know that you're wrong about this summary of FP, but it doesn't smell right to me.

That's about right. A "function" in functional programming is supposed to be just like the functions you remember from grade-school algebra class, e.g.,

  f(x) = 2x + 5

If you look at that function, you'll notice that for any given value of 'x', the function always produces the same output value. For example, no matter how many times you try it, plugging in 3 for 'x' always returns 11. This means that f(x) is a "pure" function.

The only difference between the trivial example with f(x) above, and say, Haskell, is that the functions you're working with in Haskell are much more complicated. Boil it down though, and they're still pure, mathematical functions nonetheless.

Now, you can (should?) write purely functional programs in C if you follow the same principals. The main difference is that C doesn't force you do write your code this way, and since writing purely functional code can be a bit tedious, most people don't.

This leads to impure functions in your code, like when you read a file from disk -- if the file is there, the function does one thing; if not, it may do something else (like crash). Since the output of an impure function can vary depending on when/where/why/how it's executed, it can be much harder to find bugs in it, since the code may compile and run just fine until the moment it doesn't.

Anyway, that's the basic rundown on FP. I'm not an FP expert, so if I've missed anything, someone please correct me.

Re: Functional Programming Is Hard, That's Why It's Good

#24

Post by [deleted] » Sat, Aug 20, 2011, 7:22 PM UTC

tptacek wrote: post #15

tumult wrote: post #13

Earlier quoted context omitted.

The title of this article, for example. The idea of this article is that functional programming is hard, because it forces you to think in a new way. But here, calling functional programming hard is just used to pat oneself on the back. Great, this article says you can map a function over a collection and then sum it. You don't need to think of yourself as some elite programmer that casts a shadow over procedural pro…

I'm not expert enough to call you out on this, but isn't "function", the way it's used in "functional programming", working from a different and more strict definition of the word "function" that (say) a C programmer is used to? I don't know that you're wrong about this summary of FP, but it doesn't smell right to me.

[deleted]

Re: Functional Programming Is Hard, That's Why It's Good

#25

Post by dustingetz » Sat, Aug 20, 2011, 7:29 PM UTC

tumult wrote: post #6

FP is becoming the new OOP. People who don't understand its original meaning are misinterpreting it and incorrectly expounding its usefulness. Newcomers are not grasping how it fits into the bigger picture. Be cautious.

You know, I've learned something today!

When some people talk about functional programming, they talk about monads and iterating with recursion and lambda calculus.

Other people talking about functional programming mean using data-oriented abstractions, where functions operate on data in well-defined ways, to avoid state and interlocked dependencies[3]. I've been calling the latter a "functional style", but clearly there is ambiguity and people get turned off and say things like "we're using an OO language why would i want FP"

in Avdi Grimm's talk "Confident Code"[2] he calls this style "narrative structure", compared to "haphazard structure"[4]. I like that; "functional" envokes all sorts of emotion about being hard to understand and unnecessary. "Narrative" or "confident" or "data-oriented" are more articulate, and don't evoke flame wars.

Avdi's example (code screenshot) is the most articulate example of this I've yet seen. https://lh4.googleusercontent.com/-Cs-muD17ato/Tk6b1Rb9MwI/A...

And it's in ruby. Nothing hard here, but it meets a functional style per John D Cook's definition[1]: "OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts." "functional in the small and OO in the large" seems a good path. The Scala community seems to get this, and seems to me Scala is mainstreaming much quicker than any of the pure functional languages.

[1] http://www.johndcook.com/blog/2010/11/03/object-oriented-vs-... [2] http://avdi.org/talks/confident-code-2010-01-12/confident-co... [3] http://www.dustingetz.com/how-to-become-an-expert-swegr [4] http://www.dustingetz.com/confident-code-vs-timid-code

Re: Functional Programming Is Hard, That's Why It's Good

#26

Post by [deleted] » Sat, Aug 20, 2011, 7:30 PM UTC

Spyro7 wrote: post #17

tumult wrote: post #13

Earlier quoted context omitted.

The title of this article, for example. The idea of this article is that functional programming is hard, because it forces you to think in a new way. But here, calling functional programming hard is just used to pat oneself on the back. Great, this article says you can map a function over a collection and then sum it. You don't need to think of yourself as some elite programmer that casts a shadow over procedural pro…

"Functional programming is just the general notion of using more functions, and less computer-architectury things, to express your ideas." Umm, no, that is not what functional programming is. Functional programming is, basically, programming without side-effects. A purely functional language will have variables that are completely immutable. This is a bit of a shift away from the way things are done in C or C++. Spea…

[deleted]

Re: Functional Programming Is Hard, That's Why It's Good

#27

Post by thurn » Sat, Aug 20, 2011, 7:30 PM UTC

tptacek wrote: post #15

tumult wrote: post #13

Earlier quoted context omitted.

The title of this article, for example. The idea of this article is that functional programming is hard, because it forces you to think in a new way. But here, calling functional programming hard is just used to pat oneself on the back. Great, this article says you can map a function over a collection and then sum it. You don't need to think of yourself as some elite programmer that casts a shadow over procedural pro…

I'm not expert enough to call you out on this, but isn't "function", the way it's used in "functional programming", working from a different and more strict definition of the word "function" that (say) a C programmer is used to? I don't know that you're wrong about this summary of FP, but it doesn't smell right to me.

I agree. Minimizing state and side effects are at least as core to functional programming as "you should use lots of functions."

Re: Functional Programming Is Hard, That's Why It's Good

#28

Post by profquail » Sat, Aug 20, 2011, 7:33 PM UTC

Spyro7 wrote: post #17

tumult wrote: post #13

Earlier quoted context omitted.

The title of this article, for example. The idea of this article is that functional programming is hard, because it forces you to think in a new way. But here, calling functional programming hard is just used to pat oneself on the back. Great, this article says you can map a function over a collection and then sum it. You don't need to think of yourself as some elite programmer that casts a shadow over procedural pro…

"Functional programming is just the general notion of using more functions, and less computer-architectury things, to express your ideas." Umm, no, that is not what functional programming is. Functional programming is, basically, programming without side-effects. A purely functional language will have variables that are completely immutable. This is a bit of a shift away from the way things are done in C or C++. Spea…

  My understanding is that most programmers that have a background primarily working with non-functional languages have a challenging time initially grasping the concepts of functional programming.

I'd guess that "most programmers that have a background primarily working with non-functional languages" could just be shortened to "most programmers". Take a look at any of the "language ranking" pages around and you'll find that they're all dominated by imperative/procedural languages.

  However, I would guess that a programmer that learns a functional programming style early on would probably have very little difficulty understanding non-functional constructs.

You're right; unfortunately, it seems that most CS curriculums these days just rush people through some basic programming classes in Java/Python (maybe C++) then through a few more "upper level" electives while just skimming over the algorithmic and data structures stuff that FP is most useful for.

I'd argue that the algorithmic / data structures material (maybe with an intro to some FP language mixed in) is much more important than those elective classes, because the elective stuff is much easier to pick up later on (as needed), while someone who doesn't know their algorithms could spend a whole career writing buggy, slow code because of it.

Re: Functional Programming Is Hard, That's Why It's Good

#29

Post by dasil003 » Sat, Aug 20, 2011, 7:34 PM UTC

stmartin wrote: post #5

This is the lie that every functional programmer has perpetuated for the last 50 years since the dawn of Lisp - that somehow, automagically, productivity or effectiveness of programmers increase with the use of functional languages. It's the biggest lie in the programming world, and it was designed to make the uber-geeks of this world, those people that you walk around the block just to avoid saying hello to because…

You're making the same mistake that the Java loyalists did when Rails came out: judging something based on your distaste for the advocacy around it without any real understanding. I'm not going to pretend to know your motivations here, but often times people throw up this defense mechanism to protect their own professional knowledge; but here's the thing, that does nothing but stunt your own growth.

Functional programming is about the removal of side effects, aka mutable state. Removing side effects makes programming harder because ultimately the whole point of computer programming is to create side effects. Isolating those side effects and writing most of your code in a functional (mathematical definition: always the same output for a given input) way is challenging, but it also promises an order of magnitude more possibility of correctness. The mathematical rigor of a pure functional language like Haskell allows deeper reasoning to be done, and thus more powerful abstractions to be introduced.

In practice functional programming is not the fastest way to solve many problems, but it is an excellent way to push forward the state of computer science as a whole. Think about the relationship between physics and math. We would not have the deep practical knowledge of the physical universe that we have today without the complex math that allowed physicists to reason about things well outside the realm of experimentability.

Re: Functional Programming Is Hard, That's Why It's Good

#30

Post by MrKurtHaeusler » Sat, Aug 20, 2011, 7:38 PM UTC

stmartin wrote: post #12

tete wrote: post #11

Earlier quoted context omitted.

No offense but the same could be said about Object Oriented Programming. To me functional languages make a lot more sense, because of the "No side effects" stuff. Reminds me of a quote from Richard Stallman: "Adding OOP to Emacs is not clearly an improvement; I used OOP when working on the Lisp Machine window systems, and I disagree with the usual view that it is a superior way to program." But I also don't consider…

"I think it is a lot about the way you think" Brother, you are on the money with that statement. But the MINUTE I make a religion out of the way _I_ or a bunch of eclectics uber-geeks think, is the minute you bring about the demise and distaste of that particular paradigm of thinking. I can relate to the 'way of thinking' better than these stupid religious arguments about FP. Did you know you can program in an OO fas…

Common Lisp at least has full support for object-orientation. You don't have to roll it yourself like with C.