9 ms·

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

177 points by trptcolin 15y ago

dasil003 15y ago
The thing that got me really interested in learning Haskell was the realization that something like 90% of the nasty bugs that I fixed in production over the years would be have been impossible in a pure functional language. The thing that slows me down is the prospect of actually getting paid to write Haskell, and my doubts about it's ultimate suitability for iterate-quickly, fail-fast software world. But reading this article reinvigorates me. Pure functional programming may be much harder, but its rigor allows for more powerful abstractions. Grokking those abstractions is no doubt useful regardless of what language you're using.
- thesz 15y ago
  >doubts about it's ultimate suitability for iterate-quickly, fail-fast software world. Lest you doubt: http://thesz.mskhug.ru/svn/hiersort/doc/hhm-eng.pdf http://thesz.mskhug.ru/svn/hiersort/doc/hhm-eng.pdf We did a cycle-accurate prototype of MIPS CPU with some twists. In Haskell. For Haskell to shine in prototyping you have to apply it to some critical and new task, where type system works with you, preventing errors. The novelty is crucial, I think. You will have to explore the solution space with the help of some sort of theorem prover (type system).
  - ThaddeusQuay2 15y ago
    "You will have to explore the solution space with the help of some sort of theorem prover (type system)." Have you tried ATS (Applied Type System)? http://en.wikipedia.org/wiki/ATS_(programming_language) http://en.wikipedia.org/wiki/ATS_(programming_language)
    - thesz 15y ago
      No, I haven't. When I looked at it, I didn't see a well-composed thing like Epigram or Agda2. So I decided to stick to Haskell for a while and then slowly work my way to Agda2, if I would feel the need.
- richcollins 15y ago
  They might have been impossible but how long would it have taken to write the functional code vs write the code with side effects and fix the bugs?
rednum 15y ago
It is worth noting that there are a few other paradigms that can change the way you think of programming - recently there was a post providing a good overview of languages that will make you learn some new abstractions, functional programming being one of them: http://blog.fogus.me/2011/08/14/perlis-languages/ http://blog.fogus.me/2011/08/14/perlis-languages/
deleted 15y ago
[deleted]
stmartin 15y ago
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 know they are deeply and profoundly anti-social, feel good about themselves, to feel special, as though they have the "upper hand" that other normal people who deliberately choose other languages over purely functional ones. There is value in learning how to think recursively, but a lot of programming, especially systems programming doesn't need to have its for loops transformed into recursive functions, or its addition operators into primitive recursive functions. I am sick and tired of people expounding on the alleged efficacy and efficiency of functional languages and I wish they would just STFU once and for all and go back to their porn intermezzos between their functional programming spurts.
- klez 15y ago
  I'm not a FP-fan boy (yet), but it seems you have a very limited view of FP. It's not just recursion...
  - marshray 15y ago
    I assure you, it's recursion all the way down.
- deleted 15y ago
  [deleted]
- joemoon 15y ago
  Wow, this is really dramatic.
- tete 15y ago
  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 functional programming harder. I actually do have more problems with (C++/Java/Python style) OO, even though I like it when it is a real language concept, like in Smalltalk and others. But I am weird. I consider Assembly to be easier (to learn) than C(++) and Perl easier (to read) than most other scripting languages. I think it is a lot about the way you think. A language has to compensate the things that are hard for you so you can concentrate on the easy stuff. It's a bit like having different tutorials or teachers. There are people that think similar to you while there are other who think very different. It's a common problem in schools. If the teacher thinks in a different way the pupils will have a hard time.
tumult 15y ago
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.
- dustingetz 15y ago
  Care to elaborate?
  - tumult 15y ago
    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 programmers. It's not true. Functional programming is just the general notion of using more functions, and less computer-architectury things, to express your ideas. It's not necessarily about map/reduce, monads, or whatever. Encode your ideas mostly as functions where possible. That's it. It's bad to say that functional programming is hard on purpose, or that it makes you a part of some elite cadre. Functional programming should be, and usually is, no harder than any other way to explicitly write down your ideas. The whole point is to make it more simple to express your ideas in a way that can be evaluated by a computer. Functional programming isn't hard. Programming is hard.
    - tptacek 15y ago
      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.
      - tumult 15y ago
