Design Principles

Published on Saturday, June 17th, 2017


Here are a few design principles that I've thrown together:

# The principle of least astonishment
  Everything from spirit and semantics to syntax and naming should
  strive to minimize astonishment. For instance, if you got an
  ordered sequence of items, you should be able to use operations
  that makes sense in an "ordered sequence"-context, regardless if
  the ordered sequence in fact is a list, an array or a string.
  Reversing this ordered sequence should then be named something
  aptly like "reverse" in order to reflect what we intend to do.

# There's more than one way to do it
  Ah, the good old Perl mantra. Many appear to shy away from this
  principle, citing the write-only nature of many Perl scripts as
  the reason. I think it is a sober reminder that as the designer
  of a language, you can never anticipate the needs of a programmer
  and that you should never, ever be so arrogant to believe that.

# Premature optimization is the root of all evil
  The Knuth quote pretty much says it all: you shouldn't optimize
  before you know what is relevant and how.

# Premature safety is the death of expression
  My personal twist on the quote above. I feel that a premature
  focus on safety kills expression. Safety is good, but only when
  you know what need to be safe.

# Shit will happen
  A fact of life. There's no prevention to it, so building systems
  that try to postpone the inevitable is a silly enterprise.

# Fail fast, fail hard
  Addendum to the previous principle; fail and retry with a clean
  state. (See Erlang)

# No one's ever died from a little dirt
  Don't get blinded by the quest of providing elegant precision
  tools. Sometimes blunt force is the right answer.

# Human first, machine second
  A reminder that the language is a tool for humans, and that
  the matters of the machine should not distract the human.

# It's better to solve the right problem the wrong way,
# than the wrong problem the right way
  In other words, don't talk about right and wrong if you don't
  have a clear idea of how the playfield looks like.

# Keep It Simple Stupid
  A reminder to not overcomplicate things. Less is more.

# Composition is key; small parts doing specialized work are
# easier to reason about, test and reuse.
  Also known as bottom-up design and the 'unix philosophy'.

# Separate policy from mechanism; spearate interfaces from engines
  It's generally a good idea to keep the inner workings separate
  from the interface, as you don't want to leak abstractions out
  as much as you don't wan to leak inhibitions in from a poorly
  thought out API.

# Clarity is better than cleverness
  'nuff said.

This is of course bound to be changed, but I guess it's nice to get
a feeling for what I'm aiming for.

<3 jzp