I like this a lot. One thing I noticed is that on the video, the first change is on the background from green to red. As a deuteranomalous (color-blind) person, I really couldn't see the difference unless I watched really close while it happened (and didn't blink). A small thing, but that kind of thing can be slightly frustrating for us. At any rate, the other examples were helpful in giving a feel for the product.
On a philosophical level, I like how this should integrate well with the rest of the Unix utilities. It isn't as immediate and interactive as Bret Victor's examples, but I think this has the advantage that the code is actually there and it works. It's not the ideal system, but I suspect that it is an improvement over the status quo. I'll definitely be keeping an eye on this.
Thanks for the feedback. Do you know of any good pair of colors that would solve the problem for all types of color blindness or should I modify the example to play with brightness ?
Changing brightness is good. Also, tritanomaly (or tritanopia) is very rare (about 0.01% for either males or females vs 6% males and 0.4% females for dueteronomaly), so changing between blue and either green or red should be fine for almost everyone.
I don’t want to sound overly negative, but latexmk already supports this workflow with its -pvc option (i.e. watching files for modifications and updating the preview). The ramdisk is nice, but with an SSD it’s roughly as fast.
Since I decided to use LuaLaTeX for my documents, I can’t use whizzytex (but I’d love to!) and compilation time is insanely high with LuaLaTeX.
My main point of criticism is that this is _not_ what Bret Victor describes. Sure, quick feedback is nice, but that’s not the point of his videos. In the videos, you can actually modify the program using the interface. For our example, you should be able to edit in the xpdf viewer, but you can’t.
I don't think his main point is modifying the program using the interface. The important thing is the quick feedback loop. In his examples in Learnable Programing, you technically are editing in the same interface, but, really, you're just editing the code on the left and seeing the result on the right.
Additionally, I think that's actually the right way to do it. The result should be optimized for viewing, not for editing, and the editing environment should be optimized for editing, not for viewing. If the two can be merged into a tight feedback loop, then maybe we can get something of the best of both worlds.
Okay, let’s assume that you are right, and we don’t need the same interface.
I still maintain that the feedback loop demonstrated in Bret Victor’s videos is _significantly_ quicker than anything you can achieve with any TeX engine in its current form.
Think of the part where he draws the fish. Or where he drags a slider. You need update rates of a few miliseconds, tops.
What we can achieve with TeX is in the order of seconds, at best — for simple documents.
I am definitely not convinced this lives up to Bret’s standards :-).
You're right -- this isn't, and won't ever be (as long as it stays with this technology) up to Bret's standards.
However, Bret's stuff doesn't exist, and there's a reason for that: it's really hard. What these guys are doing is trying to make something that actually works, and it looks like they're doing a pretty decent job of it. The fact that it integrates with all the normal tools (in particular, LaTeX) makes me inclined to overlook it's imperfections.
I didn't know about whizzytex, it's very interesting. The ability to modify placement with the mouse looks quite neat. I'll look into it, thanks.
To add on pcmonk's answer, this program has two advantages over latexmk : it does not require the user to save the file (in the video, you can see the double stars in the status bar of emacs : the file is not yet saved) and it works with any text file-(compile)->result loop, not just LaTeX. You could use it to edit executable code (see the python example) or HTML for example.
"Recently, some people have mistakenly attributed the "live coding" concept to me, but it's not a new idea, it's certainly not "my idea", and it's not a particularly interesting idea in itself. Immediate-update is merely a prerequisite for doing anything interesting -- it enables other features which require a tight feedback loop. An action game with a low frame rate is a bad game, but simply upping the frame rate doesn't magically make a game good."
But to the point, Bret mentions specifically that this isn't what he's talking about, but saying so anyways is a great way to climb the karma ladder in HN.
I knew of the ideas linked to live programming only thanks to Bret Victor's presentation. I guess I did not do my bibliographical homework.
Your spike about karma was unnecessary, the goal of this submission was to gain exposure to have feedback, which I got.
I will now act on this feedback. Your essay is very interesting in this regard to help me understand what features are necessary to implement, as well as for bibliographical references.
The LaTeX demo reminds me of Gummi[0]. Gummi has a similar two-paned interface with LaTeX on the left and the preview/build log on the right. This project seems a little too complicated, although their solution is a lot more general than editors like Gummi as it supports HTML and your editor of choice.
The ramdisk is for performance purposes. As for FSEvents/inotify, I just did not know it existed. I will compare both approaches performance-wise. Thanks.
18 comments
[ 2.7 ms ] story [ 50.5 ms ] threadOn a philosophical level, I like how this should integrate well with the rest of the Unix utilities. It isn't as immediate and interactive as Bret Victor's examples, but I think this has the advantage that the code is actually there and it works. It's not the ideal system, but I suspect that it is an improvement over the status quo. I'll definitely be keeping an eye on this.
Check "diverging" and "colorblind safe"
Also, there’s http://cristal.inria.fr/whizzytex/whizzytex.html
Since I decided to use LuaLaTeX for my documents, I can’t use whizzytex (but I’d love to!) and compilation time is insanely high with LuaLaTeX.
My main point of criticism is that this is _not_ what Bret Victor describes. Sure, quick feedback is nice, but that’s not the point of his videos. In the videos, you can actually modify the program using the interface. For our example, you should be able to edit in the xpdf viewer, but you can’t.
Additionally, I think that's actually the right way to do it. The result should be optimized for viewing, not for editing, and the editing environment should be optimized for editing, not for viewing. If the two can be merged into a tight feedback loop, then maybe we can get something of the best of both worlds.
I still maintain that the feedback loop demonstrated in Bret Victor’s videos is _significantly_ quicker than anything you can achieve with any TeX engine in its current form.
Think of the part where he draws the fish. Or where he drags a slider. You need update rates of a few miliseconds, tops.
What we can achieve with TeX is in the order of seconds, at best — for simple documents.
I am definitely not convinced this lives up to Bret’s standards :-).
However, Bret's stuff doesn't exist, and there's a reason for that: it's really hard. What these guys are doing is trying to make something that actually works, and it looks like they're doing a pretty decent job of it. The fact that it integrates with all the normal tools (in particular, LaTeX) makes me inclined to overlook it's imperfections.
To add on pcmonk's answer, this program has two advantages over latexmk : it does not require the user to save the file (in the video, you can see the double stars in the status bar of emacs : the file is not yet saved) and it works with any text file-(compile)->result loop, not just LaTeX. You could use it to edit executable code (see the python example) or HTML for example.
"Recently, some people have mistakenly attributed the "live coding" concept to me, but it's not a new idea, it's certainly not "my idea", and it's not a particularly interesting idea in itself. Immediate-update is merely a prerequisite for doing anything interesting -- it enables other features which require a tight feedback loop. An action game with a low frame rate is a bad game, but simply upping the frame rate doesn't magically make a game good."
But to the point, Bret mentions specifically that this isn't what he's talking about, but saying so anyways is a great way to climb the karma ladder in HN.
Your spike about karma was unnecessary, the goal of this submission was to gain exposure to have feedback, which I got.
I will now act on this feedback. Your essay is very interesting in this regard to help me understand what features are necessary to implement, as well as for bibliographical references.
Good luck with your work and I'm glad my essay was useful!
[0]: http://en.wikipedia.org/wiki/Gummi_%28software%29