REBOL 3 Released for AmigaOS

[henrikmk]

Yes rebol can be used to script web pages, like jsp, asp.

And that, is primarily where it is used, if you ask me.

Web projects may be the most visible ones, such as Cheyenne server and QTask, but they are far from the only ones.

There really isn't much point to rebol for generic application development.

Actually that is the whole point of REBOL and I make my money today because I do generic application development in REBOL.

The generic design of REBOL allows it to work on any task, except for high performance calculations, where you would use extensions written in C or other high performance language.
It's also not likely that you would write an operating system in REBOL, but REBOL 3's modular design allows it to sit in more places, such as directly on top of a kernel, which is to become the Wildman project at some time in the future.

What's odd about Rebol is a few years ago, it supported almost every platform available - and that wasn't really important because everyone was using Windows.

The problem was that Carl Sassenrath had set up a development model that dictated that every piece of code, documentation and also maintenance task had to be done and checked by himself. Hence, development slowed to a crawl. The REBOL 3 development model solved this 3 years ago by making the kernel smaller and peripheral code (the hostkit, i.e. how the kernel talks with the OS) was open sourced.

Now, we have this real split in the marketplace, where some are using Android, some using iOS, some using Blackberry, some using WinMo - on their Smartphones, and soon, on their tablets....

and yet now Rebol punks out and doesn't support any of those devices.

Time limitations and also focus on getting the REBOL 3 core completed. It's very complex and a huge amount of work. But the REBOL 3 hostkit already runs on different OSes now, as you can see, and the role of porting is now in the hands of 3rd party developers, where it should occur.

Now I've been an it professional for a couple decades now, I know why it would be difficult to support a platform, when well...Apple is blocking you.   Google maintains control over Android too, despite the impression of being so open.

But - that's the challenge in this world...unfortunately Rebol doesn't solve too many problems, and I love scripting languages, and I agree with a lot of Carl's rhetoric, I just don't believe he's found any great answers.

Even the bill for the old Rebol of being a dialecting language was a bit of a joke, because he  didn't even  understand people speak different languages (talking about spoken languages and their intersection with programming languages)....what's the point in creating dialects, and missing the big picture about differing languages all together.

The point of dialects is not to make something that just is different from the syntax of the language itself for fun. It's to allow a different type of express-ability to simplify what it is you want to do without specifically writing an API. Dialects is something that is not very important in other languages, thus they are either misunderstood or ignored.

Dialects allow greater express-ability and coupling dialects with 56 datatypes, you can express and parse meaningful data in a wholly different way than you would otherwise be able to, when using the standard syntax alone.

But I digress....that dialecting stuff isn't even mentioned a lot anymore, so we can move on from that.

Actually no. Dialecting is one of the big reasons to use REBOL and REBOL 3 extends this a great deal with improved parsing and more dialects.

Without dialects, half of REBOL's design philosophy goes out the window, most of my programs wouldn't work, so we can most certainly not move on from dialects. :-)

[henrikmk]

I've been playing with it a bit, it looks like the Win version on Rebol 3 is still an Alpha release and I think it only operates at the console level. No Gui yet. (If I'm wrong on this, please correct me.)

Rebol 2.7 View (the graphical version) seems to work nicely. I've been messing a bit with it, but haven't had a chance to dig too deep as I'm swamped with other projects.

Regards,
AmigaEd

The windows version is currently the primary platform for REBOL 3 testing, simply because it has the most completed parts. The development is largely split in:

1. Core work (language, booting, modules, extensions), which is done by Carl and expert helpers.
2. The hostkit, which is Carl and the community of a few expert developers (one is Steve Solie), to oversee porting of REBOL 3 to other platforms, while doing code auditing and design changes.
3. GUI work and graphics engine by a third party company, RM Asset, where I work. We want to use the GUI for building viable business applications, so it has to be much stronger than it was for REBOL 2.

The hostkit is what needs to be completed to allow the graphics engine to work on other platforms than Windows, so that's our next big step.

[henrikmk]

However, some of it is not clear to me. For example...

1. What does Rebol 3 bring to the table in terms of aiding the user (as opposed to the developer) that Rebol 2 did not?

