Think about it: currently, functional programming is, finally, getting some well deserved recognition in the wider programming world.

Yet almost everything it presents has been present in programming for as much as 45 years. The original paper on Hindley's type system was published in 1969. Milner's theory went to print in 1978. Scheme first appeared in 1975 and was already building off functional ideas that had been spawned by earlier Lisps. Guy Steele designed an actual Scheme CPU in hardware in 1979.

And yet even today, a non-trivial number of programmers react with absolute horror at the idea of a Lisp (usually based solely on ignorant trivialities like the parens-syntax), more or less exactly as your C programming classmates did in 1995, and while FP is starting to gain major inroads in some spheres, others dismiss the whole field as wank and Java and C remain kings that are unlikely to be unseated for another decade at a minimum, if ever.

We remain utterly bound to one model of hardware, one model of programming, and largely, only a couple models of operating system, after decades of development, because so many programmers react with horror at anything they're unfamiliar with or that deviates from the percieved norm, be it in features, syntax, or focus.

And God forbid you make anything that might actually be easy for non-programmers to learn. It will be more or less met with instant and persistent scorn, and its users derided and outcast, simply because they didn't use a 'Real Programming Language' like C. Go ask a BASIC coder what life has been like for the last 40 years, or a game dev who worked in AGS or GameMaker prior to the last half decade or so. Hell, I have a friend who still sneers at visual layout designers.

The divide described in the article is very much culturally enforced as much as economically.

People assume that functional wasn't used because of programmer prejudice.

Why don't people assume that functional wasn't used because there were good reasons not to use it?

Imperative programming lives in a world where CPU cycles and memory are scarce. Gee, once CPU and memory became abundant and free, people started using functional programming. Go figure.

Statements of this kind trouble me every time I see them, last time yesterday in the discussion about Greece.

I guess Marx's ideas aren't very popular over here. But implying that economy and culture need to be mentioned separately seems at least a little naive.

More fundamentally, you're ignoring the huge difference in power between consumers (in this case the programmers) and the people that create the tools and take them to market.

Both tend to enforce that divide, but for very different reasons; the coders for cliquish reasons as I described, and the business guys like Apple for the reasons in the original link.

it is bizarre

Prejudice doesn't seem to have anything to do with it. Functional programmers think differently, and what's obvious to the Functionals isn't to the Statefuls. And the Statefuls are currently most of the world. I've flip-flopped myself, because while I love the elegance of being a Fucntional, being a Stateful is just so much more productive. There are a few reasons for this: If I want to make a game, there's no good functional framework. If I want to write a script to get something done, like download a webpage, my goto language is Python because I know for a fact that their libraries work and that their documentation is almost always stellar. Contrast that with Lisp where you can spend at least a day just getting the environment set up in a way that asdf doesn't hate. Especially on Windows. (Yes, if you want to make games, Windows needs to support your dev environment.) My info about asdf is a couple years out of date, because to be honest I haven't felt inclined to look into it again after some bad experiences.

Haskell could be wonderful. Never tried it. Will someday. Until then, I'd love some sort of competition where a Haskell programmer and myself are given a task, like "write a script to X," where X is some real-world relevant task and not an academic puzzle, and see who finishes it first. It would be illuminating, since I'd give myself about a 30% chance of finishing first, but it would reveal what I'm lacking.

Arc had potential. It really did. Everyone just gave up on it, and it never attracted the kind of heroic programmers that Clojure did.

So the wildcard seems to be Clojure. It's a decent mix of performant, practical, and documented.

I'm out of time to pursue this comment further, but the main point is just that FP's problems have very little to do with societal acceptance or scorn. If you're running into that, you're probably running with a bad crowd anyway. It's mostly because imperative languages are popular, so network effects mean they'll just get better and better. If FP wants to chip away at that, it'll need to start off better and stay better. "Better" is many things, but it includes performance, cross-platformability (yes, Windows is necessary), documentation, and practicality (the ability to quickly accomplish random tasks without a huge prior time investment, Python seems to be the best at this so far).

I think one of Haskell's biggest marketing problems is that its strong points (strong static types + separation of side effects) aren't all that important in scripts (or any program that's small enough to fit in someone's head in its entirety), which makes it difficult to convince people of its merits in reasonably-sized examples.

What Haskell gives you are good, solid abstraction boundaries that you cannot accidentally break, and the ability to refactor code with a high degree of confidence that it's still going to work fine afterwards.

Neither of those are particularly helpful for any program that you might write in a competion, but both are incredibly important in day-to-day software development.

As for "getting work done" in Lisps/FP, I earnestly recommend checking out Racket. The developers have said that they've aimed to create 'the Python of Lisps' and by and large they've succeeded at exactly that. The documentation is thorough, the functional tools live alongside OOP and imperative ones quite nicely, the standard library is enormous, and DrRacket makes for a very good 'just open up the damn editor and start writing' tool.

Really, most of the FP languages are much more multi-paradigm friendly than Haskell, to the extent that I wouldn't even consider CL a functional-first language at all. CL's problems there are more a lifetime of neglect + Emacs loyalty, though Allegro and LispWorks offer more 'everyone else' friendly options. F# is fantastic as well, and integrates nicely with the rest of .NET and allows for a mixed paradigm while still getting all the functional tools and the power of type inference on top.

I recently re-installed my OS and setting up my Lisp environment (SBCL, Quicklisp, SLIME+Emacs) took about 30 minutes.

I don't see what the problem is on Windows.

My info is out of date though. Maybe it's better now.

> my goto language is Python because I know for a fact that their libraries work and that their documentation is almost always stellar.

> It's mostly because imperative languages are popular, so network effects mean they'll just get better and better.

This claim makes it seem like imperative/stateful is more productive because of functional itself:

> I've flip-flopped myself, because while I love the elegance of being a Fucntional, being a Stateful is just so much more productive

All of your other comments seem to be "imperative/stateful is more productive because of popularity, docs, and libaries".

Are you claiming both of those are true? Weakly claiming the first, strongly the second? Could you elaborate?

EDIT: Maybe a little longer.

So it's just a combination of mindset change plus a different "context" for programmers to get used to. That, along with deployment problems and sometimes lack of documentation, leads to a lack of incentive for anyone to make the switch. Since stateful is more popular, it's almost always better for productivity to start and stay a stateful programmer. However, for personal skill level, everyone needs to become a functional programmer for at least several months and try to develop production apps with it. Who knows, you'll probably get much further than I did, and figure out a way to convince all your friends to make the switch too.

Very recently computers got to the point where we can afford to write slow code, this is the reason higher level people are coming out of the woodwork.

So I asked the developer, does he use the famous ROS software for running the robot. He said, no way, because the robot had only an onboard Intel Atom of relatively low performance, all the complex multi-threaded behavior had to be written in low-level C. No space nor execution time for anything more.

Of course there is a need for freestanding C. But for every one of him there are a hundred developers using c++ or java or javascript. They may not appreciate the power of working in such high level languages, but the vast majority of developers work in HLLs.

There. Top that.

http://www.gdcvault.com/play/1018048/Classic-Game-Postmortem

Their Hypercard experience is at the 38 minute mark.

But this is the problem with our profession, it's baked in at a deep level that old == bad. So every new generation reinvents the wheel, worse than the last. The truth is all the big problems in software were solved in the 1970s, if only we would pay attention. The only actual progress in computing is that the hardware guys make everything faster.

Do you have a reference to that paper on C and LISP?

https://www.dreamsongs.com/WorseIsBetter.html