The Unix Philosophy

It's been a while since I've posted. We moved across the country, from Newport to DC, and I start in a new position tomorrow. Maybe I'll get some time to read/write, maybe not.

The most noteworthy book I read recently was The Unix Philosophy by Mike Gancarz (looks like this is an updated version, I read the one with the 1995 copyright date). It's a great read, especially for philosopher-programmer types. If you prefer the tldr approach, wikipedia's short summary pulled from the first chapter and the second answer in this thread, taken from Classic Shell Scripting, a great example of the Unix philosophy at work.

recently noted

Nice short essay on addiction (and homelessness) at Griffen Writes.

--
Also, I recently created a new blog about building web apps - Lack of Elegance.

what i've been reading

Project Management: Scrum, Timeboxing (wikipedia)

How to Start a Startup by Paul Graham (2005)

I'll get back to philosophy at some point. In the meantime, here's Paul Graham's take on philosophy (2007).

starting my own company

Today I quit my job in order to start my own company. It sounds like I'll have two clients on board to begin with. I'll mostly be building web applications and helping determine internet strategies for small businesses.

I would start writing about becoming an entrepreneur but I think Paul Graham has already taken care of that.

dirty systems

This essay does a good job of describing an obvious divide between types of computer scientists (and technology workers more generally).

Theorists Favor Sophistication

Like mathematicians, theorists in Computer Science take the greatest pride in knowing and using the most sophisticated mathematics to solve problems. For example, theorists will light up when telling you that they have discovered how an obscure theorem from geometry can be used in the analysis of a computer algorithm. Theorists focus on mathematical analysis and the asymptotic behavior of computation; they take pride in the beauty of equations and don't worry about constants. Although they usually imply that their results are relevant to real computers, they secretly dream about impressing mathematicians.

Detecting Theory

You can tell someone is a theorist because they slip one or more of the following keywords and phrases into lectures and technical conversations: ``theorem'', ``lemma'', ``proof'', ``axiom'', ``polynomial time'', ``logarithmic'', ``semantics'', ``numerical'', ``complexity'', ``nondeterministic'' or ``nondeterminism'', and ``for large enough N''. They write lots of equations, brag about knocking off the ``extra log factor'', and often end their lecture with an uppercase ``O'' followed by a mathematical expression enclosed in parentheses. You can also recognize a theorist because they take forever to prove something that may seem quite obvious. (I once sat through an hour lecture where someone proved that after a computer executed an assignment statement that put the integer 1 into variable x, the value in x was 1.)

--
Experimentalists Favor Simplicity

Like engineers, systems researchers take pride in being able to invent the simplest system that offers a given level of functionality. For example, systems researchers will light up when telling you that they have constructed a system that is twice as fast, half the size, and more powerful than its predecessor. Experimentalists focus on the performance of real computer systems; they take pride in the beauty of their code and worry about constants. Although they usually imply that their results can extend beyond real computers, they secretly dream of filing patents that apply to extant hardware.

Detecting Systems

An experimentalist will slip one or more of the following keywords and phrases into lectures and technical conversations: ``architecture,'' ``memory,'' ``cpu'' (sometimes abbreviated``CISC'' or ``RISC''), ``I/O'' or ``bus'', ``network'', ``interface'', ``virtual'', ``compile'' or ``compiler'', ``OS'' or ``system'', ``distributed'', ``program'' or ``code'', and ``binary''. They talk about building programs and running the resulting system on real computer systems. They refer to companies and products, and use acronyms liberally. Their lectures often end with a graph or chart of measured system performance. You can also recognize an experimentalist because they describe in excruciating detail how they set up an experiment to measure a certain value even if the measurement produced exactly the expected results. (I once sat through an hour lecture where someone carefully explained how they used three computer systems to measure network traffic, when their whole point was simply to show that the network was not the cause of the problem they were investigating.)

How To Criticize Computer Scientists

A mixture of both is probably best but life is messy and simple solutions are easier to maintain. That means if you do it right a non-technology person (or at least someone with a weaker skill set) may be able to perform that task once completed. So I'm an experimentalist and I value experience. You'd think that theorists are best suited for true programming jobs and that experimentalists are best suited for systems administration but programming often requires integration with various systems. Most of the time (unfortunately) technological solutions aren't built to match theory (they rarely meet specifications, see how well browsers meet w3c or even http specs for an obvious example). What this means is that in practice the "perfect" theoretical solution won't work. Someone else will have to come by and accommodate the clean code to integrate with the dirty systems. Dirty systems will often negate the performance increase gained through the "optimal" theoretical solution as well.

Incidentally, a lot of interviews for programming jobs lean toward the theorist side so it's best to memorize a bunch of rarely necessary crap (O Notation, obscure data structures, better to reuse code or reference the appropriate books when necessary in the real world) before going into those sorts of interviews. I get the feeling interviewers test the theorist side just because it's simpler to test.

Both of these descriptions show how each side can get caught up into details that distract from the problem at hand and having both types on a programming team is usually preferable.

The philosophical point: Humans are dirty systems and they're the systems that we never get away from. So you can either accommodate this truth (experimentalists) or ignore this truth (theorists). Perhaps these correspond with empiricism and rationalism.

on programming and process

Software development abounds with processes of course: we have processes for requirements engineering, requirements management, configuration management, design review, code review, test design, test review, and on and on. Massive process documents are written. Huge diagrams are drawn with dozens of boxes to try to encompass the complexity of the process, and still they are gross oversimplifications of what needs to happen. And yet in every one of these processes and diagrams there is a box which basically says "write the code", and ought to be subtitled "(and here a miracle occurs)". Because the process underneath that box is very simple: read the problem, think hard until a solution occurs to you, and then write down the solution. That is all we really know about it.

We don't know how we program.

Some of the comments on this post are interesting as well. Especially that coding is mostly about design. A good design can save a ton of coding and maintenance nightmares. There's another difficulty though in that when you're creating something completely new, you may not even know what you want yet. So there's a lot of prototyping in coding as well. And then your users start telling you what they want, and on it goes.

programmers and philosphers

Do all programmers eventually become philosophers?

I came across that post recently. I think a knack for systems leads people in many directions. Interesting to read another programmer's perspective.