REBOL Technologies

Definition of Simple

Carl Sassenrath, CTO
REBOL Technologies
28-Mar-2011 9:45 GMT

Article #0509
Main page || Index || Prior Article [0508] || Next Article [0510] || 235 Comments || Send feedback

For more than a decade I've loosely used the word simple... but, what is simple? I've avoided defining the word. Why? Because I thought the definition itself might be overly complex.

Well, I know now. This experiment called REBOL has taught me quite a lot, and more recently in some of the work I've been doing, I've had the chance to contrast my ideas (yet again) to the quite different world of modern computing (pick Linux, Windows, XML). But, it goes beyond that, doesn't it? Couldn't I just as well say modern government, modern management, modern medicine, modern investing, or modern education?

Simple is:

  1. Clear abstraction: smart, well-drawn layers of "knowledge focus" that allow hiding of details.
  2. Clean expression: meaningful, concise but not cryptic, representation and communication of concepts.

If you're a computer scientist, engineer, or programmer, or even if your inclined in that general direction, then you already know the first requirement because it's stressed heavily these days. You hide the complexities of code in layers.

For example, if in REBOL I write:

image: load %photo.jpg

This loads a JPEG image into memory and defines the word image to represent it. Now JPEG itself is a complex multi-layered image compression process. But we don't need to care about that. All we need to know is load. That's the power of abstraction.

Unfortunately, the second requirement of simple is not stressed at all and therein lies the rub. In fact, I could claim that cleanliness of expression is completely ignored in most modern anything, whether that be a core OS subsystem or bill of law placed before congress.

Let me make my point concrete with an example. In REBOL one can write:

button "Click Here" green [browse the-website]

Within a GUI dialect of REBOL (e.g. VID) this line defines a button to be shown in a window and specifies its color, text, and what happens when it's clicked.

Now, compare that expression with what you might write in C++, Java, or most other "modern" languages. Really... if you know those languages, you immediately recognize my point here. And, please don't tell me that that problem is solved by XML, DHTLM, XHTML, XSL, XSD, XSLT, blah blah blah. It isn't, and if you listen to that little voice deep inside, you know that SGML-isms aren't the answer to most problems. Sure, you wish they were; but sorry, they aren't.

In recent months I've had to dive deeply into very large piles of "modern code"... not only specialized programs (like ffmpeg and gstreamer) but major libraries of huge GNU code-bases that provide core functionality (Linux, pick any lib.) And, I'm not a newbie here. My history is well documented.

Yet, when I browse these massive code-bases what I clearly see is a complete naivety of the engineers and/or programmers who wrote it. I'm not talking about their understanding of the knowledge domain, I'm talking about how they've mostly ignored tapping into the realm of expression as part of their solution.

Some designers recognize deep down that something is wrong, and to help solve their problems, they often invent yet another language as a layer within their system. Modern Linux is completely littered with such languages, and it's a huge mess that spans everything from how you configure and build the kernel down to how you write little script jobs.

The problem here is that there's no unity of language design, and in fact since most domain-smart programmers don't know much about language construction, you get something really quite ugly and nasty. Sure, people will force themselves to learn it, but only because they want the final solution... the circuit design, chip layout, kernel build, highway structure, nuclear reactor simulation, ...

But something important is lost in that approach. Simplicity is sacrificed.

Many designers strive for simplicity, but they don't truly understand the definition of the concept. They often point to an API that is well designed, but in actual usage it is by no means simple. When I look over such programs, all I see are the main expressions trying to break free of the code itself!

In my opinion this problem can be solved. And yes, you know that as the designer of REBOL I offer its main principles as a good first draft of such a solution.

For many engineers and programmers it is just a matter of waking up and understanding that they need to take a more unified view of the entire problem space, not just focus on solving a specific problem and perhaps providing good abstraction but horrible expression.

Ok, so there you are. Simplicity defined. You no longer have any excuse. The world needs simplicity... and frankly in many more domains than just computing.

I wasn't sure that I could ever write this. But now, with the experience of the last six months, it has become clear to me.


Updated 19-Oct-2017   -   Copyright Carl Sassenrath   -   WWW.REBOL.COM   -   Edit   -   Blogger Source Code