Currently more a collection of things than any conclusions, but it's useful to have some succinct guiding principles.


Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!


Communicate intent precisely.
Edge cases matter.
Favor reading code over writing code.
Only one obvious way to do things.
Runtime crashes are better than bugs.
Compile errors are better than runtime crashes.
Incremental improvements.
Avoid local maximums.
Reduce the amount one must remember.
Focus on code rather than style.
Resource allocation may fail; resource deallocation must succeed.
Memory is a resource.
Together we serve the users.
Assigned to
1 year, 2 months ago
6 months ago

~icefox 1 year, 10 days ago

A few thoughts:

  • Start with as little convenience as possible, only the things that are necessary, and explore from there
  • Merge concepts that are similar
  • Keep separate concepts that are dissimilar
  • Don't try to hide implementation details
  • Mend and defend. (hah)

~icefox 8 months ago

  • You want to be able to touch the hardware
  • You need to be able to describe what the hardware expects to the software
  • The programming language can't prevent someone from pulling the plug on the machine

Simon Heath 6 months ago ยท edit

  • Don't try to hide implementation details -- rather give control over them
  • It's ok not to be the best tool for every problem domain, you become a great tool by specializing
  • This means that tools need to be able to work together
  • Never make the language guess what you mean (though you shouldn't have to tell it to do the obvious thing over and over, either)
Register here or Log in to comment, or comment via email.