state of the art

If you’re like me then you are constantly depressed by the state of the art when it comes to software and all things related to it. Many of the tools I use day to day haven’t moved an inch since the day they were invented back in the heyday of computing. Do a search for “the mother of all demos” and you’ll know what I mean. Continue reading

the toolmaker’s curriculum

The limits of my language mean the limits of my world.
– Tractatus Logico-Philosophicus (5.6)

It is one of the chief skills of the philosopher not to occupy himself with questions which do not concern him.
– Ludwig Wittgenstein, Journal entry (1 May 1915)

What cannot be imagined cannot even be talked about.
– Ludwig Wittgenstein, Journal entry (12 October 1916), p. 84e

By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race.
– A.N. Whitehead

Programming languages, because they were designed for the purpose of directing computers, offer important advantages as tools of thought. Not only are they universal (general-purpose), but they are also executable and unambiguous.
– Kenneth E. Iverson, Notation as a Tool of Thought

The goal of the programmer isn’t to write programs. The goal of the programmer is to make tools that expand one’s world view and reduce cognitive overhead so that the extra mental reserves can be spent on thinking about stuff that would otherwise not be possible to think about.

simulations and sandboxes

Let’s do a thought experiment. Suppose you could take half of the world’s population and put them inside a simulation where time is running slightly faster. If you did this right then you would have “weather prediction” for the state of the world. You could in theory predict the average well-being of the world in the next ten minutes with some degree of certainty. Of course I’m not saying anything new here. Asimov already beat me to the punch with psychohistory and a few others even before Asimov had similar ideas. Lets scale back the science fiction aspect until we get to science. Continue reading

the problem solver’s interview

Do a search for “interviews suck”. There is no shortage of valuable advice out there but it feels like all of it is ignored. My current favorite advice on this is by Laurie Voss.

I can’t quite figure out for what kind of person the current tech interview process is designed for. One thing I know for sure is that it is most definitely not designed for the problem solving programmer. Just like most schools are not designed to make learning fun and accessible the technical interview is not designed to measure what it should be measuring. What it should measure is problem solving ability but instead most people use technical trivia as the proxy and fail miserably.

There isn’t anything I can add here that hasn’t already been said better by Joel Spolsky and Laurie Voss.

programmer fungibility

fungible (adj.) : being of such a nature that one part or quantity may be replaced by another equal part or quantity in the satisfaction of an obligation (oil, wheat, and lumber are fungible commodities)

The common wisdom on this is that programmers are not fungible. You can’t replace someone with 5 years of experience with two who have 5 years of combined experience and expect the same results. This is true but there is another kind of fungibility that can be put to good use. Overlooking this other kind of fungibility is why most startups are complaining about not being able to find good programmers. Continue reading

systems vs programs

Talks by Alan Kay are always fun. In a recent one he talks about inherent vs incidental complexity of software systems. It turns out back in the day there wasn’t much of a distinction between hardware and software engineer. Instead of software or hardware engineer there was just one kind of engineer, the system engineer. The system engineer would think about the problem that was being solved, design a problem-oriented language to encode the problem, and then implement a system to interpret the problem-oriented language to solve it. Continue reading

streams vs indexables

I was trying to figure out why most parser combinator libraries rely on the streams instead of the more natural array-like indexable object. I still haven’t figured it out but following Polya’s advice of finding a smaller problem I can’t solve I settled on figuring out how to convert back and forth between streams and indexables. Continue reading