# Some questions on Star Wars

Warning, spoilers below.

I finally saw the Star Wars movie yesterday. I liked it while watching, and I'd watch it again, though on reflection there are some grievances, or just questions I had while watching or after watching that it'd be nice to have answers for... I'll probably research some after I post this. So break out the pizza rolls, it helps if you read everything below in that voice.

Why are there so many tiny kids in the audience? This is a PG-13 movie. Did their parents not see Episode 3, or are they comfortable with the possibility of their kids seeing on-screen amputation and dead children and flesh-burning? Maybe they just trust Disney is a family friendly company like Nintendo and would never be too violent...

# Some (Updated) Beliefs

Years ago I wrote this, expressing without too much elaboration or reasoning several beliefs of mine in various categories. Needless to say, some have changed, and this gives me an outlet to write a little about what I haven't been writing about. So, following the original categorization (with a few new categories), here are some of my current beliefs. If I don't address an old one, conclude it hasn't really changed. Please keep in mind most of these are "academic level" beliefs and thus I'm not super attached to them, for clarity on that (and maybe some updated beliefs if this post is old) see here.

### Religion

I stand by my original belief in 2009. The only thing I might add is that I think the rituals employed by religion can be useful, ritual itself is important -- see these.

# re-frame: A software FPGA

Ever since ClojureScript was announced I've been keeping tabs on it here and there to see what sorts of interesting frameworks people come up with. I'm pretty picky when it comes to UI development (not because I'm particularly good at it, just because I'm picky in general) and something needs to do quite a bit to convince me it's worth using over plain HTML+CSS+JavaScript. (Not a fan of Backbone, but I did like Angular.)

Anyway, re-frame has been on my radar for a while as "the pinnacle alternative to Om". Om is really neat, but I've never tried it enough to feel like I wanted to try more of it. I've known about reagent for a while (that re-frame is built on) and instantly loved its usage of Hiccup to specify markup. Hiccup is so straightforward and simple I still haven't fully read its spec, though I should do so because it's kind of disturbing to me that if I have a "component" (function) that returns something like [:h1 fn-arg] then I can insert that as a child element to something else either with [my-fn fn-arg] or (my-fn fn-arg)...

Anyway again, last weekend I finally sat down and read all the through re-frame's manifesto in its README. And afterwards I thought: wow, this reminds me a lot of FPGA programming. I decided to 'redo' an FPGA assignment I had in college, using re-frame. This evening I cleaned up what I made and wrote this up.

I recently did a 2-day TDD workshop for work. It covered the basics which were helpful to review, and we did team and individual exercises to apply. My only real complaint is that these exercises were starting from nothing. In order to be convinced of the merits of TDD, I need to see a case study. I need to see commit logs. I need to see a "holy shit" moment where unit tests really saved someone's butter.

Why don't I just go look up those things myself? I'm not particularly incentivized to learn about TDD on my own. That's because I know of the Linux Kernel, which has no tests, and Clojure, which has tests now but none of them written by the core author and creator of the language. Tests are no substitute for careful programming, and if you have careful programming, I don't think you really need any automated tests, though you may find some useful, especially since careful programming is not rewarded in a corporate setting so that bar is a little high most of the time for your average salaried programmer. In one of the creator of Clojure's famous talks he brings up two interesting facts about bugs: they all passed the test suite, and they all passed the type checker. How much value do those two things really give us then when even in the most powerful static type languages with extensive tests we still find an annoyingly large number of bugs? What other things could we trade off with those two things to get a lower bug count? Could we get anything for free if we looked elsewhere? Incentives for careful programming are always going to be a human problem, but perhaps the language can provide features that make careful programming easier? Hence Clojure is garbage collected and immutable by default. Dynamic typing is a tradeoff.

In the class, the final day's assignment was "somewhat large". No one in our group of 20 finished it entirely, including the instructor. This was sort of glossed over, but what I get out of that is: TDD slows me down. Some will argue that as you do it more and more TDD will eventually speed you up, or at least allow you to continue at a constant velocity and not hit a mountain, but without a case study I can't agree with that. I just know that for a new project from nothing, it's much faster for me, and I assume everyone else in the class, to Just Do It, and write useful/semi-useful tests after if I want. (Often to just prove to oneself the thing works as expected without having to prove it manually all the time if the output is complicated.) The time savings of not doing TDD are banked and you can move on to other things. If a bug shows up (that for the sake of argument we'll say would have been caught by TDD), that's okay, you just take from your banked time to fix it. My argument is that if you do in fact spend all of your banked time, and in fact exceed it (subtlety! I'm talking about Expected Time Savings), you're actually spending the same amount of time in total as you would have with TDD, but you're spreading it out (and hence even if you go over your banked Expected Time, that just means your Expected Time was under the real time if you had done TDD to begin with). By spreading it out, you can move faster. :) At least, ship buggy things that mostly work and get you money and then you fix the bugs later, instead of shipping late with no bugs but losing all that potential money. Most customers for most domains don't care if you're 100% bug-free, they care if you solve their problem.

# Another rambling defense of human behavior on the Allais Paradox

The Allais Paradox is about how 1a and 2a, and correspondingly 1b and 2b, in the below alternatives are equivalent decisions:

1a) receive $24k with certainty 1b) receive$27k with 33/34 chance, 1/34 receive nothing

2a) receive $24k with 34/100 chance, 66/100 receive nothing 2b) receive$27k with 33/100 chance, 67/100 receive nothing

# An hour fighting with play-clj

I spent an hour tonight playing with play-clj, with the end goal being a Pong clone. Unfortunately I distracted myself with how play-clj works in a way I don't like, and got nowhere.

I got started game programming with PyGame, which is a Python wrapper on top of SDL with some extra goodies. I think I've been spoiled by the clean mental model of 2D games that SDL provides, along with the total control over the main loop. But PyGame isn't a game engine, it's not a game "framework". It doesn't give you all that much. I enjoy that level of flexibility, though, and the necessary tradeoffs in what I worry about involved in using a game framework always seem to irritate me. One day I hope I'll find a really nice one, that's nice for both 2D and 3D, and has good Clojure support. Unfortunately, play-clj is not it, for me.

What follows is just my personal notes from when I started to when I stopped. I added/cleaned up a couple things in this after-edit. There's a macro, but that's about it in terms of code. I've got nothing against play-clj after this exercise, I'm sure it's fine if you can tolerate the way it and LibGDX do things. Wonderful even. But it's not for me. (At least play-clj. Potentially someone could write a nice enough wrapper around LibGDX that I'd want it.)

# Solving word problems with models vs. direct translation

I skimmed this interesting study this morning. They were testing an idea about how people solve mathematical word problems that are expressing a less-than/more-than relation between two numbers, and then asking for a solution number that makes use of that relational information. They phrased each problem in one of two ways, "consistent" and "inconsistent", and measured successful and unsuccessful solvers. They also measured through eye-tracking what parts of the problem the subjects returned to and what their recall of the problem was, with results that strengthen the interpretation of the successful/unsuccessful results. In the end they found evidence that successful solvers seem to construct a model of the problem internally which they then use to get at the solution, whereas unsuccessful solvers seem to try a direct-translation sort of approach where they take the items in the problem, directly translate them to their most intuitive mathematical operations, and compute.

The way a problem is phrased (consistent vs. inconsistent) is key to getting evidence for this idea. An example problem, phrased consistently, is this:

At Lucky, butter costs 65 cents per stick.
Butter at Vons costs 2 cents more per stick than butter at Lucky.
If you need to buy 4 sticks of butter,
how much will you pay at Vons?