Hacker News new | past | comments | ask | show | jobs | submit login

REBOL is very impressive.

My favorite programming language is K, which is super fast, super terse, and completely eschews modern abstraction paradigms like Object Orienter Programming. (Opened a file? get an int selector. Want to define your own data type? Sorry dude, you have to make do with the built in int+double+string+symbol+date+time+list+dict. That kind of spartan). K programs tend to be 10-100 times shorter than the equivalent C++, and of comparable speed.

REBOL is super terse and compact, but it is otherwise the complete opposite: It has tens of built in types (file, money, email, internet address, color), lets you modify its syntax and even encourages that (define new "dialects").

REBOL programs that don't deal with math tend to have comparable length (in term of tokens, not characters) to the equivalent K program, while having abstraction facilities almost on par with LISP. That's quite amazing.

Unfortunately, it is also the complete opposite of K in terms of speed ... It's rather slow.

Both languages clock at a complete implementation (no dependency beyond basic OS) at ~300K while providing quite a bit GUI and some batteries (In the case of K, a full fledged ACID hot-standby order-enhanced relational database; In the case of REBOL, everything you need to do internets including mostly complete mail/ftp/http protocol implementations, sophisticated GUI layout, and a lot more).

My dream language would be something that is fast and terse like K, but has all the REBOL built-ins and abstraction mechanisms. I'm not sure if such a language can exist, or how it would look. But I would like one of those.




Rebol clearly shows its Rexx roots with the battery-included nature. And the SyllableOS actually wanted to use it in a similar manner, sure they're glad that they don't have to clone the language anymore.

But if there's one thing the language needs if it wants to succeed after it became OSS is a good module archive, similar to CPAN/rubygems/PEAR. Not having that for a long while was one nail in the coffin of tcl, especially after web & infrastructure APIs became increasingly important.

I'm looking forward to it. Liked the language, but didn't want to bet on something close-sourced.

Running Rebol on DragonFlyBSD is going to get some Amiga fans a serious case of nostalgia.


>Not having that for a long while was one nail in the coffin of tcl, especially after web & infrastructure APIs became increasingly important.

The ActiveState distribution of Tcl comes with Teacup, FYI. And yes, it would have been nice to have had it back in the '90s.


Tcl improved greatly in recent releases, also burying the "it doesn't look native" argument. But by then the momentum was gone, and it's hard to recapture that. Rebol will have even worse problems, not having the initial userbase of tcl.


It is still used often in test automation, probably because of Expect. I use it to automate database backups, performing ETL while acting as an intermediary between Oracle's sqlplus and MS's bcp as well as for one-off GUI utilities.

It really is a shame it lost out to Perl and Python. The language is so damn pragmatic. Programmers who enjoy snapping together executables in shell will feel at home with Tcl. It functions like a portable shell. Also, Tcl embodies the philosophy of simplicity in implementation better any other software I've encountered; the C API is simplicity itself. It's actually a great way to organize large programs too, just make the commands do more work with C algorithms and data structures and expose less text-output-chatter to Tcl, in other words, make the commands do "big" things and glue them together in Tcl. It's BSD licensed. It has a surprising number of packages due to it being so trivial to convert existing C libraries to Tcl commands using the dead simple API.

I'm surprised more open source OSs (Linux & BSDs) have chosen Ruby, Python, and Perl as opposed to Tcl. Tcl seems like the more consistent extension of the Unix Way.


There was a surprisingly large "enterprise" crowd using Tcl, as it's pretty great for self-contained environments. You have to generate the binding to your own proprietary legacy interfaces anyway, and lots of situations benefit from proper event handling and easy enough GUIs (esp. canvas graphics). And every enterprise GUI looks bad anyway, so complaints about Tcls' L&F were rare.

I think it missed some important opportunities, and was too focused on GUI stuff. And after all, the Perl/Python/Ruby bindings to Tk weren't that bad, either. In the early days of the web, tcl actually was a pretty good option (as a rival to Perl/CGI). And aolserver was pretty neat (still is, I'd say). But then it didn't go with the times, gtk/Qt stole the Unix OSS GUI thunder, RMS ranted against it, lua came along for embedded interpreters, Ousterhout moved around from Sun, to Scriptics to whoknowswhere… It's easy enough to miss your window.

At least it's still more popular than Pike… I wouldn't rule out a small comeback, there aren't any technical reasons against it, it's well maintained, fast, has a very good codebase etc.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: