Interactively Programming Flappy Bird in ClojureScript(rigsomelight.com)
rigsomelight.com
Interactively Programming Flappy Bird in ClojureScript
http://rigsomelight.com/2014/05/01/interactive-programming-flappy-bird-clojurescript.html
12 comments
To me this looks more like immediate programming than interactive programming á la Bret Victor. You program the same way as ever, but changes can be seen immediately since browser can load new code very fast. I use LiveReload for this:
http://livereload.com/
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...
http://livereload.com/
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...
This is great, but the author already has a ton of working code and a framework that he can plug and play into.
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?
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?
As the OP I firmly believe that this is more than just a distraction. I don't have a ton of code and a framework that I am leaning on. I am leaning only on a practice. And that practice is to write functional code and then reap its many benefits. One of those benefits is being able to see my running programs change in real time.
In the ClojureScript community we passed a threshold where we can now program interactively, I am simply pointing out that occurance.
In the ClojureScript community we passed a threshold where we can now program interactively, I am simply pointing out that occurance.
> One of those benefits is being able to see my running programs change in real time.
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.
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.
Could you elaborate. I'm curious why interactive programming isn't more popular.
Most likely because:
- 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
- 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
Thanks, that's an interesting topic
You might find these videos interesting, cross linked from another discussion.
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.
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.
As any small talker would tell you, functional programming isn't the only way to reap these benefits; also see the videos linked in:
http://research.microsoft.com/pubs/211297/managedtime.pdf
The trick is not to avoid state, but rather have a sane relationship with it.
http://research.microsoft.com/pubs/211297/managedtime.pdf
The trick is not to avoid state, but rather have a sane relationship with it.
Nice! I wonder if interactive programming might end up encouraging a trial and error approach to coding which can be a very bad habit.
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.
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.
Thanks for the tip. That was my first screen cast. I went through like 7 iterations eventually I just threw the towel in. Yeah the whole sine-wave function thing takes to long. Next time I will paste stuff like that in.
Actually I'd like to strongly urge you to not copy/paste code in. The trend lately has been to not paste code in but to do the typing... it's more akin to live coding and I think learners gain more. A lot of the better online tutorial sites make their teachers work the code out live. In addition to that, they often discourage the use of macros and shortcut keys so the viewer can see and learn what's going on. With modern video players those who don't want this can scrub past it.
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.
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.
I like live coding too but I think how much of it is acceptable depends on what you're trying to demonstrate. If you're doing a programming tutorial video then yes by all means type every line so the viewer can follow along. However, if you're trying to show how various code changes get reflected in your browser do you really need to dedicate 20% of your video time to writing a sine function?
I think so, especially in this case. In this case, you only really get a sense of just how interactive the programming is by watching how a really short amount of time coding produces game play changes. When people cut and paste I think the viewer wonders in the back of their mind if something else got tweaked (not intentionally to mislead or anything, but because of the nature of coding). This is probably one of the reasons why, for example, the PeepCode Play by Play videos got so popular.
I thought it was a good live-coding demo. The code you typed was interesting and non-excessive. (But I like math and clojurescript.)
This was no where near as painful as some talks I've seen, where the speaker is programming. Like running of time, and only being half way through the talk. Live coding definitely slows down the momentum. A good example of coding demos is Stephen Wolfram introducing the Wolfram language [1]. 12:55 minutes of pure ecstasy :D
[1] https://www.youtube.com/watch?v=_P9HqHVPeik
[1] https://www.youtube.com/watch?v=_P9HqHVPeik
Try camtasia; you can speed up sections of the screencast and even make animated gifs (which compress well for programming experiences). see for an example:
http://research.microsoft.com/en-us/people/smcdirm/liveprogr...
http://research.microsoft.com/en-us/people/smcdirm/liveprogr...
I actually like the typing part... if I had my druthers there'd be more typing. I can process what's going on in that time.
Excellent point about the trial and error approach. I started programming relying heavily on setting a breakpoint and writing code inside of Chrome's devtools (then copying the code, which I knew worked, into my project).
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.
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 can easily say that when I return to projects that don’t have an interactive workflow I feel like I am in the stone ages.
i really can't put it better. it's like when i first found Firebug or Mapquest.
i really can't put it better. it's like when i first found Firebug or Mapquest.
We should make people program without Firebug every now and then and so they can experience the pain we went through.
When I debug in firefox, I use the native debugger. Firebug takes a long time to start up. Am I missing out, or are the two similar at this point?
They're basically the same, except the native debugger--like you said--is faster. I love Firefox, but I've switched to Chrome for the dev tools and overall speed.
Firebug pre-dated (and heavily inspired) the native debugger, so the GP is probably intending to suggest doing without either of them.
alert(my-var); :(
Why not just use light table?
Good question! And I have to first say that I haven't used light table a lot. But from my experience Light Table has what I will call REPL based interactivity. You choose which sections of code to have compiled and then evaluated in the browser environment.
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.
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.
Is it just me or is the game stuttering every half second ? Is this because of the screen capture, JS GC, scrolling implementation or am I just imagining things ?
If you are on mobile the game is certainly stuttering. I built this primarily to demo interactive coding not with an eye to making it perform well on mobile. Are you on a mobile platform?
I think the commenter may have referred to the video, in which there's a lot of stutter. I found this distracting as well, since it made it difficult to see just how interactive (or immediate, for the semantically inclined) the programming really was. That said, I think this is great work, and the screencast is otherwise doing a great job getting your points across. I disagree with other comments saying there's too much coding, and copy/pasta would've been better; I feel the balance was just right. Thanks for sharing this with the world!
How does figwheel compare to boot? http://github.com/tailrecursion/boot
I just read the README and it looks like boot is Clojure centric, not ClojureScript. And it is a build tool where figwheel hooks into a ClojureScript build tool and send code changes to the browser.
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 it looks like boot could be a good foundation for a project like figwheel. But for now I am going to stick with lein.
I'm waiting for LightTable to properly support Erlang to enable this kind of workflow.
> If you tell me that I can experience live behavior changes in the browser as I type and all I have to do is defonce the reference to my program state I’d call that a clear win.
But your codebase is only ~20 lines.
But your codebase is only ~20 lines.
Good point. But I'll say that with React and ClojureScript you can make a very large code base where all the components manage their lifecycles in a way that is completely reloadable with little effort going into thinking about reloadability itself :)
Are you using react/cljs without using any of the Clojurescript wrappers? For learning purposes do you think is better to start that way?
I'm using Om quite heavily and it was my first look at react, clojurescript and single page web apps (prior Clojure experience though). Its been a reasonably pleasant experience and I can see myself continuing to use them quite a lot. Learned a lot about React in the he process too.
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.
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.
I am using Sablono https://github.com/r0man/sablono a lot. It is a very thin wrapper around the basic react components. IMHO I would advise getting to know React before jumping into frameworks. It's a pretty simple model and incredibly powerful on its own. That being said I think Om is a wonderful framework. But its good to understand React outside of Om.
Great stuff! Would that work in both Android and iOS?
They both have browsers with Websockets, so theoretically you could live code in the mobile browser. Although I haven't done it yet.
Would this work with standard JavaScript as well?
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.
[0] https://github.com/aidos/chromesync