
Interactively Programming Flappy Bird in ClojureScript - brucehauman
http://rigsomelight.com/2014/05/01/interactive-programming-flappy-bird-clojurescript.html
======
aidos
This is wonderful. I really need to get past the reading through a tutorial
stage with clojurescript and actually build something.

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](https://github.com/aidos/chromesync)

------
jarpineh
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/](http://livereload.com/)

You can get it for free, with Python for instance:

[https://github.com/lepture/python-
livereload](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...

------
politician
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?

~~~
brucehauman
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.

~~~
pjmlp
> 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.

~~~
enen
Could you elaborate. I'm curious why interactive programming isn't more
popular.

~~~
pjmlp
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

~~~
enen
Thanks, that's an interesting topic

~~~
pjmlp
You might find these videos interesting, cross linked from another discussion.

[https://news.ycombinator.com/item?id=7565751](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.

------
lispylol
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.

~~~
brucehauman
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.

~~~
joeevans1000
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.

~~~
lispylol
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?

~~~
joeevans1000
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.

------
catshirt
_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.

~~~
brucehauman
We should make people program without Firebug every now and then and so they
can experience the pain we went through.

~~~
tieTYT
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?

~~~
fellytone84
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.

------
eagebhart
Why not just use light table?

~~~
brucehauman
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.

------
moonchrome
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 ?

~~~
brucehauman
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?

~~~
mstade
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!

------
jboynyc
How does figwheel compare to boot?
[http://github.com/tailrecursion/boot](http://github.com/tailrecursion/boot)

~~~
brucehauman
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.

------
fenollp
I'm waiting for LightTable to properly support Erlang to enable this kind of
workflow.

------
elwell
> 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.

~~~
brucehauman
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 :)

~~~
derengel
Are you using react/cljs without using any of the Clojurescript wrappers? For
learning purposes do you think is better to start that way?

~~~
dkersten
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.

------
piokuc
Great stuff! Would that work in both Android and iOS?

~~~
brucehauman
They both have browsers with Websockets, so theoretically you could live code
in the mobile browser. Although I haven't done it yet.

------
dav-
Would this work with standard JavaScript as well?

