Hacker News new | ask | show | jobs
by gavanwoolery 2497 days ago
I've been programming for a quarter of a century.

It has taken me a long time to realize that "dumb code" is the best.

Dumb code is easy to read.

Dumb code is concise and to the point, not attempting to address theoretical problems (necessarily).

Dumb code does not overthink the problem.

Dumb code helps you sympathize with the machine.

Dumb code has no weird blackbox behavior.

etc...

3 comments

This, exactly.

Brian Kernighan (of K&R fame): Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

This is exactly why I love Go so much. The whole language is just dumb and simple, you need to REALLY work hard to make complex shit with it.

Doing things the dumb and easy (and maybe a bit verbose) way is the path of least resistance.

Compare that with C++ with its templates and Javascript with its ... everything and even Rust. They invite you to make the most complex monstrosity you can manage with all of the fancy stuff at your disposal.

> The whole language is just dumb and simple, you need to REALLY work hard to make complex shit with it.

On the contrary, the resulting code bases are more verbose and harder to understand compared to more expressive languages. And by the latter, I'm not even talking about things like Scala or F#. Java and C# are strictly more expressive and have stronger modeling power compared to golang. Reality is complex, you don't want a dumb language to model it because it will translate to complexity in the code base.

Here's some expressive code. If you aren't familiar with Ruby, how long would it take for you to decipher what that does?

  def sum_eq_n?(arr, n)
    return true if arr.empty? && n == 0
    arr.product(arr).reject { |a,b| a == b }.any? { |a,b| a + b == n }
  end
The exact same code in Go would span multiple lines, but would most likely only be constructed of a few basic programming idioms that every programmer with a few months of experience can identify.

Code is read 10x more often than written, it should be easy to read and skim through. "Expressiveness" of code is a quick way to get incomprehensible crap that works, but no-one but the creator can decipher.

> If you aren't familiar with Ruby, how long would it take for you to decipher what that does?

Why would I not be familiar with the language of the code base I'm working with? This is a fallacy.

Secondly, I don't use Ruby, and from what I can tell, it's finding if any two non-equal elements in a given array sum up to a given number n.

I worked on several golang projects. It gets tedious and messy very quickly seeing code bases littered with one-use functions with what basically amount to map/filter calls being expanded into multiple line for loops. Not to mention it makes exploratory debugging much more tedious.

A corollary to that-- less code written the better.
Not always. eg, simpler code is sometimes turning a line into two or more lines, just to make variables named in a way that describes what's going on.
It's not just less, it's being as straight forward and simple while avoiding any temptation to be clever.