[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
