Rebol's Target Market: Newbies, Experts, or Other?

Usage Philosophy
1

Rebol went through something of a change of course in its mission. The most prominent public post about this change was in a post Carl wrote in 2008 titled Rebol: Not for everyone?.

Caching it here for discussion and pulling together related threads. The below text is Copyright Carl Sassenrath, and comes verbatim from his blog entry #0374

Author: Carl Sassenrath
Date: 15-Oct-2008 21:55 GMT

Many years ago, when I first released REBOL, I decided to introduce it as a simple approach to programming.

In order to help convince new users, I posted a great number of examples on our website and in the REBOL.org library to prove my point. I wrote simple scripts of all kinds. My motivation was to attract new users to try our unique approach, and the scripts were just the candy.

Of course, although I knew that REBOL scripts were often quite simple, we should be very careful not to invert that statement. The existence of one or more simple scripts does not mean that REBOL itself is simple. No, quite the opposite.

Early on, many programmers who encountered REBOL looked at our simple scripts, and not diving any deeper, concluded that REBOL was too simple. Little did they know. REBOL is one of the deepest languages ever designed.

Since those days, I've glanced over a lot of REBOL code written by a wide variety of programmers, and quite often I'm floored. Many programmers use REBOL like they're writing in C or BASIC. I can spot it in an instant; they did not bother to learn the fundamental concepts of the REBOL language. When I see that kind of code, I wonder why they bothered to use REBOL at all. C is better written in C. You will never hear me contest that fact.

I think it's time to change our message. REBOL is not for everyone. REBOL is advanced. It promotes the concepts of symbolics, context, and environment as powerful tools, going far beyond the traditional ideas of functions, objects, loops, and if statements.

REBOL is for a different breed of programmer. It is for those with open minds; those who are reflective, observant, and those who do not simply bang out any kind of junky code that works, but consider each detail of their design, and sculpt it perfectly as a lasting work of thought.

In REBOLville, we often like to boast, just a bit, about how we wrote a cool reblet that was only 15K or perhaps 50K. Yes, we all love that result. But, I think our love of it isn't just because we built useful applications in less than the typical size of a single web page. Sure, that's fun. But, for many of us, it's more the fact that we can, in the year 2008, easily manage the entire software process: getting it built, finding and fixing the bugs, distributing it to our organizations or friends, and then, a year later, add some nice enhancements, often in just a few minutes. We needed no huge multi-gigabyte, complicated, trouble-prone development system or run time monstrosity.

I think we REBOLers have different priorities, different values. REBOL is for a different kind of programmer. We are of the old school but of the next generation. We want more from our language. Sure, we can write simple scripts, but even better, we can write powerful programs that are the size of simple scripts.

I think it has come time to update our message and website. I should not pretend that REBOL is for everyone. It is not. REBOL is for those who of us who think differently.

Frankly, I would not want it any other way.

2

BrianH approved of Carl's post in the comments section, and later wrote a response to the blog link (saying he forgot where it was) in a CureCode ticket. Here's a copy of what he said, put closer to its context.

Author: Brian Hawley
Date: 14-Mar-2013 18:32
...

Rebol 2 was originally aimed at newbies to programming, which is an admirable goal that noone has really managed yet, including Rebol. What Rebol got instead was interesting people, many of whom are power users like Ladislav, but many of whom aren't quite at that level yet. Because of the kinds of things Rebol was actually used to build, Carl decided to change the target market of Rebol 3 to these power users and interesting people (I forget the blog link). That goal has affected the design of R3 much to its benefit, but unfortunately it hasn't gone back in time to retroactively design R2 with that goal in mind in the first place so we still have functions like FOR.

One thing we have to consider is that the new target market requires balance in the design, because interesting people and power users became that way by being different, with different goals, and great minds don't think alike. One of those issues is the need to balance the flexibility that power users need, against the increased need to make it easier for our developers to correct mistakes when they make them, because interesting people make interesting mistakes.

