ClojureScript is a fantastic piece of engineering. I'm the author of ClojureJS, one of the few Clojure libraries that implemented Clojure to JavaScript translation (with predictable scoping semantics). After having looked over the ClojureScript sources, I'm convinced this is a far more sophisticated compiler with a sound namespace strategy.
The namespace and compile time checks alone are worth the price of admission. Plus macros, which was the biggest motivator for building ClojureJS.
Suffice to say, if ClojureScript (in its current form) had existed 7 months ago, I'd never have considered building anything on my own. That's not to say I'm not proud of ClojureJS. It was born out of a real need that I had, and has been enhanced by some very valuable contributions by people who also shared my excitement for writing browser clients in Clojure.
I still need to understand the Google Closure integration impact, but from what Rich said at the ClojureNYC talk, it sounds worthy of study and adoption.
We're not launched yet (but, close). I'll definitely post about it when we're live. I'm not sure how much of the Clojure (subset) code we'll publish, but I'll write more about our process and experience once we're launched.
I beg to differ. I've used ClojureJS (a Clojure to JavaScript translator) for building a non-trivial web app front end, and the result has not only been robust but also a pleasure to build (from a Lisp programmer's point of view).
[Disclosure: I'm the author of the ClojureJS library]
RTM and his controversial (for that time) Internet worm were key influences during my early years with computers and computer networks. My condolences to him and the rest of the Morris family.
My wife and I made this same decision about 5 years ago when we were expecting our first child, for pretty much the same reasons you cited. We were extremely fortunate to have found a niche for which we could build a product, and find paying clients relatively quickly.
It took us about 18 months to reach a level of stability - literally, our business grew alongside our first child. But, even during this phase we were able to spend quality time with our child. Although, as one of the other posters indicated a lifestyle business doesn't automatically mean tons of free time and no stress. It's just that relative to a traditional startup life (which I experienced as a principal when I was still single), it's still night and day.
My wife and I are extremely grateful for the time and freedom our business afforded us. We were able to spend more time with our children during those precious first few months and years than we would have even working for a big company, let alone a startup. There were still stressful times, especially finding clients, or when servers went down in the middle of the night (funny how that always happened just as soon as you go back to sleep after walking a crying child to sleep :), but it was all worth it.
I believe clojurescript requires a patched Clojure implementation, and a JVM to support the generated Javascript at runtime, although I'm not 100% certain that these constraints are still true. And, I'm not sure how actively it's being developed. However, clojurescript is probably a better approach to this, with an appropriate intermediate representation (a nice byproduct of using the built-in compiler) etc.
clojurejs generates javascript which has no other dependencies (other than any in the source Clojure (subset) code itself) and should run on any reasonable browser.
FWIW, clojurejs is a much less ambitious effort born out of the necessity of one developer (me). You can read more about the current limitations and some of the things I'd like to improve on the project's github issues page and the Google groups discussion referenced elsewhere in these comments.
You're quite right about the juxtaposition of "demonstrable" and "future". I should have said functional programming has "already" demonstrated an advantage in producing robust and understandable concurrent programs, which will continue to be relevant in our multicore future. Really, there's nothing "theoretical" about that fact.
To your second point, I made no claims that C and C++ are not used to solve performance intensive problems. I'm sure C and C++ (or Assembly, for that matter) can be applied to solve any number of problems, if that's one's calling.
For a certain (large) class of programs, being "functional" is an advantage. Interestingly, you made the point that being functional means easier maintenance etc., but fail to attribute those advantages to being functional. If your argument is that there can be bad functional code which performs worse than non-functional (imperative or OO) code, I don't disagree. However, in the multicore future that our semiconductor overlords have in store for us, functional programming has a demonstrable advantage in helping build understandable and robust programs.
I'll accept your own experience, and am happy for you. As for how Mr. Norvig's coping -- let's wait for him to post his own.
I could see a language designer (say someone like Guy Steele) who has made major contributions in Lisp happily moving on to his or her next research interest, pursuing a completely new design. Those of us stuck in the "real world" of trying to make a living with our software skills are a different matter.
In my experience, once having worked with Lisp I found it extremely difficult to switch to programming in Java. I spent a lot of time trying to make Java look like Lisp, which in my opinion made my code more readable, but to other programmers I worked with - not so much.
My point is, Lisp can be a mind altering experience, much like LSD (I suppose). Some have the ability to compartmentalize the experience and move on with other pursuits and some are forever hooked on the "forbitten" fruit.
"LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot." -- Eric Raymond (How to become a Hacker).
I wonder what percentage of people who "get Lisp" manage to stay happy working in other languages.
http://kriyative.github.io/tags/
I vaguely remember someone adapting it with an ECL to android cross compilation effort. Can't find that link now.
The LGPL license of ECL is something to keep in mind as you consider your options.
Good luck.