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.