deleted 15y ago
[deleted]
Paddy3118 15y ago
The "One True Language Paradigm".... ... Is functional programming! (while it lasts that is). Keeps the money circulating.
deleted 15y ago
[deleted]
nirvana 15y ago
I love Erlang so much I haven't yet gotten around to learning another functional language. (still growing with erlang). I learned it reading Armstrong's book from Pragmatic Programmers. It was a joy. I'm also reading the OReilly book, and it seems good as well, though I can't tell how it would be if I didn't know the language already. As for the titles-- one is Programming Erlang, and the other is Erlang Programming!
- stmartin 15y ago
  I think you should learn Brainf*ck. It has awesome mental/intellectual benefits to you as a Erlang lover. No, but really.... ! And if you don't you will suffer! Muahaha!
  - nirvana 15y ago
    Erlang is easy to read and makes a lot of sense, without requiring much brainpower... if you'll take a few days and read about it. I think its kinda silly that people will just ignore a language because it doesn't look like java/C/pascal. Its not like the syntax of erlang is stupid, or pointlessly obtuse.
    - SoftwareMaven 15y ago
      IMO, the only really ugly part of Erlang is it's record syntax, but it's binary handling more than makes up for it! Doing Erlang at the day job for the last few months has been awesome. I really wish it would catch on more. Maybe when the JVM supports tail-call optimization and there is a JVM implementation of the runtime...
      - rvirding 15y ago
        We know, we know. BUT no one has come up with a better syntax that really works, all the time. There have been suggestions but none have really worked.
    - barrym 15y ago
kenjackson 15y ago
I'd really love to hear PG defend this line: "But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too." I'd really love to see the code for something that one would do in a day or two in Lisp, but would be much longer in another language. I don't suspect there exists a wide class of such things -- I suspect the features tend to look like embedding Lisp compilers.
- dustingetz 15y ago
  i speculate the edge compounds as, say, a competitors java codebase's complexity increases faster than a lisp codebase. exponentiate this over time and the edge is obvious.
  - dpritchett 15y ago
    The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- anghyflawn 15y ago
  Also speculating, but I would hazard a guess that a lot of that was due to the fact that the library ecosystem was much smaller then, which means people would be implementing things that you don't have to think too hard about now.
- richcollins 15y ago
  It's not because they were using lisp. It's because everyone else was using C.
mwexler 15y ago
Ok, I've been a procedural programmer for years. I struggle even with OO. Where's my easy bridge to Functional? Where's the killer "here's the trick, the secret, the leap"? Because I have to say, for all the "functional will save you" mantras, I keep finding a procedural approach gets the problem solved. Are my problems too simple? Not scale issues? Perhaps. And clearly, I am not trained in anything other than intro Lisp and Hadoop, so I haven't had the deep dive indoctrination others appear to have had. But as each new computing metaphor comes, we find ways to make it easy for folks trained in older metaphors to come over. Other than Scala, I've found few bridges that are trying to help procedural and OO lang folks adopt functional. It's no-one's fault, I guess, other than new folks are trained in it, and older folks aren't. But I'll keep looking for that bridge, that shining one thing that will make me go "aahhha, I see" and not "one of these books will explain how passing this function through this multi-nested other function is better than just making a loop". Because after all these articles, I know functional is great. I just feel bad that I haven't been able to make it great for me... yet.
- dustingetz 15y ago
  one of the cardinal rules of OO is: "each unit (method, object, whatever) should do exactly one thing"[3]. this rule is universally ignored in all the big OO codebases I've seen[1]. applying this rule with discipline, forces you to have a better understanding of what your code is actually doing. I think, that applying this rule even in OO languages forces you towards "functional-style in the small, object-oriented in the large", and the only difference is your code will have fewer classes/methods, and more high-level data-structures with operations like list.filter on them. [1] i get it, refactoring takes discipline and time, and desire to practice and learn[2], and a team of like minded people, on top of sensible business constraints. [2] http://www.dustingetz.com/nostrademons-75h-work-week-harmful-to-personal-growth http://www.dustingetz.com/nostrademons-75h-work-week-harmful... [3] http://en.wikipedia.org/wiki/Single_responsibility_principle http://en.wikipedia.org/wiki/Single_responsibility_principle edit: added source for single-responsibility principle
  - SamReidHughes 15y ago
    That's not a cardinal rule of OO or even a rule of OO.