REBOL 3 is a from-scratch rewrite. REBOL 3 fixes a ton of small design flaws in REBOL 2 that is observed and collected over 10 years of use. Using more clever designs for many functions, the language overall runs 50-100% faster, although its new bottom-up unicode implementation makes text handling more complex, slower and takes more memory. However it uses less memory in general, due to its more modular design, allowing you to not load parts of REBOL that you don't need.

The graphics handling is much lighter and faster, implemented as a general model of graphical objects (GOBs), which currently is coupled with Anti-Grain Graphics (AGG) as the rasterizer. The coupling can be replaced with an OpenGL rasterization or a different one, if desired.

R2 also had two graphics engines, one for GUI work and AGG for general graphics, like drawing graphs, etc. R3 uses only AGG for everything, so we now have anti-aliased fonts everywhere.

It also implements rich text, which was impossible to do properly in R2.

Ports are totally asynchronous and much simpler, thus allowing much higher performance, which was a weak point in REBOL 2. Where before you had to make use of undocumented async features, these are now documented and standardized.

The modular design allows it to be used inside other programs as a DLL. It has a device model that may allow it to sit directly on top of a kernel without any other OS environment, thus you could theoretically build your own desktop around it. :-)

It also implements multithreading, but this feature is very OS dependent, thus not yet completed and is unstable. Cooperative threading is possible in R2, but it requires hundreds of lines of code and is slower.

Some new core functions allow it to restrict how much memory is used, so it will work better in embedded environments and on webservers like Apache.

It also has an open sourced coupling between OS and REBOL kernel, and also a more open license, which makes developers safer in case REBOL Technologies goes belly up.

There is much more, but this is what I can list for now.

2. Can Rebol be used in implementing a Website? i.e. in other words can it be used as an analog of jsp pages or perhaps similar to Javascript?

Yes and no. It doesn't replace client side javascript, since that is inherently married to the browser, although an experimental plugin was made a few years ago that allowed direct DOM manipulation. It was very interesting to work with in the pre-web2.0 days. :-)

But since R2 lacks certain security features, that R3 has, this plugin was never finished. But server-side, it's a joy to work with and you can write much smaller code than, say, with PHP.

A new plugin may be made later with R3, but I'm not sure.

3. Let's say you have Rebol core running on a server, can it actually serve up dynamic content?

You need a webserver for this, where there are a few available (one is 16 kb of code: http://www.rebol.org/view-script.r?script=volkswebserv.r). The one I use, and is the most popular one, is Cheyenne, which basically consists of an executable and a configuration file.

Then you write pages in .rsp, which is basically REBOL code that can be intermixed with regular HTML code.

On top of this, I wrote an HTML dialect which generates all HTML code for me, so I never have to write any HTML code, and it takes up about 30-50% of the HTML code I would otherwise have to write.

Then there is automatic document generation using REBOL's unofficial MakeDoc standard (similar to LaTeX in philosophy, only vastly simpler in function), and all documents are on-the-fly converted to prettier HTML from plain text files.

My website:

http://97.107.135.89/www.hmkdesign.dk/index.rsp?page=about

I must apologize for it being so slow, as the site is not yet in production mode, because various debugging features are enabled and excessive amounts of code is loaded, every time you view a page. :-)

Also, take a look at QTask, a collaboration website. The entire backbone is implemented in REBOL 2.

4. If it is possible to use Rebol in developing dynamic content, such as an interactive form tied to a database, does there have to be an instance of Rebol View on the client or is a browser plug in required or is the dynamic content presented to the client browser in such a way that nothing else is needed beyond Rebol core residing on the server?

See responses above for clues, but there are not really point-and-click tools available, if you want to build websites in REBOL. Also you would need a host who accepts REBOL to be running, which most standard hosts don't allow, so REBOLers resort to VPS hosts, like Linode, Slicehost or Amazon.

Strictly, if you want to really start from scratch as a fun challenge, you can implement a webserver in a few kb of code and use it to serve basic pages, but it's not asynchronous, and so may be a little easy to knock over without a process manager, like Cheyenne has.

But you can get along just fine without a database, as long as you don't need to serve millions of accounts or gigabytes of data.