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.
