Here is another set of articles with which to feed your brain. This time around the main focus of my article-scrounging is history and conduct, although a few general programming articles are still there. History is especially important for programmers to understand because it gives us a basis for why things are the way they are today. Last time, I focused on dynamic programming languages (programmer brainfood, part 1).

How to Disagree

We all disagree on things. Sometimes we get carried away, or don’t exactly know how to disagree. This article by Paul Graham is a great overview of the argument pyramid, and a great set of guidelines for your next argument!

Let’s Talk About Python 3.0

Although this article is focused on Python 3.0, the introduction is very insightful and applicable to many areas of life, programming included. (And if you’re interested in Python, go ahead and read the rest as well.) I had always agreed with the lesson of the introduction in some way or another, but reading it there really put things into perspective for me: reasons are important.

Execution in the Kingdom of Nouns

Another long one by Steve Yegge. This time he’s focusing on “noun oriented programming” (which some also affectionately call “object obsessed programming”).

Things You Should Never Do, Part 1

Joel Spolsky talks about a big mistake that a lot of people have made, and I’m no exception: throwing away code. “It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.”

How To Become A Hacker

“There is another group of people who loudly call themselves hackers, but aren’t. These are people (mainly adolescent males) who get a kick out of breaking into computers and phreaking the phone system. Real hackers call these people ‘crackers’ and want nothing to do with them.” Eric S. Raymond, long-time Unix hacker and author, presents an article and FAQ about (real) hacker culture.

The Art of Unix Programming: Chapter 1, Philosophy

Although it’s worthwhile to read the entire chapter, the focal point here is the list of rules that support the Unix philosophy. It’s filled with software design wisdom. Some of my favorites are “separate policy from mechanism” and (paraphrasing) “a programmer’s time is expensive; a machine’s time is not.”

The Art of Unix Programming: Chapter 2, History

Even if you have never used a Unix descendant, such as Linux or BSD, it has such a rich history that it is worth knowing. The birth of the Internet, the C programming language, and the Open Source Movement are all closely related to Unix. (The book is also available as a pdf.)

One of my favorite pastimes is scouring the internet for stuff to read. Much of the time I search for interesting articles about programming (in a broader sense than “just writing code”). These are the fruits of my labor. (This is taken from a post I made on a forum.)

Teach Yourself Programming in Ten Years

Many books claim to teach technical subjects in so-and-so days or hours. Peter Norvig disagrees with this approach and instead offers his own recipe for success, which includes teaching yourself over a span of ten years — not days.

Knowing Java is not knowing much

This article puts forth the idea that simply knowing a language doesn’t mean that you know a whole lot, whether it be Java, C, or something else. It’s a good, brief message.

Design Patterns of 1977

I’ve seen a lot of people try to throw design patterns around to make things less painful, and while well-implemented ones can help out a whole lot, it doesn’t address a core issue: Design patterns show a deficiency in the language.

Static Typing, Dynamic Language Performance, V8 and Tracing JITs

“For optimisation, more is known about a program written in a dynamically typed language at runtime than is known about programs in statically typed languages at compile time.” Dynamic languages are getting much faster. This article drives the point that performance needn’t be a trade-off, and that the more you know about a program’s characteristics at runtime, the more it can be optimized.

Dynamic Languages Strike Back

This is an entertaining and long (transcribed) talk that Steve Yegge gave earlier this year. It goes over a *lot* of stuff (when he’s not rambling ) and may take a while to read through, but it’s still enjoyable.

Beating the Averages

Paul Graham argues that all languages were not created equally, and shares what he believes “power” actually means. This is one of my favorite articles, and I highly recommend it to all programmers. (It is at least worth reading the “blub paradox” section.) He has other interesting essays posted on his website as well.

Write more to write better

From the comments: Someone once asked Somerset Maugham if he wrote on a schedule or only when struck by inspiration. “I write only when inspiration strikes,” he replied. “Fortunately it strikes every morning at nine o’clock sharp.” Not strictly for programmers, but just as effective!

Strong typing vs. Strong testing

Bruce Eckel of “Thinking in [Java, C++]” fame offers the argument that strong testing, even in dynamically typed languages, trumps the presumed safety of static type systems. (Note that “strong typing” here refers to static typing.)

Have some of your own? Feel free to share them!