9 ms·

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 eff

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.
- stmartin 15y ago
  "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 fashion in C? Or even in Lisp, if you really cared to? You could also write a very 'functional' program in C if you really wanted to. Why is everything black and white with geeks, is beyond my wildest dreams - but it just points to a lack of mature thinking.
  - MrKurtHaeusler 15y ago
    Common Lisp at least has full support for object-orientation. You don't have to roll it yourself like with C.
    - stmartin 15y ago
      Which is why I find CL more appealing to my palate...
deleted 15y ago
[deleted]
KirinDave 15y ago
I think you're misunderstanding the aim of my essay. It's not to say that FP is uniformly superior to OOP. It's that there is value (and difficulty) in learning the functional abstractions. The same is true of most programming paradigms, but we live in a world where FP is one of the less understood and increasingly relevant tools. Do you really think this is so controversial?
- stmartin 15y ago
  Controversial is hiding a bastard child in plain sight for 10+ years while running a state. You're not :). Joke aside - I don't want to write essays here, so I'm gonna try to make a hopefully brief point. I -know- your essay was well-intentioned, and believe me, so is my reaction, after having written software for a living for nearly 15 years... Rather than to expound - let me ask you - do you know of Martin Fowler? I can get Graham and his cult-like persona has ensnared you/others somewhat in his FP-Kool-Aid cult :D... but read Fowler for a bit of balance too. Your intention was actually awesome - you want to illustrate a general principle, e.g. an abstraction, that thinking via and writing through a functional paradigm/language makes you a better programmer. Is that "true" to the extent you and a bunch of other FP-evangelists claim? Why, yes it is! So is learning assembly language, or Brainf*ck for that matter.... Why I mentioned and really enjoy reading Fowler's non-imposing, well-argumented style of writing is because he effectively does, what you bravely attempt to do here, convey a general principle about _programming languages_, except he does it expertly, whereas you do it naively, despite the good intention. To get what I'm saying, surf over to www.amzn.com, and get yourself a copy of Fowler's Domain Specific Languages. Upon reading that book, heck, even half way, you soon come to the same realization that what one of the other repliers to my original rant has come into some time ago - we are ultimately discussing various paradigms/philosophies of thinking. Not ONE single or multiple paradigms that are tailored to your particular way of thinking or that you are "hard wired" for (which I find hard to believe, but I'll grant some 'nature vs nurture' arguments here too), makes you or anyone else, me included, necessarily a 'better' programmer... I'd go as far as saying that it's probably your personality, mental/emotional states you experience on a daily basis while glued to your PC, that have you be more or less effective at programming, e.g. you're a 'perfectionist/procrastinator', most common among programmers, or you're extreme and reckless and use inadequate tools to just conjure something up, looking to get 'promoted' and it blows up a few months later or BSOD's in a demo to the board of directors.... This has been said over and over, and for some reason, it doesn't sink in - there is no silver bullet, there is no 'better/worse' programmer - unless you count lines of code produced per day as a 'productivity measure', hardly a clever measure of anything... Back to your essay - I'd much rater you embark on the topic of DSLs, rather than using CL as a platform to write a DSL in - which is -fine- except maybe people who are unfamiliar with Lisp's syntax, e.g. domain experts, can relate to a specific, external DSL better than they can relate to a LISP based DSL... Think of teaching a DSL to a ... I dunno, a postal worker who examines mail rejects that didn't pass the OCR phase. You could construct a DSL specific to that purpose. It would be relevant and useful and increase the worker's productivity. On the flipside, teaching him Lisp, such that he can learn a DSL designed inside of Lisp, would be a pain in the ass... DSLs, e.g. macros, are one of the highly touted benefits of Common Lisp, which I actually like, because of its multiparadigm ('dirty') nature... Anyway, I don't really want to indulge here - I think if you are serious about writing something, which I believe you are - be as balances as you can be, and never throw ANYONE under the bridge - including people who have only coded VB in their life.... You are either on board w/all people, or you're alone. Smugness about a particular paradigm is something I'd stay away from, as well as people who hypnotize you with their eloquence and "successes" (financial or otherwise) into thinking that they've discovered the next best thing since sliced bread..... This is why, as much as I like my Macbook, I still think Apple's a cult, and that Linux will eventually prevail, even on mobile platforms, tablets, etc. Peace.
danenania 15y ago
"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." What is the point of this vitriol? Makes you seem fairly anti-social yourself.
BDFL_Xenu 15y ago
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.
dasil003 15y ago
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.
- deleted 15y ago
  [deleted]
- ebiester 15y ago
  Here's the problem I have with this: nearly everything I do involves state. It's called a database. Let's take a simple example, a to-do list. Abstracted out to its essentials (a piece of paper), the to-do list is exclusively state. Add a task, complete a task. Now, I can write a program that manages a to-do list in a functional language. There are two options. (Let's assume this is a web app.) First, I can make the client manage the state. Each time they use the application, they bookmark the last page. This is obviously inconvenient, but it's pure. Every input has a distinct output. Send the entire to-do list and what you wish to add or complete as input, receive an update copy of the state in return. It's always immutable state. It's also inconvenient if you ever want to use this on another computer. So, like most to-do lists, we use a database on the server side to manage the state of the application. However, you've lost the entire benefit of immutable state! You are not guaranteed to get the same output given an input. We're back to square one, aren't we? What's functional about mutable state? Now, in a subset of programs, eliminating mutable state is beneficial. 99% of scientific programming would be best served by FP. However, I've never seen an answer to how we can still call any system functional once we add a database. And at that point, why aren't we using a language that is bad at what we expressly need in the first place?

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.

