rot13

That was a remark that demeaned the author more than anyone else. Perhaps he or she could come forward and make a case for why one should not use rebol? I make a living writing code and I've coded in over a dozen languages. Rebol's the most productive I've found. If I were to write some really crappy perl code and submit it to the perl ML and then leave a remark like that in the code - I'd be flamed so bad whatever hair I've got left would be long gone! Now if I were fluent with either perl or rebol and was able to post an intelligently written piece of code that illustrated some weakness in either language, I would be actually be doing that language and its users a favor, as painful as it might seem....... MTCW (tim '(curmudgeon-in-alaska)) * Joel Neely <[joel--neely--fedex--com]> [031214 11:16]:

-- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com

FWIW, we've gotten this mail a number of times, over a number of years. Fine; submit your significantly nicer implementation and remove the foul stain from your language's honor. This was written at a time that rebol was going through a serious hypefest, so I wanted to check it out. Perhaps I gave it insufficient consideration before judgement; fair enough. Looking back on my implementation, it looks pretty hideous.

Yep, and I appreciate you taking that attitude, considering the affront to your MFTL. I just ask these two things: (and I keep the Cc to rebol-list for this reason, as you aren't the first...) 1) Stop emailing me. I don't care. I evaluated rebol again later, having learned more about similar languages, but I find ruby more suiting to my personal preferences. Email Jay, he maintains the page. (I know he's included in the Cc:) 2) Submit a full implementation, rather than providing hints on a good implementation. I'm sure that Jay will happily put your implementation first on the page, change the description of mine to ``a clumsy implementation'', or whatever you like. Cheers. (hoping to never have to hear about this again, and hoping to meet people under friendlier circumstances than language wars.) -- Julian Squires ----- End forwarded message ----- -- Julian Squires

Neither does my partner. He loves perl and will program in nothing else. No matter. He delivers, and delivers thoroughly. On the other hand, I'm a faithful husband and a promiscuous programmer. I love the variety of programming languages available, and knowing more than one informs me in all. Many people hate mutt and vim. I favor them both. [tim [studying-lisp]] -- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com

I'll be glad to forward it.

Actually, I'm a bit of a polyglot myself (mostly Perl and Java for work, still dabbling at Python, bought Dave & Andy's Ruby book but haven't had time to invest in serious reading/playing.) I get very interested in seeing how mental models of various languages shape (or at least influence) one's design and coding, and would likely have spent more time on Python had it been around when I decided to learn Perl.

Happy holidays (and I'll try to point a cold fire-hose at some of the flamers! ;-) -jn-

In the interest in some friendly discussion, I guess I'll answer this. First, to be fair, some things I like about rebol: - very obvious influence from both lisp and forth, both of which are interesting, complementary languages. (this covers a lot of aspects of the language and its distribution) - prototype-based OO, like self. - the syntax elements are relatively orthogonal. - the way that evaluation is structured so as to make it unnecessary to have a fancy macro system is neat, although I don't fully know the ins and outs of it so I'm not sure exactly how it stacks up against CL, or scheme. Meanwhile, the following are some utterly subjective reasons, off the top of my head, why I still do not use rebol: (and, it should be noted, some of these may spring out of ignorance, or just that I'm feeling tired today.) - no open source compiler for the language, it seems, and the language appears to be controlled by a single company. (a negative to me, no matter how good-willed the employees of that company) - a lot of things seem magic (as with perl), and the line between the language, its libraries, and its necessary runtime support is very unclear (also a fault, to some extent, of both forth and lisp). A specific example of the above that bugs me is that operators and functions behave differently (and you don't seem to be able to define infix functions). Another one is that, while all these magic datatypes are certainly handy, how do I define my own, with their own behavior, or override existing behavior? (perhaps this is a fault of the documentation, which I've just skimmed over again to make sure I'm not missing out.) - I don't like the way it looks and feels, personally... it's as if John McCarthy invented COBOL in some parallel universe. I find it can be a bit hard to read while trying to remember exactly the order in which the elements of a complicated statement are evaluated. (not that those rules are complicated) - it doesn't seem to do anything that my existing languages don't do. While there is always the danger of the blub paradox here, I guess what I'm saying is -- no type inference, no extension of the base types at runtime, not obviously easily embedded into an application written in another language, no clearly defined FFI, et cetera. This isn't to say those things are necessary, but it means that I don't see a compelling reason for me to use rebol. (this is where you come in ;-) ... not that I'm actually looking for reasons to use it.)

That's great. I think the worst thing in our industry is that people are unwilling to explore new languages, and see that they can greatly improve productivity. My personal current high-productivity languages would have to be common lisp and caml for big/fast things, and ruby for small things. And, I hope that the answer won't be the same in five or six years. Maybe it will even include rebol. Cheers. -- Julian Squires

Yes, it is observable, that Rebol has inherited some advantages of both languages.

This may be a matter of personal preferences. I like it too, but some users prefer a class-based approach. It may be "mimicked" to some extent.

Agreement here.

This is the true innovation. It brings the feature its author calls dialecting . Without it Rebol wouldn't be as malleable and appealing as it is.

This can be called and "utterly subjective" reason. It ceases to be true these days, because there are open source projects cloning language features.

I take is as an overall description of the things detailed below.

Yes, the behaviour of operators differs from the behaviour of the (prefix) functions. Although there isn't a way to define your own infix operators yet, this can be easily fixed in the future. I would say, that infix operators are there to allow programmers to use the "ordinary" formulas. For more andvanced uses you can always switch to prefix notation and do whatever you like.

You are not missing out, the mechanism for defining your own datatypes isn't there. You can only define new kinds of objects. There are three aspects of user datatypes: 1) in other languages datatypes "protect" their internal attributes. Rebol by design doesn't protect internal attributes of datatypes - e.g. native functions are mutable in Rebol, which may not always be considered an advantage. This is advocated as an "orthogonality". (you can inspect/change virtually any "complicated" value) 2) Rebol actions (native functions operating on values of different datatypes) should be extended for every new user datatype. This looks like a hard task for a user and that may be the reason, why the language designer didn't want to allow it. 3) the type-checking mechanism has to change to allow new datatypes.

This is a subjective statement, hard to comment on.

From the "computational completeness" POV clearly true. OTOH, there isn't another language with the built-in dialecting ability. The dialecting ability is a feature, that is more general and useful, than the ability to define new user datatypes or operators. (it is an ability to define completely new "sublanguages")

Fairly stated :-), see my comment above.

Cheers -Ladislav