Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: rot13

From: lmecir:mbox:vol:cz at: 15-Dec-2003 9:32

Hi Julian, thank you for taking time to discuss the things. Some opinions are well informed:
>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) >
Yes, it is observable, that Rebol has inherited some advantages of both languages.
> - prototype-based OO, like self. >
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.
> - the syntax elements are relatively orthogonal. >
Agreement here.
> - 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. >
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.
>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) >
This can be called and "utterly subjective" reason. It ceases to be true these days, because there are open source projects cloning language features.
> - 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). >
I take is as an overall description of the things detailed below.
> 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). >
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.
> 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.) >
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.
> - 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) >
This is a subjective statement, hard to comment on.
> - it doesn't seem to do anything that my existing languages don't do. >
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")
> 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.) >
Fairly stated :-), see my comment above.
>>I make a living writing code and I've coded in over >>a dozen languages. Rebol's the most productive I've >>found. >> >> > >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. >
Cheers -Ladislav