Applying this to more than just games, you could probably make a really good tool for mathematical modeling of physical situations. Speed would be an issue, but it would be a good way to test out ideas quickly.
I remember geeking out to that when it came out! Since reading that I have been playing around with d3 a good deal to try and be able to make some of the stuff he has. I've been slaving away at this for the past few days actually:
http://zacharymaril.com/analytics/
This afternoon, I will put up a better version (this one won't work for you due to some figuration stuff), but this takes in your google analytics data and maps it a bit better than the normal set up.
I would also like to point some of the commenters to (fluxus) http://www.pawfal.org/fluxus/. It is a very nice example of this concept of the same thing, only using racket/plt scheme.
Live coding/reactive code are fantastic little ideas which I wish had been exposed to me earlier in my career.
ClojureScript compiler being written in Clojure is a huge disadvantage. It should be written in JavaSript or ideally self-hosting. That way for this project you wouldn't need the server and when its hosted somewhere there is no need to the compile round-trip each time the code changes. Also as a plus you'd have eval!
self-hosting only gets you bragging rights and neat demos - it offers little advantage for real applications targeting JavaScript. That said, ClojureScript now implements most of Clojure - if someone wanted to bootstrap ClojureScript for fun it wouldn't be much work, go for it.
Advantage for a beautiful demo. If I'm going to actually build real applications in this way, I don't need to run my development environment on someone else's website.
This was beaten to death on the release of clojurescript. I think the consensus is it's not worthwhile, since there are real benefits to google's closure compiler, optimization, and dead code elimination. But there's nothing stopping you from implementing it?
If people want to code on the web that's great. If someone wants to provide a bootstrapped in-browser ClojureScript development experience, that's great too. I just don't buy your claim that ClojureScript's strategy is a disadvantage.
eval is fantastic - the power of connecting to server-side REPLs comes to mind. However given ClojureScript's clientside focus the lack of the compiler infrastructure on clients (to provide support for eval) is less problematic in my opinion. But you might disagree - and no one's stopping you from addressing the issue.
Advantage for a beautiful demo. If I'm going to actually build real
applications in this way, I don't need to run my development environment
on someone else's website.
The key benefit of having an in-browser implementation of something like Clojurescript isn't:
"I can run my dev environment on the web."
it's:
"There IS no dev environment."
Look at how absolutely trivial and frictionless it is to get started with LessCSS[1], and compare it to the morass of libraries, source file locations, command-line invocations, and extra compilation steps that Clojurescript requires[2].
You can introduce someone to LessCSS and have them working with it in five minutes. No cross-platform problems, no installation, no figuring out how to automatically compile code when it changes, or anything else like that.
Once you need the extra speed, sure, have a command line tool to precompile everything to vanilla JS. LessCSS has this exactly. Heck, sure, maybe even run it through the Closure compiler if you want crazy speed. But don't optimize the development process for huge apps at the expense of small ones, because even if you only care about those huge apps (which would be a mistake -- there are some really cool small apps out there) you need people writing smaller stuff first to learn how to use Clojurescript, create libraries for it, convince others to use it, and so on.
Before anyone screams at me that I'm caring too much about that filthy concept of "easy", let me say that I loved Rich's talk on Simple and Easy, but I feel like it may have actually done some harm to the Clojure community by giving them an excuse for making conceptually-simple but hard-to-get-started-with-and-use libraries and tools.
Simple is more important than easy, yes, but if you can make something easier without sacrificing simplicity then you should!
No one should say "I don't have to thoroughly document this because it's conceptually simple so you should just read the code", or "we're going to make something that has lots of uncomplected layers and who cares if it's performant enough for real world use", or "I don't feel like making this a single-step install, so if anyone complains I'll just say they care too much about ease of use".
In Clojurescript's case it actually seems like the combination of Clojurescript code calling Clojure macros and then being compiled by a compiler written in Clojure and then compiled again with the Closure compiler (aside: this naming is just hilarious) is really complex. There's a lot of mental effort required to say "Hmm, where do I put everything so all the different parts of my project can talk to each other?".
A lot of this can be solved in a few different ways:
- More mature tooling with sane defaults, so I don't need to know everything a library is doing to use it. The entire point of a tool/abstraction is to take care of this stuff for me. lein-cljsbuild is off to a good start, but as an example: don't make me specify where my .cljs files are when it can `find . -name '.cljs'` and figure it out for most people itself!
- Documentation. This is a problem with the Clojure community in general. Auto-generated API docs are worse than useless because they fool developers into thinking they've written actual documentation.
Another problem in my own experience is that the performance of all of these extra layers is just awful compared to something lighter weight.
If you saw Chris Granger's screencast about the Overtone controller webapp the other day, did you notice that he often had to refresh in the browser a bunch of times before his Clojurescript changes were compiled and took effect? It's a sub-100 line Clojurescript file and yet a several gigahertz machine[3] takes a noticeably long time to show us our changes? We have to mash the refresh button until we're pretty sure our changes have compiled?
I really, really want to love Clojurescript, because it's got some beautiful ideas, but it almost seems to have adopted Haskell's "avoid success at all costs" mantra. That's great if you're building an experiment in programming language theory, not so great if you want to save real live people's time and frustration.
TL;DR: Clojurescript makes it really complicated to get to a black triangle moment[4] and that's a bad thing. An in-browser version of Clojurescript would reduce the time and effort needed to get there.
[2]: Yes, I know about lein-cljsbuild. Compare the README at https://github.com/emezeske/lein-cljsbuild to the two lines required to use LessCSS. Yes, this is a matter of easiness, but easy is not a dirty word.
[3]: I assume he's using something fairly newish, and my own experience agrees with this.
Do you guys think Bret Victor built an actual editor for his "live editing" demo, or just build enough of a demo to illustrate his principle?
It seems to me that if what he had built was a real editor (i.e. could be used for more than just his Braid demo game), there would be immense value in releasing/selling it.
One of the students asked this during the Q&A period at the end of the talk, he said it was just some Javascript and HTML cooked up to do just the things that he showed. So it wasn't a real demo, only something he whipped up to demonstrate the ideas but wouldn't be available to use for actual coding.
After I saw this talk, I thought about what it would take for making such an editor for general-purpose programming (and not just drawing or simulations).
This is really cool. One problem I've noticed with real time evaluation is infinite loops. I've played with an realtime javascript editor/evaluator and I inadvertently locked the browser (and the editor) when writing code. Imagine writing a "while (true)" loop and it evaluates before you've finished the break condition.
He rolled the player back, so it wasn't projected into the future, it was just he adjusted the current position backwards. you fall straight down because your velocity is dependent on whether or not you have the key pressed. Jump and let go of the arrow.
I haven't quite yet recovered from a weekend of sleep deprivation, and was entirely disappointed to learn that the link was for an "editable game", not an "edible game"...
I notice in your Overtone + ClojureScript screencast you were using VIM on Mac, but this looked different. Are you using SublimeText here or Noir itself as the editor?