Dn_Ab 15y ago
I see that some people are saying that functional programming is more powerful than OOP. I disagree with that. I do not think one is less than the other. Actually there is a mathematical argument why one is not less than the other. To me functional programming is "what does what I'm trying to describe do?". In object oriented programming it's "what are the properties of the thing I'm trying to describe?". In functional programming I describe the interactions directly and in OOP the interactions come about from how I have described the objects. Done properly, they are both about interactions, it is just a difference of what you focus on. It has been shown that classes of OOP can be modelled for the most part as co-algebras. This means that objects are a mathematical dual to algebraic types of functional programming. The reason why functional programming is important is that some things are easier to express in a dual space. This means that many things that are hard in OOP are trivial in functional languages. But the reverse is also true. This is why it is important to not drop one for the other. The real advantage IMO in functional programming is that these languages tend to be developed with stronger mathematical foundations. Hence programming in them tends to encourage people to be principled and rigorous (at least in theory). It is very likely that if you study the subject you will naturally come to be interested in why monads are only one particular type of functor, that polymorphic functions are well described as natural transformations or try to wrap your head around mechanically generating dynamic algorithms in terms of hylomorphisms. The more mathematical nature also makes it less magical and rickety to the self taught programmer (such as myself). That I think is the real advantage. But there is nothing inherent in OOP that stops it from also being built from more rigorous foundations. Such things will come to matter more with increasing concerns in security. I think functional programmers sleep on the power of coalgebras. In fact his example of google map reduce is completely ignorant of the fact that the real hero in MapReduce tm is unfold not reduce. I have a pet theory that the fact that algorithms are written in dual styles is why experienced OOP people find functional programming so hard. They literally have to reverse their style of thinking. This takes a lot of energy. Just because it takes place in your head doesn't make it any less physical than trying to roll a boulder uphill or get a wagon wheel out of a rut. http://www.cs.ru.nl/E.Poll/papers/durham97.pdf http://www.cs.ru.nl/E.Poll/papers/durham97.pdf
- dustingetz 15y ago
  i think the root problem here is out-of-band -- expertly written OO models are fine. the problem is that i've never encountered an expertly written OO system, which is probably because OO allows you to get lazy, where functional patterns require thought and understanding. i'm gradually starting to suspect that an expertly written OO system actually kinda looks like a functional system, except with practical compromises with respect to functional purity.
Eliezer 15y ago
And here I was expecting the surprise moral to be, "Functional code looks better than average, just because only smarter-than-average programmers can manage to work in FP languages."
Apocryphon 15y ago
How about learning functional JavaScript?
richcollins 15y ago
Functional Programming Is Hard, That's Why It's Good This is a major issue in software development. Developers like a challenge so they are often drawn to complexity. Unfortunately, this interest in complexity often carries over into their work.
gregburek 15y ago
I have an electrical engineering background and all this FP VS IP sounds like Async Logic VS State Machines. How far off base is that description?
vegai 15y ago
I have done a few real, production projects with Haskell, and I've come to realize that a lot of interest in it is hype. The paradigm is neat, the language is relatively well designed (considering that it's an academic committee language) and the implementation is passable. Programmers sadly forget that the greatest challenge of software creation very often happens outside of your text editor: it happens in the domain, in architecture, specification and communication. If you succeed in those, your project will succeed, no matter which language* you chose. If you fail in them, no amount of strictness in your programming language will save you. * unless of course it's Java
quizbiz 15y ago
Can anyone recommend any resources for getting started with Scheme?
- rimmjob 15y ago
  the little schemer series was very good. you can safely skip the first 5 chapters if you're comfortable with recursion. learn scheme in fixnum days is good too for learning the language right away.
kwithl 15y ago
In the first paragraph a dialect of Lisp is considered a functional programming language. So I don't read any more. 133 points for this?
brohee 15y ago
"Pointers are a very powerful and fundamental abstraction" An abstraction of what? Can't get much closer to the metal than with pointers. Frankly I'm not sure someone writing this have much insight worth wasting time on.

