Comments on: REBOL Bloat Busting
REBOL Technologies

Comments on: REBOL Bloat Busting

Carl Sassenrath, CTO
REBOL Technologies
4-May-2006 16:44 GMT

Article #0274
Main page || Index || Prior Article [0273] || Next Article [0275] || 17 Comments || Send feedback

I've received a few feedbacks from people who are worried about REBOL 3.0 becoming bloated. Comments like:

I like the fact that REBOL/Core is only 220K and does not require
special libraries or installation. Please do not change that.

And, this one is even more blunt:

I have a concern that REBOL 3.0 will try to become more "like
the others" -- garbage like Python, Ruby, et. al, designed to
pander to the Corporate CIO brainless.

To this I say: Do not worry!

REBOL is all about being powerful but lightweight, and we're going to keep it that way. That's the REBOL way.

So far, even with several new datatypes and features, REBOL 3.0 is actually smaller and faster than prior versions. I cannot promise 3.0 will remain smaller (there's still more to do) but my point is... we're going to keep REBOL being REBOL: lean and mean.

I think part of the problem may have been the term programming in the large that I used in the REBOL 3.0 Roadmap. This term has a special meaning that could be misleading.

Programing in the large does not mean that the REBOL system or its programs must be large. You can still write a 10K program that does amazing things. The term actually means that if you do write large programs, you will have better internal mechanisms to manage them. For example, modules (namespaces) allow you to write sections of code without worrying about global words colliding with other parts of your code. Tasks allow you to easily create asynchronous sections of code. Object attributes let you control how object fields are accessed and let you attach documentation to your objects (similar to functions).

So, let's keep REBOLing. Bloat is dead. Leaner is smarter.

Personal note:

I think most software and systems are insanely out of control. As a result, not only do they crash (e.g. my satellite TV receiver crashes almost daily), but they do not improve and adapt to user demands quickly. I think the world is doomed if that bigger-is-better approach continues to dominate modern software designs.

I cannot wait for the day when REBOL 3.0 lets us get our little reblets running not only on the desktop (all of them), but the same code runs on the set-top (TV) and the cell-phone!

"I want a REBOL-programmable cell-phone, and I want it now!"



4-May-2006 16:30
Actually, I want a Rebol prommable Zaurus, and I want it now ;-D

On a less serious note: most things which are good for "programming in the large" actually are good for "collaborative programming", too. This term might be more appealing for some ...

4-May-2006 18:12
The word 'bloat' is subjective. Probably every programmer would agree in the broad sense that bloat is bad. But while every programmer may rail against bloat, their actions suggest an indifference toward its antithesis, compactness.

There are a handful of traits that most programmers look for in a programming language:

1. performance (speed & scalability) 2. robustness (features & functionality) 3. detailed documentation 4. active community

I'll call these The Big 4, and set aside issues such as "open/free source code" and licensing. The Big 4 represents a standard that users perceive as being worth paying for.

Where's compactness on the list? I believe it's incorrect to call it a software feature. Compactness could be number 5 or 15 on the list of traits, but my point is about priorities.

I'm not slamming compactness. But my view is-- to rephrase another RT mantra-- REBOL 3.0 should be as small as it needs to be, and no smaller. The mere fact that Carl S. is the language designer should satisfy the most militant anti-bloat ninja-hacker. You'd have to be new to REBOL or asleep for the past 8 years to have overlooked THE FIRST LAW OF REBOL:

REBOL is not fat.

So before you take my statements as pro-bloat, let me revisit: the converse of REBOL, large, multiple-CD spanning IDE programming languages and executables do not drive adoption either.

The issue takes a back-seat to The Big 4, and may serve to distract from priorities which could actually make a real difference to the future of REBOL.

4-May-2006 18:20
I thoink you forgot...

0: Leverage. One executable, small and self-contained, easy deployment.

4-May-2006 18:20
:) I agree that your item zero lists some nice features. Most REBOLers value them. But I am thinking of the next wave of adopters, those who would come after the True Believers.

The question you have to ask is: Are these features key drivers of adoption, and should they take priority over others? It depends on what Carl believes is feasible, but my guess is the answer is no-- not if growth and viability are important.

There are languages that are single executable (or can be packaged), easy to deploy (or ubiquitous), and rather small. Most of these languages live in the margins-- not as a result of their fine qualities, but because Big 4 languages have them out-gunned.

Some will say, "But if REBOL isn't a tiny, self-contained single-executable, etc. it isn't REBOL!" I say, change is good: let's see what Carl S. can come up with. No matter what emerges, as long as Carl is designing it, you can be sure it will be worthy of the REBOL name.

Brian Hawley
5-May-2006 1:28
As long as the features can be loaded when you need them, I'm all for taking extensions out of the runtime. I'm a big fan of /Base and /Face and requested that /Base be ported to WinCE long ago.

You should go further and see how much of the runtime facilities can be shared between REBOL instances, just to cut down on resource usage. Multithreading may render this moot though.

5-May-2006 9:02
I am also a big fan of the /Base and /Face approach. In fact, I would love to see richer, more extensive help/documentation embedded right in the language. Sure, it might bulk up the executable a bit, but a free /base or the SDK could enable tools to slim down such features.
5-May-2006 9:45
The fact that rebol takes 600KB or 3MB is not so important. Floppy disks are not more the base storage on a computer and a hard disk has a capacity of minimum 20GB.

