Don’t Be Scared Of Functional Programming

http://www.smashingmagazine.com/2014/07/02/dont-be-scared-of-functional-programming/

by subbz • 12 years ago

53 98 12 years ago

slapresta3• 12 years ago

Smashing Magazine on functional programming, getting most of it wrong. This is the very moment functional programming jumps the shark.

It's too mainstream for me now, I'll have to switch to reactive programming.

platz• 12 years ago

Too late, Erik Meijer already declared the term reactive was washed out.

boothead• 12 years ago

There's still dependant types!

pacala• 12 years ago

Reactive programming is functional programming for events. You can run but you can't hide.

lightblade• 12 years ago

"Functional" reactive programming is the functional programming for events. Reactive programming is actually pretty broad.

seanmcdirmid3• 12 years ago

Imperative reactive programming via Esterel has been a thing since the 80s, you know.

doctorKrieger• 12 years ago

one of the points of the article is wrong, fp isn't stateless at all it just tends to represent state in a different way - look at monads in haskell.

wyager3• 12 years ago

Well Haskell can still "stateless" in some sense, even if your program seems to take advantage of state. The State monad (and other monads), for example, just facilitate a bit of clever syntax to sneak computational context, which can include state, into the lambda calculus. The IO and STM monads (which deal with side effects) are a bit different, and can introduce true state into a program (with a bit of cleverness to make the existence of state mesh well with the lambda calculus).

innguest21• 12 years ago

No, it is indeed stateless. The fact that it represents state is proof of that. FP uses representations for things instead of the real things. For instance, OO purposefully causes changes in RAM to make things happen, where in FP changes in RAM are incidental and the programmer need not manage them. So it is stateless because you program indirectly by using these conceptual representations that are free of implementation.

dllthomas4• 12 years ago

Modulo IORef and similar.

droithomme• 12 years ago

"Don't be scared" rhetoric is generally used to promote arguments not primarily through logic, but by painting the audience as fearful luddites, scared of progress and the inevitable better future based on whatever the speaker is advocating. The goal is to encourage the listener to convert to the new religion or paradigm, or be considered backwards, behind the times, and ignorant or stubborn. It's an effective tactic because any push-back is pre-framed as evidence the listener is among the ignorant backwards people.

notacoward2• 12 years ago

Hear, hear. I had exactly the same reaction. Maybe the author is pitching the article toward novice programmers and is genuinely trying to reassure. OTOH, such phrasing is far more often used as a pure rhetorical ploy.

Personally, since I work in storage which is where we have to store all the "state" that the FP folks have defined into Somebody Else's Problem, I have little tolerance for that particular flavor of the month.

slapresta3• 12 years ago

You seem to be confusing state with data. Storage is supposed to store data, not state.

Still, even if you store your internal state, that's hardly what functional programming means when opposing state.

wyager3• 12 years ago

Personally, since I work in storage which is where we have to store all the "state" that the FP folks have defined into Somebody Else's Problem, I have little tolerance for that particular flavor of the month.

You say this as if functional programmers somehow make your life harder... It's not like they're decrying the existence of persistent storage or trying to put you out of business :)

