© Kevin Mehall and the Splash Contributors
No special cases, no unneeded abstractions. Splash is designed to be as simple as possible. Simplicity means less code, fewer bugs and more power and speed. Small, simple blocks that can be put together are more flexible and powerful.
The best is never good enough, and it will get better. This may break things. Accept change.
We're rapidly approaching a massively multicore world. Think hundreds, thousands of cores. We'll be there in a few years. If your algorithm looks like, "Do this to the first one, than repeat for the rest" (the lispy linked-list style), you're doing it wrong. Instead, think "split the problem in half, then split those in half..." (the mapreduce way). Concurrency is cheap in Splash. Use it.
Computers are plenty fast. Make it easier on the user, even if it's a little slower or a little harder to code.
When possible, bring things together. The user sees the same actions as the developer. The same tool is used to browse contacts and songs. Avoid duplication. Add data and methods to existing systems rather than reinventing them.
Data is more generic and allows easier user interface for manipulation. Resist the temptation to make everything code.
Why parse when you have objects? Parsing strings is horribly inefficient, both at runtime and development time. Splash objects are persistent; within Splash, there is no reason to serialize anything. Just pass an object instead.