Most reasonable definitions of imperative programming include the pervasive use of mutable variables, `while` and `for` loops, procedures that have effects beyond their return values, or plain don't return the same values for the same arguments…
You could de-sugar your way out of those (Turing completeness and all that), but then it wouldn't be imperative programming any more. You could isolate those things in a monad, but (i) the monadic part is not functional, and (ii) the rest of the program don't use those things. I stand by my incompatibility claim.
Your marketing argument is better, but I don't see any other way. No matter how you cut it, FP is big about not using some features, and what benefits we get from this restraint.
Haskell has been called one of the best languages for imperative programming [1]. Even in a pure language, we still NEED imperative code at some point where the program hits the real world of time and state (even in FRP a stepper is often needed!). By lifting state and sequencing into a monad, continuation, map or whatever, it is still there even if handled better.
Now, you don't need to use imperative programming everywhere, and in a functional language you have the option to easily not fall into it (well, in Haskell, most other popular FPs are way less pure).
> No matter how you cut it, FP is big about not using some features, and what benefits we get from this restraint.
And that is really why FP will be niche (especially pure FP). Like very powerful static type systems that are really good at saying no...it adds to the resistance of writing code while claiming benefits further down the line. "Worse is better" wins out over and over again (why dynamic languages, imperative programming, OOP continue to be popular; we aren't Vulcans after all!).
> Like very powerful static type systems that are really good at saying no...it adds to the resistance of writing code while claiming benefits further down the line.
My experience is the exact opposite: having a compiler that is good at saying no means I correct my errors earlier. With a dynamic typing, my errors are revealed later, and further from the root cause. So, static typing removes to the resistance of writing correct code. It speeds me up.
Static typing would indeed add to the resistance if it required you to jump through hoops. But it doesn't. Bad type systems have significant limitations, but the good ones have very few. Unless you go crazy with Smalltalk-like hot-plug live systems (and even then, see Yi and Xmonad), static typing is permissive enough.
> we aren't Vulcans after all!
I have two theories. The first is, some of us are Vulcans. And somehow, Vulcan brains function better with static typing and functional programming. In other words, Vulcans are better at "math", and put programming into the "math" bucket. Then there are humans, who see programming and mathematics as two quite separate disciplines, ran away from math, and function better with procedural programming and dynamic typing.
My second theory is that everyone could adapt to anything, if only they would bother to learn. Anyone can think like a Vulcan.
I currently lean towards the second theory, though frankly I'm not sure which theory is closest to reality.
> Static typing would indeed add to the resistance if it required you to jump through hoops.
No arguments there. Haskell makes some interesting tradeoffs in this regard, I'm not sure they are optimal but they are definitely valid.
> Unless you go crazy with Smalltalk-like hot-plug live systems (and even then, see Yi and Xmonad), static typing is permissive enough.
The PL community is just really bad at exploring incremental type checking technology. It is totally possible (and I'm doing it with the live programming language I'm working on).
I only claimed that: if static typing feels like it is resisting too much, programmers won't like it. How fluid is programming in Haskell? Ever try using it in a REPL?
> The first is, some of us are Vulcans.
Yep. Take SPJ, the guy is brilliant and I feel like we are from different planets when we talk.
> In other words, Vulcans are better at "math", and put programming into the "math" bucket.
Some programmers like to treat programming as math, but definitely not all of them or even a majority of them.
> My second theory is that everyone could adapt to anything, if only they would bother to learn. Anyone can think like a Vulcan.
Spock was never able to convert Kirk. And I doubt we ever wanted him to.
You could de-sugar your way out of those (Turing completeness and all that), but then it wouldn't be imperative programming any more. You could isolate those things in a monad, but (i) the monadic part is not functional, and (ii) the rest of the program don't use those things. I stand by my incompatibility claim.
Your marketing argument is better, but I don't see any other way. No matter how you cut it, FP is big about not using some features, and what benefits we get from this restraint.