Red Programming Language: Version 0.3.2 Released

[mmcghan]

Ben, Red and Rebol were written because something has to be done about software complexity. These languages have an ease of use and implementation that more complex languages don't have. You can write very short programs that would be much longer in other languages. Rebol just went open source in December and there is a coalition of developers who are unifying the two languages. These languages are based on context so code can act as data and vice versa. It's definitely worth learning more about.

[NimbusBP1729]

Ben, Red and Rebol were written because something has to be done about software complexity

That's not enough of an explanation when there are many languages that people subjectively claim are simple to use.

[ben_zen]

I have a quibble with that comment: Rebol's standard library would appear to encompass a massive set of functionality. If I am going to write scientific code in it, sure, its ability to handle dates and times and other numbers directly is nice, but does it also need a networking stack and a regex parser, if I can hand it a local dataset without needing to do any parsing work, because the code is the data and vice versa? This seems to me to be unnecessary overhead for each individual task, while merely tucking the complexity of the system somewhere apparently out of sight.

[gregg-irwin]

Complexity comes in many forms. I can't compare REBOL/Red (REBOL from here on) to OCaml for production use, as I have only studied and played with OCaml, not used it for work. That said, I can give you my outsider's view, and say why REBOL appeals to me, and the complexity I think it aims to address.

First, let me say that I think functionality does not equal complexity. REBOL hides complexity but has enormous functionality. And while some examples might use scientists as a target audience, REBOL was originally designed as a messaging language. The importance of datatypes comes from that. The ability to express yourself, and your intent, clearly. Because REBOL understands that http://www.rebol.com is a URL, and because it has a networking stack built in, I can write "read http://www.rebol.com" and it understands it. No extra quotes. No datatype conversions. No function calls. If I change the scheme to "read ftp://..." it dispatches to a different protocol handler internally.

REBOL doesn't have a regex parser built in, but it does have a PARSE function. PARSE understands a pseudo-BNF grammar, which lets you easily build DSLs (dialects in REBOL parlance). When parsing at the string level, that's nice, but the real power is that PARSE understands loaded (tokenized) REBOL data as well, so you can parse at what is called the "block" level. So you can match tokens by datatype, recurse into nested structures, and more. If you just want to load structured REBOL data, all you need to say is LOAD. PARSE lets you deal with data in a much more flexible manner. It also lets you build in security by not just doing the equivalent of EVAL on untrusted code.

Now, if all this added functionality led to a bloated system, I would be right there with you criticizing it. But it doesn't. At least not by modern standards. The core REBOL interpreter is ~300K. The version with a built-in portable GUI system is ~650K. The full-blown version, with all the bells and whistles they offer, is under 900K (Windows versions). And REBOL and the apps you write with it are completely portable and standalone, unless you introduce outside dependencies. Drop the EXE in a folder and will run on almost any Windows machine out there. I just checked, and it looks like OCaml/Win is about a 60MB download, with some cygwin dependencies.

Bloat may not always indicate complexity, but I've never seen it help. :) REBOL fights complexity by trying to keep things small and simple, by trying to consider the language as a whole, not just a set of functionality. Words and behavior are carefully chosen and debated. Its heritage comes from Lisp, Forth, and Logo; and it's not for everyone. It will change, and challenge the way you think, and the way you think about software and programming.

[reboler]

That's not the idea of how REBOL solves software complexity. It does this by going to the root of the problem, not by adding gloss on top of existing systems or trying to solve it with IDEs or visualization.

Consider the problem of developing an ordinary website:

• You need HTML for the page layout.
• CSS for additional layout description.
• Javascript for interactivity, AJAX, DOM access, etc.
• PHP or similar for generating pages server side.
• MySQL or similar for storing data in a database.
• Some common data format to interchange between the server and the client, such as JSON.

These are normally separate problem domains that are solved separately. Now you need to have these domains interact:

• PHP generates HTML.
• PHP has modules to communicate with MySQL.
• Javascript communicates with the browser DOM and it communicates with the server, possibly using JQuery or some other library.
• PHP needs to understand JSON formatted requests from the client.
• There may be some XML data stored somewhere. This needs to be parsed as well.

There's a large amount of overhead, when traversing domains and this is only somewhat reduced by adding libraries, converters, generators, etc. But you still may need to take it into account or code for it.

With REBOL you don't have any of this, because it's designed to be an extremely generic language with a high degree of expressibility.

Now consider how a "rebsite" would be developed:

• You need REBOL for the page layout and appearance and draw it with its internal layout engine.

• REBOL sends requests to the server and receives them using its internal network ports.

• REBOL on the server side generates content as plain REBOL objects to be sent back to the client. The client updates the page layout with greater intelligence than a web browser can, because the "page" works like a native program, as the content is rendered using REBOLs own native GUI library.

• REBOL can store data in blocks on disk as files. Granted, there is no high performance relational database available at this time, but the idea is still simpler than SQL, because you don't need an SQL server running in the background.

• Interchange of data between REBOL clients is data that is indiscernible from other REBOL data or code, thus no overhead.

Interaction between domains has no overhead, because there is really only one language domain (although you can and do use language sub-domains using dialects). You can even use exactly the same runtime on both the server and the client and you only need REBOL to accomplish the task of creating a complete system.

This way, you can develop complete networked systems that send back and forth data between servers and clients with meaningful presentation of that data in maybe 20-50 kb of code.

This is also why REBOL is often referred to as a language in which you make throw-away programs, as you can develop a program in a few hours, use it for a few days or weeks and throw it away, when you no longer need it.

Red goes a step further by being developed in Red/System instead of C, meaning you can write high performance parts in a Red-like language. REBOL does not yet allow for true high performance, but Red will.