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.
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.
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.
I don't think the state of computer science is really held back much by the current state of programming ability. SW Engineering is maybe held back by it, but many of the best computer scientists I know don't program at all and would think discussing Lisp vs Java would be like asking a mathematician if he preferred to use an ink or gel pen.
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?
Programs have to have state and side effects to interact with the outside world. That's not what's frowned upon.
The goal with functional programming is to try and minimize the number of functions that involve those external transactions. The spine of your program in Haskell will revolve around IO, but all the limbs can probably avoid requiring anything more than inputs and outputs.
Perhaps a concrete example would help? Imagine parsing incoming HTTP requests on your TODO app. Ignoring streaming (which I think we can do safely in this case), your IO code is to read and write to the socket, but the intermediate code to parse the incoming request into data structures for inspection? That can and should NOT be dependent on I/O. Similarly, the code that actually generates your HTML output (before writing it to the socket) need not care about I/O.
Functional programming isn't just "no effects." There are many parts to functional programming: there's the idea of functions as the primary means of expressing data/information (as opposed to e.g. objects in OOP), the idea of functional purity (which is obligatory in Haskell but merely preferred in ML or Scheme), the various degrees of static type-safety, expressivity and power (e.g. Haskell with extensions is powerful but not always safe, Coq is safe and expressive but necessarily limited in power, Scheme is dynamically typed), as well as a handful of other concepts which appear from time to time. Even OOP isn't necessarily a conflicting paradigm, see OCaml or Common Lisp's CLOS system for the intersection of objects and functional programming. For more radical ideas, look at e.g. Functional Reactive Programming for functional data-flow programming.
w/r/t the specific side-effects in pure-functional programming: in Haskell, functions which perform effects are specially marked in the type system, so a function which performs side effects can call another one which performs side effects, but non-effectful functions can't unexpectedly induce effects. You end up writing programs with an effectful core for e.g. the manipulation of the db, and non-effectful functions for whatever processing you need to do with the data, with compile-time guarantees that the processing functions can be tested in isolation and won't cause exceptions or do unexpected IO.
Of course, you can write imperative code in a functional setting, and you can write functional code in an imperative setting. There's an old saying that bad programmers can write FORTRAN in any language; you can also write Lisp in any language, or Haskell in any language, with varying degrees of effectiveness or utility. Functional programming partisans—myself included—assert that functional techniques, correctly applied, can reduce errors (c.f. the Compcert C compiler) and simplify writing good code (c.f. the functional implementations of the Actor model of concurrency, parser combinators). I don't personally believe it to be a panacea, but it puts another tool in the toolbox for whenever your existing hammers aren't solving your problem.
It seems you didn't read my post at all, because this is a complete non-sequitur. Look at the only sentence in which I emphasized a word and notice that it is exactly the same as the opening sentence your rebuttal.
This tells me that you are operating off of some mental model of what you've heard from FP proponents in the past without actually giving what I said proper consideration. The irony is that in your other comments you decry the religion of such debates with FP proponents, but in this case you are the one bringing a religious view. Nowhere did I say that FP languages are generally superior for real-world problem solving.
I'm not the one you replied to originally. You're right, it was a non-sequitur, but mostly because it was a question I'd had since I took a functional programming class in college, and never saw an answer that sat well for me. One of the other commenters gave one, so rather than contribute to the noise I just stayed silent and upvoted.
I was just taking advantage of a heated discussion to get an answer. :)
Of course, most of useful software involves input and output and state. Functional programming doesn't preclude that. There are compilers, package managers, documentation systems, etc, written in Haskell. They all use files and databases. Of course, your programs have to be designed differently.
For reference, here's is a talk by Don Stewart et. al about the design of XMonad:
"The mathematical rigor of a pure functional language like Haskell allows deeper reasoning to be done, and thus more powerful abstractions to be introduced."
Allows or requires? I guess I never really understood the difference between reasoning about code and actually getting shit done.
The thing with Haskell is it is almost like two languages in one. There is the Haskell you learn, with no side effects, and everything is lazy, and you are basically just binding stuff up and it gets evaluated at the end.
Then you have the Haskell that programs actually get written in, with do blocks and actions, if I remember correctly, and it looks a lot more iterative than functional. With actual side effects happening all the time.
The syntax, which is probably the hardest part of Haskell, is totally different.
Very confusing for someone learning text-book Haskell, then jumping into actually maintaining and writing programs, you almost think you have learnt the wrong language.
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.
"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.
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.
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.
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.
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.
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.