What makes good and what makes bad programmers?

The only supporting evidence for the “uberhacker” was a study on batch processing vs interactive programming, in 1960. On a handful of people, in a half hour session. The rest of the noise is untamed adolescent egotism.

If I’m not careful I’ll link to every one of tef’s posts.

An Introduction to You

This is the Fall from Grace phase, Not-So-New Person. We’re disappointed, and the degree of our disappointment is proportionate to our previous impossible and unspoken expectations.

I would like to get through this phase as quickly as possible.

Go and Rust — Objects without Class

Depending on the language and the programmer, asking somebody to define inheritance could result in one of several different explanations and behaviors. Neil Brown tackles the nebula that is inheritance, and how Go and Rust attempt to clear up the confusion by providing clear alternatives with specific benefits. An important note is how the removal of classes from Go and Rust is not a primary motive, but a side effect of specific design decisions.

The article also mentions one of the reasons I appreciate Go’s approach so much: instead of faffing about in runtime hoping distinctions between polymorphic instances are caught, Go gets rid of the notion of ‘type hierarchy’ altogether, and lets the compiler discern what instances are capable of doing what, and where. Programs should not read as a “debate with the compiler”, as Dick Gabriel said.

Fixing E.T. The Extra-Terrestrial for the Atari 2600

I love that someone is dedicated enough to dive into the assembly of E.T. to make it a more palatable, fun and robust game. The work involves making use of every spare byte, stepping through the code to find where its variables subtly intertwine, and even ensuring the changes pass muster with “die-hard E.T. fans”, who apparently exist.

Eventually I’m going to sit down and fire up E.T. myself, and play it with and without the changes to really get a better appreciation.

prev Page 7 / 8 next