177 points by trptcolin 15y ago

The thing that got me really interested in learning Haskell was the realization that something like 90% of the nasty bugs that I fixed in production over the years would be have been impossible in a pure functional language. The thing that slows me down is the prospect of actually getting paid to write Haskell, and my doubts about it's ultimate suitability for iterate-quickly, fail-fast software world. But reading this article reinvigorates me. Pure functional programming may be much harder, but its rigor allows for more powerful abstractions. Grokking those abstractions is no doubt useful regardless of what language you're using.

thesz 15y ago
>doubts about it's ultimate suitability for iterate-quickly, fail-fast software world. Lest you doubt: http://thesz.mskhug.ru/svn/hiersort/doc/hhm-eng.pdf http://thesz.mskhug.ru/svn/hiersort/doc/hhm-eng.pdf We did a cycle-accurate prototype of MIPS CPU with some twists. In Haskell. For Haskell to shine in prototyping you have to apply it to some critical and new task, where type system works with you, preventing errors. The novelty is crucial, I think. You will have to explore the solution space with the help of some sort of theorem prover (type system).
- ThaddeusQuay2 15y ago
  "You will have to explore the solution space with the help of some sort of theorem prover (type system)." Have you tried ATS (Applied Type System)? http://en.wikipedia.org/wiki/ATS_(programming_language) http://en.wikipedia.org/wiki/ATS_(programming_language)
  - thesz 15y ago
    No, I haven't. When I looked at it, I didn't see a well-composed thing like Epigram or Agda2. So I decided to stick to Haskell for a while and then slowly work my way to Agda2, if I would feel the need.
richcollins 15y ago
They might have been impossible but how long would it have taken to write the functional code vs write the code with side effects and fix the bugs?

rednum 15y ago

It is worth noting that there are a few other paradigms that can change the way you think of programming - recently there was a post providing a good overview of languages that will make you learn some new abstractions, functional programming being one of them: http://blog.fogus.me/2011/08/14/perlis-languages/ http://blog.fogus.me/2011/08/14/perlis-languages/

deleted 15y ago

[deleted]

stmartin 15y ago

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 know they are deeply and profoundly anti-social, feel good about themselves, to feel special, as though they have the "upper hand" that other normal people who deliberately choose other languages over purely functional ones. There is value in learning how to think recursively, but a lot of programming, especially systems programming doesn't need to have its for loops transformed into recursive functions, or its addition operators into primitive recursive functions. I am sick and tired of people expounding on the alleged efficacy and efficiency of functional languages and I wish they would just STFU once and for all and go back to their porn intermezzos between their functional programming spurts.

klez 15y ago
I'm not a FP-fan boy (yet), but it seems you have a very limited view of FP. It's not just recursion...
- marshray 15y ago
  I assure you, it's recursion all the way down.
deleted 15y ago
[deleted]
joemoon 15y ago
Wow, this is really dramatic.
tete 15y ago
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 functional programming harder. I actually do have more problems with (C++/Java/Python style) OO, even though I like it when it is a real language concept, like in Smalltalk and others. But I am weird. I consider Assembly to be easier (to learn) than C(++) and Perl easier (to read) than most other scripting languages. I think it is a lot about the way you think. A language has to compensate the things that are hard for you so you can concentrate on the easy stuff. It's a bit like having different tutorials or teachers. There are people that think similar to you while there are other who think very different. It's a common problem in schools. If the teacher thinks in a different way the pupils will have a hard time.

tumult 15y ago

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.

dustingetz 15y ago
Care to elaborate?
- tumult 15y ago
  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 programmers. It's not true. Functional programming is just the general notion of using more functions, and less computer-architectury things, to express your ideas. It's not necessarily about map/reduce, monads, or whatever. Encode your ideas mostly as functions where possible. That's it. It's bad to say that functional programming is hard on purpose, or that it makes you a part of some elite cadre. Functional programming should be, and usually is, no harder than any other way to explicitly write down your ideas. The whole point is to make it more simple to express your ideas in a way that can be evaluated by a computer. Functional programming isn't hard. Programming is hard.
  - tptacek 15y ago
    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.
    - tumult 15y ago

