6 ms·

"Study Functional Programming or Be Ignorant"

59 points by fogus 16y ago

hello_moto 16y ago
Programming Language is like Software Development Methodology: it works well in certain area but doesn't fit well in generalization. There are evangelists and purists in both world. Here's a challenge for all evangelists and purists: you keep telling people that your thing is the right way to go, but when I ask you to learn my thing, you refuse like a mad man. IT is a very funny industry, people keep telling you that we change the world, we have the power, we have the edge, we're the future or whatever. But at the end of the day, don't tell us to change ourselves.
- paulgb 16y ago
  Maybe I don't get out enough, but I've never met a Haskell programmer with that mentality (LISPers, maybe). All the Haskellers I know are pragmatic people who will use another language (usually Python, I guess because iterators feel a lot like lazy lists) when it's the right tool for the job.
afhof 16y ago
Its a pretty bold statement to say that programmers who don't use your favorite language or style are ignorant of how a computer works.
- Dunearhp 16y ago
  You can be a good bricklayer without knowing much about structural engineering. What happens when you want to build something taller than ten stories? What happens when you want to program for more than ten CPU cores?
  - stcredzero 16y ago
    Learning functional programming for a programmer is like learning programming for a non-programmer. Someone who is a logistics expert is valuable. A logistics expert who knows how to program is even more so. OO programmers who understand functional programming have a big advantage over OO programmers who don't. Learning FP gives one the mental tools to do better encapsulation.
  - joegaudet 16y ago
    I find the assertion that the ONLY way to program for multiple cores or concurrency is to use functional programming annoying. It seems to be the default fall back of functional evangelists, as if there were no other way in the world to solve concurrency. I recently took a course on concurrent programming, and the from what I learned, some problems are easier to deal with in erlang or something similar. But then again some aren't. And a lot of the time, they run an order of magnitude slower (though as my prof would say, correctness is sometimes more valuable than speed). And granted my Erlang program for matrix multiplication was very concise. My MPI implementation ran WAY faster. It seems to me, there are two schools of thought, and you can live in one, the other, or both. Certainly there are things to be learned in either. I think all one can take away from articles like this is that it's good to keep learning.
    - chc 16y ago
      You seem to be confusing "Erlang" with "functional programming." They are not equivalent. Erlang is not what makes functional style good for concurrency — it takes advantage of some of the factors, but it is not the be-all-end-all. Erlang's actor-based green-threaded messaging is only one concurrency style.
      - joegaudet 16y ago
        I was using Erlang as an example as I am familiar with it. My point was more so that there are (as you say) many styles of concurrency, and that I hate it when functional programers use "Try programming concurrently in an imperative language" as their fall back argument for the merits of FP.
        chc 16y ago
        That's because support for concurrency is one of the most relevant strengths of functional programming. It's a buzzword right now, and a lot of the advice for how to do it well points toward functional programming practices, so they see that and say, "Hey, we should let people know that we already have all this stuff!"
        16y ago
  - afhof 16y ago
    I have written code for hundreds of cores. (can you say CUDA?) It was written entirely in C and ran very fast.
    - johngunderman 16y ago
      Thats great, but anecdotal evidence doesn't really prove anything. CUDA lets you write multi-core code for GPUs, but imagine writing C code for hundreds of cores over a datacenter cluster. C isn't the right tool for that job.
- paulgb 16y ago
  I agree, so it's a good thing he didn't make that claim ;-) Lots of languages are incorporating functional features, from dynamic languages like Python to even Java's support for closures. To really get your head around these features, it pays to play with a real functional language for a bit.
