Complexity is the enemy

The author is not saying "write C in Python," he's saying "Aim for C-style abstractions in Python." i.e. build the codebase around the bread-and-butter: function calls, iteration, reference-passing and mutability, and not around abuse of the numerous higher-level abstractions available(meta-programming, yield, exec()...). It's a lesson learned regularly by programmers as they gain experience and move towards conservativism, after having seen all their silver bullet attempts go up in flames.

A similar tenet holds for the opposite direction - the performance junkies; the tendency with experience to move away from locking in specs early and doing heavy micro-optimization, towards writing the initial code in a way that tries intentionally to make it easy to modify.

It's not about the language.

To me, the author is spot on here. It is only through experience that you begin to see all the ways in which complexity can creep into a system, and why each and every one of them is bad.

Unfortunately, almost every codebase I work on right now is more complex than it needs to be.

To me, the zenith, "The simplest possible solution that does what is needed, but no more", helps a lot.

he's not saying c code is clear; he's saying that using c code can help you avoid complexity because many things you might attempt in another language are simply too expensive.

nor is he saying (as someone else said) that you should avoid higher level constructs in other languages. its quite ok to use those, as long as you keep things simple.

simplicity does not map 1-to-1 on language features and is hard to explain because it's very context dependent. it's more "YAGNI" than "avoid yield in python".

for example, here's an example from Python i noticed just yesterday. i had some code that expanded a particular kind of data and i wanted to let the user do something with the data. so i added a callback - on each step in the expansion i pass the user the relevant chunk of data through the callback.

but how do i handle errors? i had a use-case that needed to handle errors, but they didn't fit with the callback. so my first thought was to make the callback an object and have a method to handle exceptions. but that looked complicated.

then i realised that i was passing the callback a list of values. if, instead, i passed a generator, then the exceptions, when they occurred, would be raised inside the callback! so by "using yield" i kept things simple.

Agreed. If a language is more expressive, it becomes simpler. I don't think being low level is the same as being simple. Declarative languages tend to look more like English than C or Assembly does. Looking more like English seems like a pretty powerful indicator of simplicity. It is certainly easier to read.

"I tend to care more what the code does as opposed to how it does it"

Exactly. Lets focus on solving the problems and not letting the solutions become problems themselves.

But in practice, how many bad abstractions are there? From what I understand the Go team sees VMs as bad abstractions and they're ubiquitous.

The Go compiler can be fast, essentially as fast as a VM. Go can already run ~3x slower than C and they haven't put much effort into optimization. V8 is ~5x slower with a larger team working longer, 50,000 LOC compared to ~12,000 LOC of Go. To get the security of a VM they discourage the use of low level stuff by putting it into an unsafe package. This makes the binaries compatible with NativeClient, which actually checks for malicious programs. Go code can be sent as text and compiled quickly enough client side.

So they get many of the features of a VM while cutting down on complexity with some clever tradeoffs. The language is not for everyone's tastes, but their fundamental approach will surely lead somewhere.

In practice people make bad abstractions constantly and build huge legacy on top of them. Lately people have been trying to clean up the mess by starting from a pretty low level, like Go and Redis.

I like this. "The only weapons we have are simplicity and convention." Well said. I think we need to espouse a new software paradigm: DFS-oriented programming. (Dead F*ing Simple-oriented programming.)

Not sure if more lines are per definition more complex. Often they are, but check many Ruby (and Rails) gems and apps; they hide a lot at the expense of easy comprehension. That's why it is often referred to by inexperienced programmers as 'magic'; stuff in Rails works nicely if it works. If it doesn't work, you get to wade through miserable stacks of meta programming (with the worst debugger ever made). Give me C or Haskell (yes I know, big difference; I'm just skilled at both) any day, complexity wise. It's more about the programmer than the language of course, but the Ruby community generally seems to suffer from making stuff non transparant.

Yes, while we are at it, let's write C like it was Fortran.

I'm an OCaml fan as well and having written in a number of languages I can say that complexity in and of itself is probably not the enemy. I think the problem is more related to modularity. For instance I don't think it is the best policy to make a skip list implementation as simple as possible because it is self contained and will likely be used by many of my programs in the future. Complexity only becomes a problem when it is no longer possible for a developer to fit all the pieces of the program in her mind at once. Abstraction and modularity can generally help with this.

Just because you personally cannot handle macros does not make the code "read only". As I remember, your CL skill is minimal, and your macro skill even smaller.

I am the "rock star" programmer, here referred, and all my code has been easily worked on by three other people, well versed in CL, with only compliments for readability.