# TheJach.com

#### Jach's personal blog

##### (Largely containing a mind-dump to myselves: past, present, and future)
###### Current favorite quote: "Supposedly smart people are weirdly ignorant of Bayes' Rule." William B Vogt, 2010

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?

# Why write?

I haven't posted anything of substance here in a long time. Life has been weird since a couple days after my September 2014 post. I'm in a mind state I've been in before, and I'll work through it eventually, but during this time I'm just not capable of caring about much of anything beyond what I deem necessary in order to get to tomorrow, so my actions are limited.

I'd like to write more. I enjoy playing with ideas, not necessarily taking them seriously, but sometimes updating to some conclusion that results from playing. For example, it's kind of fun to think about ideas that would make big democratic governments work more efficiently, And by exploring that thought-space, one can arrive at conclusions where doing X is significantly better than doing Y, even if this other totally different and opposing thing Z is better than all of them. It's like noticing that a flu is strictly a lot better than stomach cancer, even though they're both terrible and being healthy is totally superior. Except it's funner to work with more abstract things than sicknesses, and it becomes more exploratory that way (since things aren't self-evident, or "trivially derived from some framework but I'll never show you a proof"... you have to do work to explore), and in the end sometimes you'll have something you can reduce back to a less abstract belief or suggestion.

What little idea playing I've been doing lately has taken place mostly in the context of my head. And unsurprisingly, it has less quality. Writing (and the concurrent and following process of editing) creates a better environment for exploring, because you have to crystallize what exactly you're thinking and not just rely on your brain's intuition. I have many thoughts that are interesting, but not expressed in words, but then I forget about the thought because I didn't write it down.

# Meh

In first grade, my teacher taught the class some French songs. Here are two I still remember that were meant to teach colors and days of the week.

http://learnenglishkids.britishcouncil.org/en/songs/i-can-sing-rainbow

Red and yellow
And pink and green
Purple and orange and blue
I can sing a rainbow
Sing a rainbow
Sing a rainbow too
And sing everything you see
I can sing a rainbow
Sing a rainbow
Sing along with me