deleted 15y ago

[deleted]

Paddy3118 15y ago

The "One True Language Paradigm".... ... Is functional programming! (while it lasts that is). Keeps the money circulating.

deleted 15y ago

[deleted]

nirvana 15y ago

I love Erlang so much I haven't yet gotten around to learning another functional language. (still growing with erlang). I learned it reading Armstrong's book from Pragmatic Programmers. It was a joy. I'm also reading the OReilly book, and it seems good as well, though I can't tell how it would be if I didn't know the language already. As for the titles-- one is Programming Erlang, and the other is Erlang Programming!

stmartin 15y ago
I think you should learn Brainf*ck. It has awesome mental/intellectual benefits to you as a Erlang lover. No, but really.... ! And if you don't you will suffer! Muahaha!
- nirvana 15y ago
  Erlang is easy to read and makes a lot of sense, without requiring much brainpower... if you'll take a few days and read about it. I think its kinda silly that people will just ignore a language because it doesn't look like java/C/pascal. Its not like the syntax of erlang is stupid, or pointlessly obtuse.
  - SoftwareMaven 15y ago
    IMO, the only really ugly part of Erlang is it's record syntax, but it's binary handling more than makes up for it! Doing Erlang at the day job for the last few months has been awesome. I really wish it would catch on more. Maybe when the JVM supports tail-call optimization and there is a JVM implementation of the runtime...
    - rvirding 15y ago
      We know, we know. BUT no one has come up with a better syntax that really works, all the time. There have been suggestions but none have really worked.
  - barrym 15y ago

kenjackson 15y ago

I'd really love to hear PG defend this line: "But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too." I'd really love to see the code for something that one would do in a day or two in Lisp, but would be much longer in another language. I don't suspect there exists a wide class of such things -- I suspect the features tend to look like embedding Lisp compilers.

dustingetz 15y ago
i speculate the edge compounds as, say, a competitors java codebase's complexity increases faster than a lisp codebase. exponentiate this over time and the edge is obvious.
- dpritchett 15y ago
  The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
anghyflawn 15y ago
Also speculating, but I would hazard a guess that a lot of that was due to the fact that the library ecosystem was much smaller then, which means people would be implementing things that you don't have to think too hard about now.
richcollins 15y ago
It's not because they were using lisp. It's because everyone else was using C.

mwexler 15y ago

Ok, I've been a procedural programmer for years. I struggle even with OO. Where's my easy bridge to Functional? Where's the killer "here's the trick, the secret, the leap"? Because I have to say, for all the "functional will save you" mantras, I keep finding a procedural approach gets the problem solved. Are my problems too simple? Not scale issues? Perhaps. And clearly, I am not trained in anything other than intro Lisp and Hadoop, so I haven't had the deep dive indoctrination others appear to have had. But as each new computing metaphor comes, we find ways to make it easy for folks trained in older metaphors to come over. Other than Scala, I've found few bridges that are trying to help procedural and OO lang folks adopt functional. It's no-one's fault, I guess, other than new folks are trained in it, and older folks aren't. But I'll keep looking for that bridge, that shining one thing that will make me go "aahhha, I see" and not "one of these books will explain how passing this function through this multi-nested other function is better than just making a loop". Because after all these articles, I know functional is great. I just feel bad that I haven't been able to make it great for me... yet.

dustingetz 15y ago
one of the cardinal rules of OO is: "each unit (method, object, whatever) should do exactly one thing"[3]. this rule is universally ignored in all the big OO codebases I've seen[1]. applying this rule with discipline, forces you to have a better understanding of what your code is actually doing. I think, that applying this rule even in OO languages forces you towards "functional-style in the small, object-oriented in the large", and the only difference is your code will have fewer classes/methods, and more high-level data-structures with operations like list.filter on them. [1] i get it, refactoring takes discipline and time, and desire to practice and learn[2], and a team of like minded people, on top of sensible business constraints. [2] http://www.dustingetz.com/nostrademons-75h-work-week-harmful-to-personal-growth http://www.dustingetz.com/nostrademons-75h-work-week-harmful... [3] http://en.wikipedia.org/wiki/Single_responsibility_principle http://en.wikipedia.org/wiki/Single_responsibility_principle edit: added source for single-responsibility principle
- SamReidHughes 15y ago
  That's not a cardinal rule of OO or even a rule of OO.