What must be possible with rebol and wich is difficult or impossible with another language ? ...

I want a complete business application, the rebol interpreter, and the application datas, running from a USB key of 32MB.

- The software has a nice GUI and takes no more 5MB (graphics included). - Main versions of the interpreter takes no more than 20MB (Win, MacOSX, Linux and WinCE) - The standalone database engine must be included (RIF?) - The software can be executed directly without installation from the usb key (don't worry about version of rebol) - The software is able to access to a secured rebservice with a minimum of network parameters (or without). - There are some MB to store thousands records.

That's the Rebol I want.

Oh, and if I want, I can copy the directory on my hard drive and connect the application to a MySQLDB (trought the GUI of the application) instead of using the stand alone DB engine. OK, the software could contain an installer... :)

Definitively, that's what my customers ask for. And that's possible with rebol.

OK, it's still useful to "modularize" rebol to allow building a software distribution that contains only what is usefull. If I don't need GUI, Indexed file access and Rebservices, why include it on my distribution ? But this is not this way I think about "powerful but lightweight".

5-May-2006 10:35
>> What must be possible with rebol and wich is difficult or impossible with another language ?

Great question. There isn't much of significant value that REBOL owns and other languages don't have. Compactness is probably REBOL's signature trait, but it is not highly valued among programmers. Therefore little uptake.

A while back I read about Erlang being used for high-performance online servers: substitutes

Of course it would be amazing to write something approaching that level of performance in 1k lines or REBOL instead of 9k Erlang.

Today, other programming/scripting languages have #4 and #3, and are open-source, which permits them to evolve quickly. Perl added parsing grammars a year ago. Ruby will probably have the Anti-Grain GUI before long. Undoubtedly some of these will run on cell phones before long.

Your USB/memory-stick application is a good scenario, but I submit that the distributed network world is more compelling these days. The browser is the GUI, the webserver is the universal server. But I digress.

Pier Johnson
5-May-2006 10:35
:) Goldevil writes, "I want a complete business application, the rebol interpreter, and the application datas, running from a USB key of 32MB"

I want out of 1960s-based MONOLITHIC traps like Windows | UNIX . Desktop PCs are so 20th century.

I want REBOL + PREX + OpenGL ES running on a touchscreen/pen-based UMPC. (for details, see below)

I want separate components that plug together like high-end audio with RCA jacks. I want my pluggable FireWire storage arrays hiding in my tech closet. I want data streams playing on UMPC and my 60" plasma.

What I don't want are towers | mini-towers | keyboards | thumbboards ... 20th century is way over (but the music of the Clash lives on!). It's time to move forward.

=========== What's PREX? a portable real-time operating system for embedded systems.

5-May-2006 10:35
:) Sounds good Pier. I'd love for REBOL to become a language of choice for the MAKE magazine crowd.
Evan Wired
5-May-2006 10:35
:) "Python, Ruby, et. al, designed to pander to the Corporate CIO brainless."

Say what? Someone really doesn't understand either of those languages. REBOL is fun and productive, but there is no one right way for people to program.

14-May-2006 2:29
:) i do wish you coders would make some headway in the rebol /view GUI front end apps department.

if you just spent an hour a day on things like AVC video encoder front ends then everyone would be using and taking about rebol/view and by extension /core.

then youd see a large following away from the likes of ruby etc.

its up to you, eather do it or dont, iv said for a very long time get them hooked on GUI's for the average man and youll get a far greater following everywere....................

15-May-2006 16:23
A week passes without updates to the blog. Another trip to Hawaii perhaps?
3-Jun-2006 14:52
:) well, it seems yet again, interest is lacking.

still, im doing my bit, informing the likes of these professionals that rebol exists, wheres the apps people?. showt...8417#post258417

24-Nov-2006 0:23:50
:) "Python, Ruby, et. al, designed to pander to the Corporate CIO brainless."

I am new to rebol, but I found I cannot use it for scientific research with bad(?) precision, for example >> print sine pi 5.48036651487895E-2

and I don't how to send e-mail thru a server that needs authoriaztion in rebol. Yes, I have searched and downloed esend.r and esmtp.r, but there is no prompt when I use 'esend

So, I have to use python

>>>print math.sin(math.pi) 1.2246063538223773e-016

I like rebol for its small GUI footprint, on the other hand wxpython is some Megabytes. However, rebol can not display/treate Chinese now. So I am looking for the 3.0 version.

27-Nov-2006 8:43:12
Hi oyster,

sine in REBOL accepts input in degrees while sine in python accepts radians and that's probably the source of the confusion.

>> sine/radians pi == 0.0

seems to me more precise than python ;)

4-Jul-2012 9:02:10
There are a lot of blogs and articles out there on this topic, but you have captured another side of the subject. This is good content thank you for sharing it. page link

Post a Comment:

You can post a comment here. Keep it on-topic.


Blog id:



 Note: HTML tags allowed for: b i u li ol ul font p br pre tt blockquote

This is a technical blog related to the above topic. We reserve the right to remove comments that are off-topic, irrelevant links, advertisements, spams, personal attacks, politics, religion, etc.

Updated 23-Nov-2017   -   Copyright Carl Sassenrath   -   WWW.REBOL.COM   -   Edit   -   Blogger Source Code