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

[gravity13]

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.

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

[munro]

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

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

[seanmcdirmid]

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

[undershirt]

I thought it was a good live-coding demo. The code you typed was interesting and non-excessive. (But I like math and clojurescript.)

[joeevans1000]

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.