[REBOL] Re: What language am I looking for?
From: rishioswal:ya:hoo at: 14-May-2001 1:44
I like the fact that rebol seems to be optimized for
the most frequently done cases while making
unfrequently done things possible. Many language use a
general approach. Take Java for example. As a
programming language, Java's core concept is pretty
clear and concise. But it doesn't seem to have any
bias. Everything in java seems to be equally hard to
do. While this makes complicated things
comprehensible, it also has the side effect of making
simple things ridiculously complicated.
Serialization is one example. Serialization, in java,
is basically a fancy name for saving data from your
program (like preferences) in a file so the next time
you run the program, you can load that file and start
up the program based on data in the file. There are
many steps involved to do this in java...and every
time you need to do it, you forget how you did it
previously and end up looking at the docs and figuring
it out. I was blown away in rebol when serialization
was basically all done with two simple functions:
load and save. You basically save any data to a file
by using save, and you can load that data up in a
format rebol can use using the load function. It's
really easy...and is something i use all the time.
This is just one example...but rebol is filled with
many of these examples...from parse, no operator
precedence (really makes sense!), prototype based
objects, vid, different kind of loops such as foreach
and forall (very cute and surprisingly hand!),series
(this is the best!), etc...
Basically, in rebol, common things are generally
simple to do, and uncommon things are usually
possible, but require thought. It's kind of like
evolution...animals, for instance, evolve not based on
general principals...but based on the most frequently
done task.
regarding your questions on rewriting words...first
off:
1) you can protect all system words (and user defined
words) with a single line of code.
2) this also bothered me in beginning...but i've never
run into an instance where this has become a
problem.In my opinion, it is ok to overwrite words.
Infact, if you overwrite a word with your own word,
chances are that you don't need that particular word
in your program..otherwise you wouldn't have
overwritten it!
3) Once you become proficent with rebol, there are
many ways to prevent this such as using simple
objects.
Regarding having to declare local variables:
At first i would have agreed with you...variables
within a function should be declared local...However,
after using rebol, i feel that the way it is currently
implemented is a better choice. By putting all defined
variables in global namespace, it makes it easy for
beginners to get into the language. Once you are
proficient, it's a no-brainer to make variables
local..you know better..
This brings me to my next point...rebol is really
designed nicely in terms of being a really simple
language for beginners, but providing all the features
for growth as skills increase. It has a really nice
growing curve. This has yet another benefit (in my
opinion):
Rebol is one of the easiest languages to pick up after
you haven't used it in a while! With java, c, c++ and
many other languages, their are all these little
details that, after a break from the language, you
forget. You have to go back to the manuals each time
you want program again after a period of time. Rebol
has very little syntax, no really special variable
declaration features, no confusing/complicated
headers, no unnecessary parenthesis or semicolons, no
required oo programming or function to
start...etc...you can just start off and go...i love
that.
and above all...my favorite thing about rebol is that
it is hands down the most fun language i've ever used.
Sorry for the longwinded english...would have made it
shorter if i had time!
rishi
--- Ken Anthony <[kenneth--nwinet--com]> wrote:
> Great response all (GS Jones, Porter Woodward, Petr
> Krenzelok), thanks.
>
> Scott Jones said:
> >...in my case the emphasis is on providing the most
> > productivity for the least investment of grief,
> time and money.
>
> Absolutely!!!
>
> Porter Woodward said:
> >I would refer you to the following article
> concerning language selection:
> > http://www.paulgraham.com/paulgraham/avg.html
>
> Good article, but in my mind it has a fundamental
> flaw. It's conclusions
> are true only if you accept it's definition of
> power. What they describe as
> power, I think in terms of abstraction and leverage.
> In my mind the term
> power is somewhat ambiguous and leads to some
> confusion.
>
> There the author uses power in the context of
> leveraging programming
> productivity, in which case power equals
> abstraction. Getting the most from
> those 10 lines per day that research keeps telling
> us we are capable of
> (personally, I've had days where I've added a
> thousand lines of code and
> other days where I only modified one word. I
> couldn't guess what my average
> is) I would define as productivity, which I admit
> isn't as sexy as the term
> power, but I think more explicit.
>
> Perhaps I'm just old school, but I have always used
> the term power with
> regard to computer languages to mean both its
> ability to manipulate every
> bit in the hardware and to do it at the very fastest
> speed. So when the
> article says...
>
> >Few would dispute, at least, that high level
> languages are more powerful
> than machine language.
>
> My hand goes up. Now if you replace the work
> powerful with productive then
> my hand goes back to my side.
>
> From the article:
> >"I ll begin with a shockingly controversial
> statement: programming
> >languages vary in power.
>
> Again, translating his term power for productivity;
> I say, what controversy?
> (I think the author was setting up a straw man.)
>
> >The basic argument made by the author is that you
> should always
> >use the most powerful language that you have
> available to program in...
>
> I agree (on both levels); however, my contention is
> that one small language
> (assuming an abstraction level to deal with machine
> dependancies that only
> machine language or it's equivalent can bridge) can
> be that most powerful
> language in most if not all cases. This is my
> central argument, so if I'm
> wrong here, everything else falls apart.
>
> From what I understand, Rebol takes from other
> languages, which I believe is
> exactly the right approach. Which is why I also
> applaud the creation of new
> languages, because they give us new ways of looking
> at things. I however,
> do not want to use or even become conversant in
> every new language out
> there. I'd rather stand on the shoulders of others
> that have that desire.
> All, I want is that the best of these things be
> folded back into the
> language I use in a way that isn't disruptive to the
> use of that language.
>
> Scott Jones said:
> > I think you've already touched on one of the most
> important issues that
> > can affect a project of any significant size:
> scope and namespace.
>
> Joel Neely's posts have been one's I've read with
> considerable interest. A
> work-around is a flaw, IMHO. Giving more thought to
> local variables in
> functions and I find that the syntax...
>
> g: func [a b /local c] []
>
> ...is wonderful. However, I also find what I've
> read about scope a bit
> disconcerting. I apologize for shooting from the
> hip here. I usually
> prefer not to comment on things I don't really
> understand. Perhaps after
> I've played with it a little more I'll have
> something constructive to
> contribute.
>
> Scott Jones said:
> > However, let me urge some caution in what I
> believe you understand that
> > the runtime versions will allow. I do not speak
> from authority, but
> > since others have not addressed this issue, I'll
> at least throw in my
> > understanding. The runtime license allows for the
> creation of a single,
> > executable binary file that will hide your code,
> but I do not believe
> > that it is compiled in the sense of creating a
> binary of machine code
> > nor pseudo-code. If I understand correctly, it is
> merely a form of
> > obfuscation, likely through compression, in the
> same way that one cannot
> > see the large quantities of mezzanine-level REBOL
> code by viewing the
> > REBOL executable file directly (one of the reasons
> that 500 kb of code
> > can do so much). I suspect that there is no true
> performance benefit in
> > creating a runtime. I would ask RT directly about
> that issue.
>
> Hey, if it quacks like a duck... Thanks, the
> enlightenment is appreciated.
> To me, Rebol shows a lot of Forth heritage. Forth
> had the ability to
> produce headless code and I suspect the same could
> be done with Rebol. I
> agree that performance might not improve, but that
> was third on my list. As
> long as the language is capable of it, it becomes
> the programmers task to
> wring the performance out of it. [ok, Petr
> clarified this issue - see
> below]
>
> >In terms of Rapid Application Development of a
> > GUI, it is hard to beat VisualBASIC or Delphi's
> approach, in my opinion.
>
> I agree (which is probably why I have both.) I
> think a rebol RAD/IDE is
> probably essential for it's long term success. But
> it can wait until the
> language has matured some.
>
> > The one other area that might become a gotcha for
> you is shifting to
> > REBOL's method of parsing, as opposed to the
> variations of regular
> > expression matching found in other languages.
>
> This is another area where Rebol is dead on target.
> I love the way they've
> implemented the parser. I think regular expressions
> were developed by guys
> that should go through detox. Step back and
> beautiful things happen. Rebol
> parser is a beautiful thing.
>
> > My only advice (unasked for, I know) is to
> actually implement a small or
> > medium-sized personal project in REBOL before you
> consider tossing it
> > into the bit bin.
>
> Hey Scott, your advise is always welcome. The fact
> is, Rebol is no where
> near the bit bin (or I'd stop spending money on it
> or following this list.)
> As far as vision, where would we all be without it?
>
> Petr Krenzelok said:
> >Hmm, maybe it was done so to keep things "easy"?
> Simply - if you want to
> >define your word local, you have to state it.
>
> You're right Petr, after rethinking I came to the
> same conclusion. The
> syntax is fine, it's the scope question that still
> nags
=== message truncated ===