In Rebol 3, one of the design principles we have been doing fairly consistently through the language is that while code is data, for security and stability reasons you, as a developer, should be more careful with code than you are with data - "code" in this case meaning any-function values and code blocks. This isn't an arbitrary thing. Non-active values can be screened fairly easily at runtime just with type testing, and typesets and ASSERT/type make that efficient. Simple value screening can be somewhat easy to do too, if somewhat more expensive. Screening the contents of larger structures can be a bit expensive, but depending on what you want to screen for it could be possible. Screening code at runtime is considered to be a genuinely hard problem and in some cases impossible (people get PHDs for making any headway in this), with way too much overhead to be reasonable, so asking a function to do so is just silly.

However, an actual competent developer reviewing code before they run it is capable of figuring out whether code is safe to run, in some cases using information that Rebol could never know, like the developer's intentions. And because a developer in R3's new target market should be able to handle this concept, we have been working under a policy that R3 developers will be expected to do their own code screening. That means that if a code block makes it as far as being passed to a function to be executed, it is presumed to be OK to execute even if it does weird stuff, because it is presumed that the developer intended to do what they said they wanted to do. The functions protect themselves from malicious code with APPLY and such, and SECURE protects the system a bit, but the code itself is presumed to be intentional. Maybe they intended to shoot themselves in the foot, who are we to judge? Maybe the foot had it coming.

For non-code values, we presume them to be possibly unintentional, maybe the result of data from unknown sources. In those cases, the developer would need help screening out bad data, preferably in native code as much as possible because conditional screening code in DO dialect code is relatively expensive, and if that process involves screening for triggered errors then it gets even more expensive. So we have a policy of trying to rebalance the code so that errors are only triggered in a case where it is a real error, at least according to the declared and documented semantic model and constraints of the function - that makes the remaining errors something you want triggered, for your own benefit. And for value screening, we can presume that the developer actually wanted that screening, because they called that function with those options in their code, rather than another function or options. Because of this we are careful with designing the semantic model of the function, and deciding on the range of the values supported, and what to do when presented with values out of that range, since the right balance of constraints will make the function more useful to the developer. Then they can pick the function that does the screening they need so they don't have to do it themselves.

It is this difference in how we treat code vs. non-code that lets us balance Rebol so it may meet the needs of power-users like Ladislav, and powerful on a good day but would appreciate a little help on occasion users like me. That difference isn't arbitrary, it's a balanced design policy. Consistency would be a mistake here.

...

3

Say what I will about DocKimbel, I feel like he makes the most productive point in the comments, replying to Carl's post, corrected to include a DO:

Author: Nenad Rakocevic
Date: 16-Oct-2008 2:48:33

...

I'm a little disappointed that you didn't add a few simple examples to make the point understood by everyone and show the power of REBOL semantics. Maybe with something like this :

C way:

if a > 3 [
    return "a greater than 3"
]
if b < 10 [
    return "b is a lesser than 10"
]
if ... [
    ...
]
; ...long list of IF statements

REBOL way :

foreach [condition msg][
    [a > 3]  "a greater than 3"
    [b < 10] "b is a lesser than 10"
    ...		 ...
][
    if do condition [return msg]
]

REBOL master way :

foreach [condition msg] load http://site.com/facts.r [
    if do condition [return msg]
]

...

And as he says, that's just off the top of his head. He isn't claiming it's the best "step 1, step 2, step 3" that could be shown. He asks people to brainstorm about better, but no one actually does so.

I'd contrast this with his spreadsheet example, which I think was not a good marketing concept. That is going to invite comparisons and competition...which is kind of all it did. Just read the comments on his post and on hackernews... a few people brought up the usual suspects, Tcl/Tk, K2, even arguing the JavaScript is clearer--which I actually agree with. If he had the time to play more code golf, he might have already known the competition this kind of example is up against. Take my word for it from trying: you don't want to go into such fights unprepared, it is downright hard to beat some of those guys:

https://github.com/DennisMitchell/jelly/wiki/Tutorial

So there's what I think is a good example and a bad example, both from DocKimbel, and I think understanding what makes the good example good is how to understand what Rebol's true "revolutionary idea" is. I think it's a "red" herring to try and argue that you need more or less computer experience to use the language.

4

All the time people new to the language come with suggestions to improve the wsy Rebol does things mostly like langX does things. Showing the Rebol way is adding to the acceptance of it, because often it really improves insight.