Actually, I really am sure Clojure will fit in all of those problem domains. Indeed, I'm pretty sure that if you experienced a well-written Clojure accounting app, you'd wonder why people bothered with Java.
The parentheses are only one hurdle that Clojure makes you jump over, though. The other is Functional Programming.
I read an article here or on Proggit a few weeks ago by a (semi-professional?) game programmer who reviewed his own attempts at writing a real-time arcade-type game (PacMan?) in a functional language. Yes, he got the thing working and it even performed decently but he was irritated that if he really stuck with the paradigm of not having alterable state, some small changes to his app's functionality would entail changes in all kinds of places in the source.
Happily, Clojure gives you explicitly alterable state and a bucketload of mechanisms for working with those. But still, after months of practice I still struggle to get my head wrapped around FP. Typical business software programmers (as I picture them) might have similar troubles.
Would like to see the code if you have the example. Would be a very interesting case-study as to why Functional fits such problem domain as opposed to OOP because this would open a new perspective.
Please share more. I'm interested. (Let me know if you can only share your experience via private channels).
Sadly, I can't share any code, but here's my basic observations:
First, calling a standard Java object from Clojure is extremely painless. It's a bit more complex if you're dealing with listeners, but in general terms a java object is a java object without very much getting in the way. This means that all of your favourite GUI libraries are usable without modification.
Second, as Carl pointed out, Clojure does have state, it's just tightly controlled. So tightly controlled that multi-threaded programming is much easier. There's some things that I'd like on top of what it does, but it's very powerful and useful.
Thirdly, I'm not denying that thinking functionally takes a while, but as you develop the skill, it's amazing how many things actually look pretty stateless. I've met actuaries who use F# for all of their calculations. Equally, converting game state to a 3d scene graph is a pretty stateless process (although I've yet to meet anyone who's actually getting paid to do functional game programming).
Hope that is interesting. Will be glad to share more.
I read an article here or on Proggit a few weeks ago by a (semi-professional?) game programmer who reviewed his own attempts at writing a real-time arcade-type game (PacMan?) in a functional language. Yes, he got the thing working and it even performed decently but he was irritated that if he really stuck with the paradigm of not having alterable state, some small changes to his app's functionality would entail changes in all kinds of places in the source.
Happily, Clojure gives you explicitly alterable state and a bucketload of mechanisms for working with those. But still, after months of practice I still struggle to get my head wrapped around FP. Typical business software programmers (as I picture them) might have similar troubles.