Interactively Programming Flappy Bird in ClojureScript
rigsomelight.com
rigsomelight.com
On the REPL side, I wrote a little python lib [0] to do this for raw js for me in Chrome. It watches for local changes in the filesystem and pushes them directly into the browser (which means it's editor agnostic, though, linux only). It's pretty primitive but can be useful when you're working in that environment.
You can get it for free, with Python for instance:
https://github.com/lepture/python-livereload
It is so fast that it usually takes me more time to switch focus from editor to browser with alt-tab than LiveReload uses to refresh browser state. Also, it reloads assets like CSS and images. I used it even with LightTable's internal browser, with ongoing REPL connection, albeit briefly, but it worked.
Choice of technology involved beside, the post makes great points. I truly enjoy programming more when there is less contextual switches and waiting between coding and the runtime. REPL into the browser is also a must. ClojureScript has a REPL, but for some reason there hasn't come a JavaScript equivalent. A dev console is not nearly as powerful than complete cli app, though they seem to be getting better and better. I'd like to have a NodeJS console with connection to browser tab with the app.
And I'd like to have a way to modify the code visually direct from browser, but we are not there yet...
When I see these types of demos of live coding, I always wonder what it looks like when nothing is working, and when you aren't exactly sure how things are going to come together. Is it worth it, or just an interesting distraction?
In the ClojureScript community we passed a threshold where we can now program interactively, I am simply pointing out that occurance.
http://research.microsoft.com/pubs/211297/managedtime.pdf
The trick is not to avoid state, but rather have a sane relationship with it.
Those benefits were all available in the Xerox PARC systems:
- Smalltalk
- Interlisp
- Mesa/Cedar
But thanks to many mistakes, the world got UNIX instead and now newer generations are rediscovering what interactive coding really means.
- Xerox PARC systems were too expensive for most companies. Alan Kay says if you want the future today, you must be willing to build the hardware from 15 years in the future
- The commercial attempts to bring Smalltalk and Lisp into the market failed, mainly due to mismanagement and the high prices
- The first set of UNIX clones start spreading into the industry, were much less expensive and good enough
- Attempts to replicate Smalltalk and Lisp interactive experience in common early 80's hardware failed short to provide the same experience as in the Dorado and Star systems.
- Younger developer generations educated in UNIX and microcomputer OS never experienced such systems
- Probably something else
https://news.ycombinator.com/item?id=7565751
These systems were working in the late 70's, early 80's as personal workstations. Now compare with what many developers still use today.
Just a minor tip: I feel like you spend way too much time typing in the demo. You should just copy and paste the changes you want to make ahead of time.
http://research.microsoft.com/en-us/people/smcdirm/liveprogr...
The risk of typing the code in and not copying and pasting for those who are up to speed is that they have to take a few moments to watch the coding or skip past it; the risk of not live coding for those who aren't up to speed is not understanding what's going on. The time taken to live code is really helpful for people like me.
It didn't take me long to realize that just because I could do something like (for example) `view.attributes.blah = "something"` it wasn't how you're supposed to do it (`view.set("blah", "something")`).
As a beginner, you're really just trying to make shit work. And it's fine to do stupid things, you'll learn the errors of your ways later on. The most important thing is that you have the means to learn rapidly.
You say trial and error approach, but I'd call it experimental approach. And this is good. The bad habit is never growing beyond that.
i really can't put it better. it's like when i first found Firebug or Mapquest.
This is different from the the experience of just saving a file and having the behavior change. But you can probably integrate this workflow into Light Table quite easily. Well actually you can use figwheel inside Light Table and have both repl based and file based interactivity. Pretty cool.
I also think that the Light Table interactivity for javascript is not REPL based but I would call file based. But the dominant javascript programming paradigm in javascript is imperative and thus very brittle when working with live coding.
But it looks like boot could be a good foundation for a project like figwheel. But for now I am going to stick with lein.
But your codebase is only ~20 lines.
I personally would stick with the wrappers as it makes for a more streamlined experience. I like Om though the others look a little simpler, so may be more suitable if you're looking to stay close to React.