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 largedoes 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.
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 ...
Edoc 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.
maarten 4-May-2006 18:20
I thoink you forgot...
0: Leverage. One executable, small and self-contained, easy deployment.
Edoc 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.
Edoc 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.
Goldevil 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".
Edoc 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:
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.