miguelpais 16y ago
Is he also calling ignorant to the OO Scheme or Lisp programmers? The best approach appears to me to be taking the best of both worlds. Functional may solve lots of problems, but you can't deny the advantages of a good OO design. Just devise your OO architecture for good reusability, flexibility, low coupling and high cohesion and then just use the best that functional programming has to offer.
- jackfoxy 16y ago
  If Microsoft could pull it off, the ability to write both C# and F# inline in the same class, or at least the same file, would really be the best of both worlds. I'm not a languages guy, so I don't know if this idea is practical, but like everything else, it probably is "possible".
  - hello_moto 16y ago
    The world of programming will never agree in one thing, so if this would've happened, some people would love it and some would hate it. There will be new "patterns" on how to use both features without shooting yourself in the foot. There will be new libraries written that exploit the awesomeness of both features. At the end of the day, there will be people benefited from that, and there will be more segmentation in the industry. People will have to be trained (wait... that no longer exist in our industry). ... and I... I will move on to a more managerial position so I can put to rest the learning of programming language for the sake of learning and swinging ego than for actually building things.
  - arethuza 16y ago
    I rather like that idea - allowing different languages at the method level would be rather cool.
  - RodgerTheGreat 16y ago
    Wouldn't that be a lot like C#'s LINQ? The ability to drop complex, lazily-evaluated functional expressions into procedural C# is the closest example I've seen to blending the two methodologies. (Perhaps 'ideologies' would be a more accurate term?)
pietrofmaggi 16y ago
Knowing functional programming surely makes you a better programmer, as knowing lisp do (even if you could never use in your projects). But when I see post like this I always think to Fred Brooks' "There's no silver bullet" paper (http://en.wikipedia.org/wiki/No_Silver_Bullet http://en.wikipedia.org/wiki/No_Silver_Bullet).
- hello_moto 16y ago
  Knowing something new will make you a better person. If an OO programmer never knew functional programming, yeah, sure, he'll be a better programmer after learning LISP and I think the vice-versa is also true, a functional programmer who never bother learning OO because he thinks his paradigm is the silver bullet will benefit more knowledge if he decided to learn OO.
bsaunder 16y ago
Well, the title's a bit of a tautology, but it does seem that a bit of the glow has worn off of Java (to those that were captivated by it in the first place anyway). Functional programming seems to be trending upwards too. I agree with the general assertion that hard core OO developers (Java and .Net folks) will need to start learning some new mental models of programming to keep adding relevance. I think we will start solving some harder problems that are intractable with traditional OO mechanisms.
- jefffoster 16y ago
  Can you give some examples of the "harder problems that are intractable with traditional OO mechanisms"?
  - bsaunder 16y ago
    Yes, perhaps "are intractable" was too strong of an assertion. I think as we migrate our data towards more flexible structures and look more towards asynchronous parallel processing, we may find that splitting out data and behavior serves us better than tightly binding them as OO methodology does. I think ultimately we will treat our code and data as the same thing, just from different perspectives and levels of abstraction. I'm not sure most OO programming environments today support this notion easily. I do think we will be solving harder problems, but what exactly they are falls into my unknown unknowns category.
- deleted 16y ago
  [deleted]
Aaronontheweb 16y ago
If I said on this thread "oh yeah, I'm a pro at functional programming -I use LINQ alllllll the time" how many heads would explode?
eplanit 16y ago
"I still struggle to read most Haskell, and I certainly can’t use it to build anything"....but it's great; and, if you don't know all this cool esoteric stuff, you're ignorant. Have heard/read similar posts from fans of other fringe languages: Lisp, Scheme, Prolog, ... There are grand claims of superiority, but with little practical evidence to bear out the claims. I agree with other comments here -- the art of software design and programming is _generally_ independent of language. Languages, bad ones, inhibit good software engineering, and good ones enable if not encourage them (which is why good ones are typically minimal).
samstokes 16y ago
The most important parts of this article, IMHO: The bit that stirs me up is that this “stuff” isn’t, repeat is not, Haskell-specific. Its rooted in the fabric of our reality, in our mathematics and our problem domains, and bits poke up like the tips of icebergs into mainstream OO languages, their true structure part-revealed. But rarely in the OO-world have I found such carefully abstracted and subtle techniques of programming in daily use. Ideas from Haskell & Functional Programming will continue to flow into the mainstream over the next couple of decades. This is why it's important to read about things like immutable data structures and higher-kinded polymorphism, even if your problem domain (or personal / corporate style) is utterly unsuited to existing functional programming languages. This stuff isn't just obscure tricks for maths nerds to obsess over, it's fundamental to how programming works. If you want to understand LINQ, you need to understand higher-kinded polymorphism and monads. If you're writing a series of chained callbacks in Javascript and feel like there's some repetition you'd like to extract but can't quite put your finger on, you need to understand the continuation monad (I'm only about halfway there...) If you want to reason sensibly about concurrent updates to complex data structures, it helps a lot to know about immutable structure-sharing data structures.

