Why learning programming is a great idea even if you'd never want to code for a living

When someone claims that a program has a non-obvious bug, I say "show me the miracle", that is a surprising observation whose origin isn't presently understood. Then, the process of debugging mostly consists in dissolving the mystery, which is usually achieved by performing experiments (sometimes written as actual tests).

What about bugs that arise not from a fundamental misunderstanding of the sort you're referring to, but from some sort of typo or language-specific error that you'd never think of as correct if only you'd noticed? These are more frequent, more annoying because they can come up even in simple tasks, and take just about as long to debug.

I realize that this sort of bug isn't interesting to write about, but you ignore this case completely when stating your 'fundamental law of software'.

I agree with the comments by Misha and JGWeissman, saying that the "fundamental law of software" given here doesn't focus tightly on what's especially interesting about programming. Still, I think I know what Morendil is saying is interseting here; and if it's a misrepresentation of the post, it at least represents what I think makes programming interesting, and hard.

(I'm going to try to explain this without assuming any programming jargon. Catch me if I fail!)

The first lesson of programming is the rules of the game: the syntax and semantics of a programming language, and how to run such code. For our purposes, this is just a substrate. Now, as anyone who's tried to teach an Intro to Programming class can tell you, this substrate is either hard to learn or hard to teach - I'm not really sure which. But that's not the point.

The second lesson of programming, though, is this: In a program of even moderate size, there are too many details to keep in your head. When you're writing line 20,001 of code in your program, it will be wrong -- unless you can make strong assumptions about the behavior of the previous 20,000 lines.

Thus, you learn to write your code in small, modular pieces, and you try to summarize each module's behavior clearly and concisely. Each module needs to be small enough that you can hold all the relevant details in your head -- the meaning of each line, including the summaries of all the code that it refers to. [1]

This introduces a key map-territory distinction. The territory is the code that implements a module; the map is the short description of the module. This distinction is unavoidable when you write large programs. You simply can't manipulate the entire territory in your head all at once, but you expect the code of any module to be frequently dependent on the behavior of several others.

In my experience, the toughest programming errors to fix arise as errors in some programmer's map. Suppose I wrote a module two weeks ago, and now my mental model of that module is slightly wrong, and so I misuse the module in a subtle way. Depending on the subtlety of the misunderstanding, the bug might not even show up until I change the program further -- which makes the bug hard to find, as it won't seem causally linked to the last change I made.

Some specialized map-territory distinctions exist in any field of endeavor. But, a programmer must learn a new map, over new territory, for every new project. That is, the mapped territory changes, sometimes frequently. Thus, vital programming skills relevant to LW interests are:

• Accurately mapping territory,
• Accurately conveying one's maps, and
• Creating territory that can be accurately mapped.

What's more, computers usually give you sharp feedback about whether or not the program works as expected. As such, programming can be a tight feedback loop. So, programming has the right sort of conditions in which to learn these skills.

[1] Ok, you really just need to keep track of some of that detail -- especially if you maintain explicit, logical properties in your code. But you need to know exactly how much detail you can ignore; when you can safely ignore earlier detail, it's due to something like micro-modularization. (I could go into greater detail on this, but it's not the point.)

It's kinda funny, because my map includes "program WILL fail to compile on first compile attempt".
... sloppy coding, maybe, and I would not be shocked to find I pay for my arrogance later on in my carreer, but I've only had ONE bug I couldn't track down: in pong, my computer-controlled paddle behaves more and more sluggishly as the program runs. The player-controlled paddle works just fine. (you'd have to watch it in action...)

"[programming] is in many ways a literary skill."

Be that as it may (or may not), I'd like to see someone keep a straight face while saying that to an English major!

I'm sympathetic to the idea of programming for the purpose of technological literacy, brain exercise, and coolness (as opposed to programming as required for your work, which tends to have a much narrower focus and, in my case, stays at a pretty primitive level.)

If someone who doesn't have a primarily "coding" job wants to actually take your advice, where would it be a good idea to start, concretely?

Stuff I've considered:

learning/reviewing something like C++ that would let me do big computations and simulations (+1 for obvious professional value)

learning web development, beyond HTML (no obvious professional value, but it would be cool, and lends itself easily to a DIY project)

Learning something about computer architecture, operating systems, etc, and building toy models of those (no obvious professional value, looks terrifying, but has the advantage that I'd understand the technology I use instead of playing with a "magic box.")

Something else?

1This history is sadly ignored by a majority of practicing programmers, to detrimental effect.

Why does this happen? The majority of practicing programmers are using languages, and environments designed by other people, but language designers need more skills and interest than ordinary programmers so we might expect that they would be more likely to know about this and include the desirable features in the languages they create. (See James Gosling's quote about Java dragging C programmers half way to LISP).

What happened to the knowledge/skills/interest between the people who implemented LISP as pioneers, the people who learned on the pioneering LISP systems, and the people who create C#, Java, etc.?

Are they really lost and now being 'rediscovered', or were they pioneered, found wanting, and left dormant until technology, software and communications advanced enough to be able to make good use of them?

("It was better in the old days, let me tell you about the old days" is a recurrent theme in programmer blogs, and I wonder if it's really a signal of being in the in-crowd, rather than a genuine belief which alters behaviour accordingly and causes their software to include the sorts of features they are praising).

Are there any good books about the history of programming?

Heh, I just submitted a somewhat similar article not realizing this one was already here. I think they complement each other pretty well, though.

I'd like you to go into more detail about why you say that programming is "literary". Do you mean making one's code readable to other programmers, or the process of creating a deliberate mental model of the program in the minds of the users, or something else?

The second part - "An art with a history" - doesn't seem related to the rest.

This is by way of testing if the discussion area is a good way to get feedback on posts before posting them to LW.

This was previously here where it got some feedback, but the attention it got was short-lived and the post might do with further improvement.