> 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.

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.

My apologies, that portion of my point was meant to be independent of the FP comparison. It is absolutely true that, save for the occasional grudging exception, the 'easy languages' have largely been scorned and shunned throughout programming history. Hell, I've been guilty of it myself where HyperTalk is concerned despite loving the concept.

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.

> 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.

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

Yeah, download SBCL, load quicklisp.lisp, done.

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

Several years ago SBCL was unusable for game programming on windows due to crashes. I tried and eventually gave up.

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

I've not had any issues with SBCL on Windows except with the thread support.

> 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.

> 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?

No no, I'd never claim something as foolish as FP is inherently less productive. It's the opposite in my experience. Once you have a bunch of libraries and utility functions that you know how to use, you'll wipe the floor with any stateful programmer. The hard part is getting to that point. I'll elaborate more in an edit when I'm home in like 30 minutes.

EDIT: Maybe a little longer.

I'm short on time, but my main point was just that if you're already a stateful programmer, it's difficult to become productive when switching to functional programming due to a combination of factors. FP isn't inherently more difficult than stateful programming. It's simply that stateful programmers have already spent the time to become productive, whereas switching to FP requires another time investment in terms of learning a new mindset, getting a programming environment set up, learning how to exploit the environment (how to be "fiercely effective"), learning which libraries to use and how to find them and set them up, and most importantly: deployment. Deploying native apps in stateful languages has seemed easier for some reason, whether it's python or C or whatever else. I tried to use lisp for gamedev, but it became a nightmare to figure out how to actually deploy everything including libraries along with all dependencies. The end result of deployment needs to be a program that's launchable by double clicking on an icon, which seemed difficult. (Again, my info is out of date, so maybe things are much better now.)

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.