Today was the kind of day SFPC dreams are made of … at least mine.

How to draw a line

The morning class today was animation with Zach. It was our second dip into the pool, looking again at explicit animation — animation created by moving the object itself. Before coming to SFPC, animation was definitely one of those concepts that was a step beyond my current knowledge. Even drawing a line with a trail: I knew one could turn off background redraw, but that was … unsatisfying.

Today! tho. Today! Today we looked at creating points vectors in openFrameworks and using various functions to draw, erase, and even “unfold” lines. (This last involves removing a random point as you undraw your line, straightening the path you’ve already drawn.)

Even more exciting was noise and variation with sin() and cos(). Everyone here has their spots of low knowledge and, along with hardware, trig is mine. I’m not exactly a mathophobe but perhaps apa-math-etic. Looking at the oF approach, where sin() and cos() make cool shit happen though, has added some deep interest to to the two little buggers. I can’t wait to dig into our examples and homework, which is to create some John Whitney–influenced animations with my new friendly trig buddies.

A question of grammar

Afternoon was Radical Computer Science, which remains my favorite course. We reviewed our PostScript homework and talked about stacks and identity + value, then jumped into the part I was waiting for: discussing our grammar homework. Turns out I love grammar in programming as much as I do in English, which is to say: structure of expression interests me as much as expression itself.

Ramsey has written plt.js, a library that sits on top of pegs.js, which implements the PEGS parsing approach. Within it, we can define our own little grammars for parsing inputs. In this case, we were given a bunch of examples with no rules/processes and had to write our own. I am especially proud of my boolean solution, where everything is false unless it is explicitly true. Somehow that seems apt.

There is something about designing programming languages that just gets me right in the funs.

A magnificent obsession

Meanwhile, as Zach had suggested last week, I took some time to print out d3 code I had been working with and annotated it. This began somewhat normally but quickly spiraled into this:

Turns out, I really like marking up code. As I was chatting with Ramsey after class, he suggested the markup on my d3 might be a good place to start considering what I want to do for my language design project (the final product of this class). Zan and I started discussing d3 itself and well: we are going to build a d3 emitter.

This conveniently coincides with my other magnificent obsession: d3 and d3 libraries. One of the reasons d3 is amazing is the level of control one has over drawing the SVG. One of the reasons it is not amazing is … the low-level specification needed to have so much control. Most approaches to mediating this problem tends to be creating drawing libraries that, essentially, take config objects and apply them to prewritten d3 charts, thus throwing users back into the arms of library designers, like it is High Charts all over again. But I haven’t been able to think up an alternative … till now.

The reliance on config objects seems to me to be an artifact of javascript & svg themselves. But creating a high-level, specific-purpose shorthand language for emitting the d3 ( maybe and adding in basic good hygiene), and leaving access to the important parts intact, may be just the thing for leaving config objects and lots of typing behind.

I told Zan: “We are doing this. We can just blah and foo and bar.” She suggests it may not be this simple and I know it won’t. But I can’t wait to get stuck and then figure out how to make it all work.

All in all, I give today