59 points by fogus 16y ago

Programming Language is like Software Development Methodology: it works well in certain area but doesn't fit well in generalization. There are evangelists and purists in both world. Here's a challenge for all evangelists and purists: you keep telling people that your thing is the right way to go, but when I ask you to learn my thing, you refuse like a mad man. IT is a very funny industry, people keep telling you that we change the world, we have the power, we have the edge, we're the future or whatever. But at the end of the day, don't tell us to change ourselves.

paulgb 16y ago
Maybe I don't get out enough, but I've never met a Haskell programmer with that mentality (LISPers, maybe). All the Haskellers I know are pragmatic people who will use another language (usually Python, I guess because iterators feel a lot like lazy lists) when it's the right tool for the job.

afhof 16y ago

Its a pretty bold statement to say that programmers who don't use your favorite language or style are ignorant of how a computer works.

Dunearhp 16y ago
You can be a good bricklayer without knowing much about structural engineering. What happens when you want to build something taller than ten stories? What happens when you want to program for more than ten CPU cores?
- stcredzero 16y ago
  Learning functional programming for a programmer is like learning programming for a non-programmer. Someone who is a logistics expert is valuable. A logistics expert who knows how to program is even more so. OO programmers who understand functional programming have a big advantage over OO programmers who don't. Learning FP gives one the mental tools to do better encapsulation.
- joegaudet 16y ago
  I find the assertion that the ONLY way to program for multiple cores or concurrency is to use functional programming annoying. It seems to be the default fall back of functional evangelists, as if there were no other way in the world to solve concurrency. I recently took a course on concurrent programming, and the from what I learned, some problems are easier to deal with in erlang or something similar. But then again some aren't. And a lot of the time, they run an order of magnitude slower (though as my prof would say, correctness is sometimes more valuable than speed). And granted my Erlang program for matrix multiplication was very concise. My MPI implementation ran WAY faster. It seems to me, there are two schools of thought, and you can live in one, the other, or both. Certainly there are things to be learned in either. I think all one can take away from articles like this is that it's good to keep learning.
  - chc 16y ago
    You seem to be confusing "Erlang" with "functional programming." They are not equivalent. Erlang is not what makes functional style good for concurrency — it takes advantage of some of the factors, but it is not the be-all-end-all. Erlang's actor-based green-threaded messaging is only one concurrency style.
    - joegaudet 16y ago
      I was using Erlang as an example as I am familiar with it. My point was more so that there are (as you say) many styles of concurrency, and that I hate it when functional programers use "Try programming concurrently in an imperative language" as their fall back argument for the merits of FP.
      - chc 16y ago
        That's because support for concurrency is one of the most relevant strengths of functional programming. It's a buzzword right now, and a lot of the advice for how to do it well points toward functional programming practices, so they see that and say, "Hey, we should let people know that we already have all this stuff!"
      - 16y ago
- afhof 16y ago
  I have written code for hundreds of cores. (can you say CUDA?) It was written entirely in C and ran very fast.
  - johngunderman 16y ago
    Thats great, but anecdotal evidence doesn't really prove anything. CUDA lets you write multi-core code for GPUs, but imagine writing C code for hundreds of cores over a datacenter cluster. C isn't the right tool for that job.
paulgb 16y ago
I agree, so it's a good thing he didn't make that claim ;-) Lots of languages are incorporating functional features, from dynamic languages like Python to even Java's support for closures. To really get your head around these features, it pays to play with a real functional language for a bit.

miguelpais 16y ago

Is he also calling ignorant to the OO Scheme or Lisp programmers? The best approach appears to me to be taking the best of both worlds. Functional may solve lots of problems, but you can't deny the advantages of a good OO design. Just devise your OO architecture for good reusability, flexibility, low coupling and high cohesion and then just use the best that functional programming has to offer.

jackfoxy 16y ago
If Microsoft could pull it off, the ability to write both C# and F# inline in the same class, or at least the same file, would really be the best of both worlds. I'm not a languages guy, so I don't know if this idea is practical, but like everything else, it probably is "possible".
- hello_moto 16y ago
  The world of programming will never agree in one thing, so if this would've happened, some people would love it and some would hate it. There will be new "patterns" on how to use both features without shooting yourself in the foot. There will be new libraries written that exploit the awesomeness of both features. At the end of the day, there will be people benefited from that, and there will be more segmentation in the industry. People will have to be trained (wait... that no longer exist in our industry). ... and I... I will move on to a more managerial position so I can put to rest the learning of programming language for the sake of learning and swinging ego than for actually building things.
