I didn’t really start appreciating the concept of simplicity until I started working with Clojure. I used to value having lots of language features, multiple paradigms, having syntax sugar, and so on. It felt like having more options available would allow me to write the best solution for each kind of problem.
What I came to realize is that you don’t need a lot of language features for it to be flexible and expressive. Having simple syntax and a few common patterns for solving problems makes it much easier to both write and maintain code. When your language is small it requires little mental overhead allowing you to focus on the actual problem you’re solving.
It’s a pretty reasonable interpretation of this phenomenon.
However IMHO it’s partial.
A surprisingly accurate exaggeration is that all that hackers want is power
All hackers want is applicable knowledge.
Power mostly comes from others’ ignorance.
But it’s true that some hackers pursue power through knowledge.
power […] straightforwardly comes out of flexibility and moldability of tools and interestingly enough principled design is probably the most direct path to flexibility.
It’s just a matter of optimization.
A human brain can take into account up to a certain amount of information at any given time.
Hackers are pretty good at recursion and decomposition, but with simpler tools the stack is easier to analyse.
In Jehanne I look for the simplest possible system API (and file system protocol) that can be composed to provide the everything a mainstream OS provides but also more safe and powerful distribution of computations than are currently achieved through the browser.
However simplicity is not without tradeoffs.
For example, the current number of system calls is 26 (and 6 more might be removed without too much refactoring in userspace) but performance of local computations in Jehanne will be worse than in Unix, while distributed computations will be way faster (and way more secure) than Browser+Unix.
The same might apply to a programming language.
Wirth’s Oberon-07 is simpler and safer than C, for example, but it’s not much studied and used despite its noble ancestors.
I think there’s a productivity argument to be made here, too. The simple models designed with consistency and easy composition will lead to less unexpected behavior or breakage. They’re easy to build on or change. That means Perl 5 might have gotten to its current state sooner using a base like Scheme. It would be even more powerful because the developers would’ve have been fighting against the side effects of the foundation they were building on.
Of course, tools such as REBOL and Racket already show that the two models can be combined for benefits of both. Just start with that core which is designed for easy tool building, esp DSL’s. Then, build away. :)
OTOH, productivity is the selling point of several language features that increase the language’s complexity: macro/template/generics, annotations/attributes and so on…
Looks like a tradeoff between development (aka software production) and maintenance (debugging).
I was talking the interfacing and implementation. There’s simple implementations of such things out there. Julia was partly implemented in one example, femtolisp, which piled a lot of features into what was originally 1kloc staying simple as possible. Far as larger projects, you can look at STEPS project from Alan Kay et al’s VPRI research here. They use metaprogramming with a simple base language to build an OS in small lines of code using composable DSL’s. Since it’s newest to oldest, start with STEPS link on the bottom. Then work upward.
“Looks like a tradeoff between development (aka software production) and maintenance (debugging).”
I’m not sure. I’m still looking into that. It’s a safe bet to think it’s true, though.
I didn’t really start appreciating the concept of simplicity until I started working with Clojure. I used to value having lots of language features, multiple paradigms, having syntax sugar, and so on. It felt like having more options available would allow me to write the best solution for each kind of problem.
What I came to realize is that you don’t need a lot of language features for it to be flexible and expressive. Having simple syntax and a few common patterns for solving problems makes it much easier to both write and maintain code. When your language is small it requires little mental overhead allowing you to focus on the actual problem you’re solving.
It’s a pretty reasonable interpretation of this phenomenon.
However IMHO it’s partial.
All hackers want is applicable knowledge.
Power mostly comes from others’ ignorance.
But it’s true that some hackers pursue power through knowledge.
It’s just a matter of optimization.
A human brain can take into account up to a certain amount of information at any given time.
Hackers are pretty good at recursion and decomposition, but with simpler tools the stack is easier to analyse.
In Jehanne I look for the simplest possible system API (and file system protocol) that can be composed to provide the everything a mainstream OS provides but also more safe and powerful distribution of computations than are currently achieved through the browser.
However simplicity is not without tradeoffs.
For example, the current number of system calls is 26 (and 6 more might be removed without too much refactoring in userspace) but performance of local computations in Jehanne will be worse than in Unix, while distributed computations will be way faster (and way more secure) than Browser+Unix.
The same might apply to a programming language.
Wirth’s Oberon-07 is simpler and safer than C, for example, but it’s not much studied and used despite its noble ancestors.
I think there’s a productivity argument to be made here, too. The simple models designed with consistency and easy composition will lead to less unexpected behavior or breakage. They’re easy to build on or change. That means Perl 5 might have gotten to its current state sooner using a base like Scheme. It would be even more powerful because the developers would’ve have been fighting against the side effects of the foundation they were building on.
Of course, tools such as REBOL and Racket already show that the two models can be combined for benefits of both. Just start with that core which is designed for easy tool building, esp DSL’s. Then, build away. :)
OTOH, productivity is the selling point of several language features that increase the language’s complexity: macro/template/generics, annotations/attributes and so on…
Looks like a tradeoff between development (aka software production) and maintenance (debugging).
I was talking the interfacing and implementation. There’s simple implementations of such things out there. Julia was partly implemented in one example, femtolisp, which piled a lot of features into what was originally 1kloc staying simple as possible. Far as larger projects, you can look at STEPS project from Alan Kay et al’s VPRI research here. They use metaprogramming with a simple base language to build an OS in small lines of code using composable DSL’s. Since it’s newest to oldest, start with STEPS link on the bottom. Then work upward.
“Looks like a tradeoff between development (aka software production) and maintenance (debugging).”
I’m not sure. I’m still looking into that. It’s a safe bet to think it’s true, though.