Bad Code Accretes
Sometimes while reading code, I get the impression that the person:
- Kept throwing more code at the problem until it “worked”.
- They never for a moment stepped back and thought about making it simpler.
Great Code Simplifies
Contrast that approach to Ken Iverson in this video from 1974:
I went from application to application trying to use the same techniques. The most encouraging thing is that they would work. After 2-3 years during which time the language had grown by accretion, it grew and grew, eventually I found it was shrinking.
Essentially the idea was once you look at enough different applications you begin to see what is the general notion. So I came to generalisations that allowed me to take out whole chunks of special things I had put in.
Furthermore to my surprise it turns out the general ideas are usually much simpler to understand than any of the special cases.
Modern Languages are Simplifying Common Cases
An Example from KDB
I find it worth mentioning how KDB supplies the user with handles to send data. Here we open a handle h to send a query to a remote process and get the result.
q)h:hopen `:localhost:5000; q)h "2+2" 4 q)h 7
That last line shows that the handle is 7. Why is KDB using 7 for handles?
Because linux maps files/sockets etc. using those exact same integers. In fact in kdb standard out/error can be used as 0/1. When people first encounter this, they find it confusing, possibly because they are coming from other languages that wrap handles ten layers deep in abstractions. I can’t help but imagine:
- Some coders take hours to work out what code can be removed
- Other developers like Arthur may never consider introducing unnecessary abstractions in the first place
Please for the sake of your reviewers take a moment before pushing code to ask yourself, can this be made simpler.