Dn_Ab 15y ago

I see that some people are saying that functional programming is more powerful than OOP. I disagree with that. I do not think one is less than the other. Actually there is a mathematical argument why one is not less than the other. To me functional programming is "what does what I'm trying to describe do?". In object oriented programming it's "what are the properties of the thing I'm trying to describe?". In functional programming I describe the interactions directly and in OOP the interactions come about from how I have described the objects. Done properly, they are both about interactions, it is just a difference of what you focus on. It has been shown that classes of OOP can be modelled for the most part as co-algebras. This means that objects are a mathematical dual to algebraic types of functional programming. The reason why functional programming is important is that some things are easier to express in a dual space. This means that many things that are hard in OOP are trivial in functional languages. But the reverse is also true. This is why it is important to not drop one for the other. The real advantage IMO in functional programming is that these languages tend to be developed with stronger mathematical foundations. Hence programming in them tends to encourage people to be principled and rigorous (at least in theory). It is very likely that if you study the subject you will naturally come to be interested in why monads are only one particular type of functor, that polymorphic functions are well described as natural transformations or try to wrap your head around mechanically generating dynamic algorithms in terms of hylomorphisms. The more mathematical nature also makes it less magical and rickety to the self taught programmer (such as myself). That I think is the real advantage. But there is nothing inherent in OOP that stops it from also being built from more rigorous foundations. Such things will come to matter more with increasing concerns in security. I think functional programmers sleep on the power of coalgebras. In fact his example of google map reduce is completely ignorant of the fact that the real hero in MapReduce tm is unfold not reduce. I have a pet theory that the fact that algorithms are written in dual styles is why experienced OOP people find functional programming so hard. They literally have to reverse their style of thinking. This takes a lot of energy. Just because it takes place in your head doesn't make it any less physical than trying to roll a boulder uphill or get a wagon wheel out of a rut. http://www.cs.ru.nl/E.Poll/papers/durham97.pdf http://www.cs.ru.nl/E.Poll/papers/durham97.pdf

dustingetz 15y ago
i think the root problem here is out-of-band -- expertly written OO models are fine. the problem is that i've never encountered an expertly written OO system, which is probably because OO allows you to get lazy, where functional patterns require thought and understanding. i'm gradually starting to suspect that an expertly written OO system actually kinda looks like a functional system, except with practical compromises with respect to functional purity.

Eliezer 15y ago

And here I was expecting the surprise moral to be, "Functional code looks better than average, just because only smarter-than-average programmers can manage to work in FP languages."

Apocryphon 15y ago

How about learning functional JavaScript?

richcollins 15y ago

Functional Programming Is Hard, That's Why It's Good This is a major issue in software development. Developers like a challenge so they are often drawn to complexity. Unfortunately, this interest in complexity often carries over into their work.

gregburek 15y ago

I have an electrical engineering background and all this FP VS IP sounds like Async Logic VS State Machines. How far off base is that description?

vegai 15y ago

I have done a few real, production projects with Haskell, and I've come to realize that a lot of interest in it is hype. The paradigm is neat, the language is relatively well designed (considering that it's an academic committee language) and the implementation is passable. Programmers sadly forget that the greatest challenge of software creation very often happens outside of your text editor: it happens in the domain, in architecture, specification and communication. If you succeed in those, your project will succeed, no matter which language* you chose. If you fail in them, no amount of strictness in your programming language will save you. * unless of course it's Java

quizbiz 15y ago

Can anyone recommend any resources for getting started with Scheme?

rimmjob 15y ago
the little schemer series was very good. you can safely skip the first 5 chapters if you're comfortable with recursion. learn scheme in fixnum days is good too for learning the language right away.

kwithl 15y ago

In the first paragraph a dialect of Lisp is considered a functional programming language. So I don't read any more. 133 points for this?

brohee 15y ago

"Pointers are a very powerful and fundamental abstraction" An abstraction of what? Can't get much closer to the metal than with pointers. Frankly I'm not sure someone writing this have much insight worth wasting time on.