stmartin 15y ago
"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 fashion in C? Or even in Lisp, if you really cared to? You could also write a very 'functional' program in C if you really wanted to. Why is everything black and white with geeks, is beyond my wildest dreams - but it just points to a lack of mature thinking.
- MrKurtHaeusler 15y ago
  Common Lisp at least has full support for object-orientation. You don't have to roll it yourself like with C.
  - stmartin 15y ago
    Which is why I find CL more appealing to my palate...

deleted 15y ago

[deleted]

KirinDave 15y ago

I think you're misunderstanding the aim of my essay. It's not to say that FP is uniformly superior to OOP. It's that there is value (and difficulty) in learning the functional abstractions. The same is true of most programming paradigms, but we live in a world where FP is one of the less understood and increasingly relevant tools. Do you really think this is so controversial?

stmartin 15y ago
Controversial is hiding a bastard child in plain sight for 10+ years while running a state. You're not :). Joke aside - I don't want to write essays here, so I'm gonna try to make a hopefully brief point. I -know- your essay was well-intentioned, and believe me, so is my reaction, after having written software for a living for nearly 15 years... Rather than to expound - let me ask you - do you know of Martin Fowler? I can get Graham and his cult-like persona has ensnared you/others somewhat in his FP-Kool-Aid cult :D... but read Fowler for a bit of balance too. Your intention was actually awesome - you want to illustrate a general principle, e.g. an abstraction, that thinking via and writing through a functional paradigm/language makes you a better programmer. Is that "true" to the extent you and a bunch of other FP-evangelists claim? Why, yes it is! So is learning assembly language, or Brainf*ck for that matter.... Why I mentioned and really enjoy reading Fowler's non-imposing, well-argumented style of writing is because he effectively does, what you bravely attempt to do here, convey a general principle about _programming languages_, except he does it expertly, whereas you do it naively, despite the good intention. To get what I'm saying, surf over to www.amzn.com, and get yourself a copy of Fowler's Domain Specific Languages. Upon reading that book, heck, even half way, you soon come to the same realization that what one of the other repliers to my original rant has come into some time ago - we are ultimately discussing various paradigms/philosophies of thinking. Not ONE single or multiple paradigms that are tailored to your particular way of thinking or that you are "hard wired" for (which I find hard to believe, but I'll grant some 'nature vs nurture' arguments here too), makes you or anyone else, me included, necessarily a 'better' programmer... I'd go as far as saying that it's probably your personality, mental/emotional states you experience on a daily basis while glued to your PC, that have you be more or less effective at programming, e.g. you're a 'perfectionist/procrastinator', most common among programmers, or you're extreme and reckless and use inadequate tools to just conjure something up, looking to get 'promoted' and it blows up a few months later or BSOD's in a demo to the board of directors.... This has been said over and over, and for some reason, it doesn't sink in - there is no silver bullet, there is no 'better/worse' programmer - unless you count lines of code produced per day as a 'productivity measure', hardly a clever measure of anything... Back to your essay - I'd much rater you embark on the topic of DSLs, rather than using CL as a platform to write a DSL in - which is -fine- except maybe people who are unfamiliar with Lisp's syntax, e.g. domain experts, can relate to a specific, external DSL better than they can relate to a LISP based DSL... Think of teaching a DSL to a ... I dunno, a postal worker who examines mail rejects that didn't pass the OCR phase. You could construct a DSL specific to that purpose. It would be relevant and useful and increase the worker's productivity. On the flipside, teaching him Lisp, such that he can learn a DSL designed inside of Lisp, would be a pain in the ass... DSLs, e.g. macros, are one of the highly touted benefits of Common Lisp, which I actually like, because of its multiparadigm ('dirty') nature... Anyway, I don't really want to indulge here - I think if you are serious about writing something, which I believe you are - be as balances as you can be, and never throw ANYONE under the bridge - including people who have only coded VB in their life.... You are either on board w/all people, or you're alone. Smugness about a particular paradigm is something I'd stay away from, as well as people who hypnotize you with their eloquence and "successes" (financial or otherwise) into thinking that they've discovered the next best thing since sliced bread..... This is why, as much as I like my Macbook, I still think Apple's a cult, and that Linux will eventually prevail, even on mobile platforms, tablets, etc. Peace.

danenania 15y ago

"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." What is the point of this vitriol? Makes you seem fairly anti-social yourself.

BDFL_Xenu 15y ago

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.

dasil003 15y ago

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.

deleted 15y ago
[deleted]
ebiester 15y ago
Here's the problem I have with this: nearly everything I do involves state. It's called a database. Let's take a simple example, a to-do list. Abstracted out to its essentials (a piece of paper), the to-do list is exclusively state. Add a task, complete a task. Now, I can write a program that manages a to-do list in a functional language. There are two options. (Let's assume this is a web app.) First, I can make the client manage the state. Each time they use the application, they bookmark the last page. This is obviously inconvenient, but it's pure. Every input has a distinct output. Send the entire to-do list and what you wish to add or complete as input, receive an update copy of the state in return. It's always immutable state. It's also inconvenient if you ever want to use this on another computer. So, like most to-do lists, we use a database on the server side to manage the state of the application. However, you've lost the entire benefit of immutable state! You are not guaranteed to get the same output given an input. We're back to square one, aren't we? What's functional about mutable state? Now, in a subset of programs, eliminating mutable state is beneficial. 99% of scientific programming would be best served by FP. However, I've never seen an answer to how we can still call any system functional once we add a database. And at that point, why aren't we using a language that is bad at what we expressly need in the first place?