- arethuza 16y ago
  I rather like that idea - allowing different languages at the method level would be rather cool.
- RodgerTheGreat 16y ago
  Wouldn't that be a lot like C#'s LINQ? The ability to drop complex, lazily-evaluated functional expressions into procedural C# is the closest example I've seen to blending the two methodologies. (Perhaps 'ideologies' would be a more accurate term?)

pietrofmaggi 16y ago

Knowing functional programming surely makes you a better programmer, as knowing lisp do (even if you could never use in your projects). But when I see post like this I always think to Fred Brooks' "There's no silver bullet" paper (http://en.wikipedia.org/wiki/No_Silver_Bullet http://en.wikipedia.org/wiki/No_Silver_Bullet).

hello_moto 16y ago
Knowing something new will make you a better person. If an OO programmer never knew functional programming, yeah, sure, he'll be a better programmer after learning LISP and I think the vice-versa is also true, a functional programmer who never bother learning OO because he thinks his paradigm is the silver bullet will benefit more knowledge if he decided to learn OO.

bsaunder 16y ago

Well, the title's a bit of a tautology, but it does seem that a bit of the glow has worn off of Java (to those that were captivated by it in the first place anyway). Functional programming seems to be trending upwards too. I agree with the general assertion that hard core OO developers (Java and .Net folks) will need to start learning some new mental models of programming to keep adding relevance. I think we will start solving some harder problems that are intractable with traditional OO mechanisms.

jefffoster 16y ago
Can you give some examples of the "harder problems that are intractable with traditional OO mechanisms"?
- bsaunder 16y ago
  Yes, perhaps "are intractable" was too strong of an assertion. I think as we migrate our data towards more flexible structures and look more towards asynchronous parallel processing, we may find that splitting out data and behavior serves us better than tightly binding them as OO methodology does. I think ultimately we will treat our code and data as the same thing, just from different perspectives and levels of abstraction. I'm not sure most OO programming environments today support this notion easily. I do think we will be solving harder problems, but what exactly they are falls into my unknown unknowns category.
deleted 16y ago
[deleted]

Aaronontheweb 16y ago

If I said on this thread "oh yeah, I'm a pro at functional programming -I use LINQ alllllll the time" how many heads would explode?

eplanit 16y ago

"I still struggle to read most Haskell, and I certainly can’t use it to build anything"....but it's great; and, if you don't know all this cool esoteric stuff, you're ignorant. Have heard/read similar posts from fans of other fringe languages: Lisp, Scheme, Prolog, ... There are grand claims of superiority, but with little practical evidence to bear out the claims. I agree with other comments here -- the art of software design and programming is _generally_ independent of language. Languages, bad ones, inhibit good software engineering, and good ones enable if not encourage them (which is why good ones are typically minimal).

samstokes 16y ago

The most important parts of this article, IMHO: The bit that stirs me up is that this “stuff” isn’t, repeat is not, Haskell-specific. Its rooted in the fabric of our reality, in our mathematics and our problem domains, and bits poke up like the tips of icebergs into mainstream OO languages, their true structure part-revealed. But rarely in the OO-world have I found such carefully abstracted and subtle techniques of programming in daily use. Ideas from Haskell & Functional Programming will continue to flow into the mainstream over the next couple of decades. This is why it's important to read about things like immutable data structures and higher-kinded polymorphism, even if your problem domain (or personal / corporate style) is utterly unsuited to existing functional programming languages. This stuff isn't just obscure tricks for maths nerds to obsess over, it's fundamental to how programming works. If you want to understand LINQ, you need to understand higher-kinded polymorphism and monads. If you're writing a series of chained callbacks in Javascript and feel like there's some repetition you'd like to extract but can't quite put your finger on, you need to understand the continuation monad (I'm only about halfway there...) If you want to reason sensibly about concurrent updates to complex data structures, it helps a lot to know about immutable structure-sharing data structures.