Also, functional programming isn't about offloading state, it's about removing it from programs altogether (in the sense of "state" being something that isn't explicitly passed through function arguments).

innguest21• 12 years ago

In FP, State is transformed into something more formalized, namely parameters passed to other functions. So no one in FP is punting on State, we simply don't need it to accomplish those same goals. It's different from saying "it's somebody else's problem", though it might sound like that because State is one problem FP does not have (so in that sense it is solely a turing-machine-programmers' problem).

msie• 12 years ago

I didn't get that impression from the title. There are people who are interested in fp but feel that they are not smart enough to comprehend it. They are not luddites by any stretch.

CmonDev• 12 years ago

We are already dealing with a weak dynamic language - what else could really scare us? Perhaps introducing shared memory multithreading into core JS... Certainly not a bit of immutability and pure functions.

wyager3• 12 years ago

I think it's appropriate. A sentiment I hear an alarming amount is roughly "I want to program, not do math." when someone gets a suggestion to learn functional programming.

In reality, someone can take advantage of FP with absolutely no understanding of the mathematical underpinnings. I think that's what the author was trying to get across.

innguest21• 12 years ago

I think it's better to solve the "math is scary" attitude problem by first showing how it actually helps and is useful. FP gets a lot easier if you know some basic abstract math.

VeejayRampay• 12 years ago

With more passionate FP advocates, there's no "people who are not interested in FP after having tried and not finding it useful for their intents and purposes", there are people who either :

- Don't understand it - Are afraid of it - Find it too complicated

grayrest• 12 years ago

If you're interested in FP in javascript, you should check out the relatively new Ramda.js [1]. It switches from the underscore style collection first call pattern to a collection last pattern and automatically curries its functions. The combination allows for easier function composition.

[1] https://github.com/CrossEye/ramda

More info on the topic:

http://fr.umio.us/why-ramda/

http://www.youtube.com/watch?v=m3svKOdZijA

https://speakerdeck.com/raganwald/javascript-combinators

vqc• 12 years ago

I believe Javascript Allonge takes the same approach w/r/t the call pattern: http://allong.es/

The book is also very good: https://leanpub.com/javascript-allonge

yxhuvud• 12 years ago

To be honest, this looks more like an explanation of the concept of abstraction than of the concept of functional programming.

badman_ting• 12 years ago

"Functional programming is the mustachioed hipster of programming paradigms."

Well, that's not helping. But I agree that devs should learn FP, and I now write in a much more functional style than I used to. I resisted for a long time, and that was a mistake.

peaton2• 12 years ago

The literature relies on somewhat foreboding statements like “functions as first-class objects,” and “eliminating side effects.

I personally find this view a little overbearing.

In "lay programmer's" terms, functions as first-class objects can often come down to being able to pass functions to other functions or function composition. Most of us learned about function composition in Algebra 2... So that's pretty straightforward even at its worst.

Eliminating side effects is equally straightforward in that all it means is that any variables outside the scope of a given function are not changed by the function.

mneary2• 12 years ago

Function composition is very different from passing one function into another and the latter is definitely a concept that most Algebra 2 students would not be able to grok.

peaton2• 12 years ago

I knew I was making a strong assertion when I mentioned function composition. I'm grateful for your feedback, but perhaps you could elaborate? I don't see why they have to be "very different". I think you called me on a certain case, but an example like this demonstrates that they are not so "very different":

    def a(b):
        m = 0
        return b(m)

Or even:

    def a(b):
        m = b(1)
        return m+7

I don't see how these are not a form of function composition. I'm definitely no expert. But I'd really appreciate an elaboration so I can learn from any mistake I'm making.

rapala• 12 years ago

One way to look at function composition is that it is a function to which you pass two functions and out comes a function:

  compose :: (b -> c) -> (a -> b) -> a -> c
  compose f g x = f (g x)

I'm not sure about the math curriculum in USA but in linear algebra you have functions that operate on functions.

MidsizeBlowfish• 12 years ago

Eliminating side effects is about a lot more than variable scope. One example would be reading from/writing to a file.

dustingetz• 12 years ago

I think it's an accurate description. The OS code that reads a file involves changing variables outside function scope, eg pointer writes to memory mapped hardware. Simply forcing all variables to be final, all the way down, really does eliminate all side effects.

cessor2• 12 years ago

I am not so much scared by functional programming as I am annoyed by functional programmers. I feel that they often come over like mathematics professors that just fill the chalkboard with lightning speed and look at you like "seriously, how dare you ask this dumb question". They go ahead explaining to you how your language is crap for all its sideeffects, smugly explaining how their language doesn't have those and then explain to you how Simon Peyton Jones shoehorned them into haskell with a monad. Also you always appear to fail to understand monads and they always fail to explain in an understandable way (although they're not that hard to get).

Functional programming is great and feels right, I am amazed how knowledge of fp affects my js, C# and Python up to this day. But from a social perspective: Loose the smugness, and then we'll talk fp.

cbp• 12 years ago

So you're unwilling to learn something potentially better because you're were offended by a (surely) tiny portion of its userbase? Lose the childish attitude. You owe it to your craft and users to keep learning and using better tools.

cessor2• 12 years ago

I think you just somewhat proved my point.

innguest21• 12 years ago

The reason you might be perceiving this is because once you're past the learning curve hump, the concepts become extremely obvious and the definitions stick to your head.

It takes me a few seconds to rewrite foldl from rote understanding: foldl f z (x:xs) = foldl f (f x) xs, because it takes a function, a 'zero', a list of head and tail, and calls itself again with the same function, a zero 'going up' (so accumulating) and a list 'going down' (being exhausted). So as you see this is an almost a visual way to understand it, which is natural to those that already are familiar with these abstractions, but is meaningless to those who don't.

If someone then says "how dare you ask that" then they have the wrong approach to things. Socrates asked every question and thought they were all valid. By asking the basics you learn the abstraction as if you're proving it to yourself, and that's more powerful.

So it boils down to familiarity, is what I'm trying to say. I usually come across as more passionate than arrogant about it. If you stick to it, it will make sense. It took me 4 years of Haskell exploration for it all to click really hard and now I'm trying to shorten other people's paths. In my opinion the gap is around mathematical abstractions, how they're created, what do they mean, how they actually relate to reality, and what work do they accomplish for us that we then don't need to do anymore.

mbell• 12 years ago

It takes me a few seconds to rewrite foldl from rote understanding: foldl f z (x:xs) = foldl f (f x) xs, because it takes a function, a 'zero', a list of head and tail, and calls itself again with the same function, a zero 'going up' (so accumulating) and a list 'going down' (being exhausted). So as you see this is an almost a visual way to understand it, which is natural to those that already are familiar with these abstractions, but is meaningless to those who don't.

I think this type of explanation falls into what the parent post is talking about. That is a technical accurate but very dry way to describe a construct that simply calls the function it's given for every element in a collection and returns the accumulation of the results. Granted you can dive into all sorts of discussions about what that _really_ means and what power it gives you, but save that for much later, it isn't introductory material.

An analogy to how functional programming often is taught would be if I tried to teach a new programming language by going over the BNF grammar first without context instead of starting with how the language is actually used in practice. It may be more 'technically correct' but it's a terribly ineffective way to learn for most people, even those who know and understand BNF. People are often more interested in what they can do or create with this new thing, not the nitty gritty details of how it works mathematically even if they intend to get into the details later.

mineo• 12 years ago

That should be "foldl f z (x:xs) = foldl f (f z x) xs" because the function f takes two arguments (the whole thing boils down to "(((z `f` x_1) `f` x_2) ... `f` x_n)").

freshhawk2• 12 years ago

Isn't this the blub paradox all over again? I hear the exact same thing about every other programmer in the world from some PHP/Node programmers who only know that language and insist is the best choice for every possible project.

I'm not saying that actual smugness doesn't exist, but almost all the time it's actually just projection from someone who's used to being in the know now struggling to understand something new.

Remember when you explained to someone using a language lower on the power spectrum (VB or PHP maybe) why they should use all the cool stuff that you can do in Ruby or Python, how much more productive they would be, how much more fun it was to work in? You thought you were helping them and showing your excitement, you wish someone had told you this a long time ago!

Unless you are a world class educator they were confused by some parts, threatened that their investment in their current language was losing value and worried they might not be able to function in this new world and therefore protected their ego by seeing you as smug.

AnimalMuppet2• 12 years ago

First: No, it's not just the blub paradox. The Haskell (and also Lisp) posters, even on HN, seem to have a higher proportion of smug self-congratulatory explanations-that-don't-really-explains-but-let-the-explainer-bask-in-his-or-her-sense-of-superiority posts than other languages do.

Second: The blub paradox (at least as posed by Paul Graham) is wrong. To see why, just look at Lisp and Haskell. Users of both languages are sure that they're at the top of the power curve. They're sure that when they look at the other language, they're looking down, and they can tell you precisely why ("it doesn't even have macros" and "it doesn't even have a decent type system", respectively). But they can't both be looking down at each other - unless languages cannot actually all be ordered along a single axis called "power".

In fact, you have to ask "power for what"? Once you do, you might start to see language power more as a tree than as a single line. You can really only compare power between languages on the same branch. Pick the language that gets you the furthest in the direction that your problem lies.

a-nikolaev• 12 years ago

Some Haskell proponents tend to be a bit annoying, Yes. But they are only a (not so big) subset on Haskell users.

Then, there are other FP languages, which you can easily learn in a few days/weeks, very nice and natural, e.g. OCaml, or SML, or maybe Scheme(Clojure?).

sgift• 12 years ago

Program in Java for a while and you get immune to smugness. "Java is so ..." Yeah, yeah, bring it on. While you do that I'll solve the problem and can go home.

Programming in PHP must have a similar effect.

chris_mahan10• 12 years ago

I'm not scared. It just does not make sense to me.

Just because I speak French and English fluently does not mean I can speak Japanese. My wife is Japanese, and speaks it fluently. We've been together 19 years. I've tried to learn. it just does not make sense. It would be nice, because I have relatives there, and I could go live there, legally, but it just doesn't make sense in my brain.

What can I do?

Functional programming is the same. Every couple of years I take a look, and I recoil in confusion.

It also doesn't help that people make fun of me for seeming dumb.

jeffasinger• 12 years ago

What worked for me was taking functional programming concepts, and applying them in languages where I was already comfortable. That way, I wasn't learning a new syntax and a new programming paradigm at the same time.

sanderjd5• 12 years ago

Which concepts did you find the most applicable? For me it is applying functions to collections in different ways, eg. map, fold, etc.

innguest21• 12 years ago

Can you say a few things about the parts that don't make sense to you? That would help me identify what beginners struggle with, as I'm developing tutorials for that reason.

chris_mahan10• 12 years ago

It's simple: the very concept of the program.

I want to write a program that reads one text file, and outputs another.

Let's say the first file contains a list of emails, one email per line.

The second file should contain the list of email domains in the first file, one line per email domain.

Procedurally, I would simply declare a list, read the file of emails, line by line, split each one on the @ symbol, and if the part on the right was not already on the list, I would add it to the list.

At the end, I would write the list to a new file, one line per item in the list.

How would one do that using functional programming?

agumonkey• 12 years ago

Functional programming is a hard compromise. Almost no mutation or side effects, every part of the system is encoded/encapsulated into a function entity. That's it.

The fun part is that many languages end up aiming for it. Good multithreaded/reentrant code is almost functional. I just saw a ruby rant asking to avoid mutation as much as possible. Same goes for PHP PSR-x ...

Functional programming suffers from acute mathematitis, the people behind it are fond of iterating too fast around their newfound concepts and it end up as cryptic as possible.

blktiger• 12 years ago

I have to say, it makes a big difference who you learn from (or perhaps how you learn). In college I had several courses where we programmed in Scheme and I hated every minute of them because I felt like Scheme made things harder and uglier with no tangible benefit.

Then I had a class where we learned Haskell with one of the best professors in the department. He basically taught me all of the great things about functional programming and now I try to use concepts from that class in whatever language I'm programming in.

Learning functional programming is paradigm-shifting and gives you a much broader set of tools to work with, but if it's not taught well it won't help you.

innguest21• 12 years ago

If you're interested in learning FP but struggling and would like to beta test didactic material for beginners, I urge you to get in touch with me. I'm making a series of videos explaining the concepts and abstractions of functional programming in a socratic way and from scratch (so not assuming even that numbers exist). I'm 'uploaded' at google's email service.

valarauca1• 12 years ago

Maybe its me being thick, but I can't honestly wrap my head around what the fundamental good thing in functional programming is. When ever I work in a functional language I just find myself missing objects.

OOP just feel more eloquent to look at personally.

        Struct.function(arg1, arg2, arg3);

feels more atheistically pleasing to my mental model of programming then

        function(struct, arg1, arg2, arg3);

This means more complex function definitions. While I can define multiple .close(); functions, that only operate in relation to their connection type I.E.: tcpConnection, serialConnection can each call their own close(). In FP I have to actually state either:

     fn close<T>(&:<T>){
           if(<T>::isType(tcpConnection)){
                tcpConnectionClose(<T>);
           }else if(<T>::isType(serialConnection)){
                serialConnectionClose(<T>);
           }else{
               //throw exception
           }
    }

Or I just make primitive calls to each connection type

    tcpConnectionClose(*);

This just doesn't stroke me the right way. It feels like bulky, over necessary coding when you take into account objects exist. I'm interested in FP, I feel it has to offer something for people to jump on it, but I just don't get it.

deadghost2• 12 years ago

fwiw, clojure supports polymorphism.

http://clojure.org/multimethods

I encountered this recently but I'll try to give a (bad) explanation.

You'll call `function(thing, arg1, arg2, arg3);`. Another function will run on the arguments and return a dispatch value. For example, it will check what `thing` is and return `struct`. The `struct` version of that function is then run on the args and gives you your value.

In this way you can define several `close` functions based on dispatch value instead of one monolith nested if/else `close`.

I'm on the opposite side of the fence, OOP has never ever appealed to me. "Why would anyone want to use this crazy mess?" kind of thing. I'm sure I can learn to appreciate it with time but it's not a native paradigm to my mind.

I only have experience with lisps when it comes to functional programming but the reason I enjoy it is that it's simple. You have functions and you have data. Functions transform data to more data and the two aren't tightly bound. If you pass a function a value it will always return the same result if you pass it the same value.

THE clojure video: http://www.infoq.com/presentations/Simple-Made-Easy (I don't think he even says the word clojure in the entire hour presentation.)

sanderjd5• 12 years ago

Not sure what language that is supposed to be, but in all the functional languages I've used, you would specify that T implements close and write an implementation for a TcpConnection and a SerialConnection, letting the compiler figure out which one to call when and obviating the runtime exception entirely.

innguest21• 12 years ago

Let me stress your point to the parent:

letting the compiler figure out which one to call when and obviating the runtime exception entirely.

That is how FP eliminates a whole category of bugs. You have to have "experience", which some love to boast, to know that it's better to have an else clause there and throw an exception.

If you think that's basic knowledge you'd be surprised with how little do "experienced" programmers that get paid very handsomely actually know; I've met 30-year of experience programmers that do not believe that the final-else-then-exception pattern is a good idea, because they think "crashing the program is never good". So what ends up happening is of course the program ends up crashing anyway (supposing you have passed an invalid connection in that case) but now the stack trace is potentially much deeper than it needs to be, and therefore misleading. All stack traces lose their value collectively because now we can't tell the good ones from the bad. That can make debugging harder than it needs to be.

But instead in FP, because it's a fundamentally different way to program, that situation doesn't even arise in the first place, obviating a solution. In FP things are modeled differently from OO, it's not just "procedures without an object jacket". The advantage here is the compiler verifies the "object" selection for you (which "class"/type of connection) and can provide some mathematical guarantees. Those guarantees are what metonymically "eliminate bugs".

So we can rely less on the programmer and more on the compiler. You know, like it's meant to be. After all we are sitting in front of a computer, so we should just let it do its thing without telling it how. Turns out autonomy in coming up with a solution is good both for the programmer and for the computer (and then again for the programmer).

innguest21• 12 years ago

That's great if every time you said "FP" you replace it with "procedural programming" because that's what you just illustrated.

FP has nothing to do with procedural programming at all, it is fundamentally different and diametrically opposed to both procedural and object oriented programming, which are then both in the same group away from FP.

You should look up some tutorials on FP if you want to understand what it means in practice.

Don’t Be Scared Of Functional Programming

Related Stories