[REBOL] Re: What language am I looking for?
From: kenneth:nwinet at: 13-May-2001 14:04
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 at me.
> Or use the 'use block, or create separate 'context ...
This I'll have to give more thought to.
>> Another thing that bothers me is that redefining a word should be
explicit.
>OK, maybe Rebol modules system, as it was planned (but nowadays RT is
silent
>about it), will cover your needs. But also remember - the main rebol
concept
>is - "series" - learn more about series and maybe things will be a little
bit
>cleaner for you .. (http://www.rebolforces.com/series.html by Ladislav
Mecir)
Good advise. This is a fundament language design issue. Being honest, I'd
have to say I don't quite understand how series and scope relate. But
however they relate, the issue of redefining a word when not meaning to
still exists (I think?)
>>...project has about 700,000 lines...
>I am not sure Rebol is ready to handle it. We miss components.
An interesting side point: That particular application hardly uses any
components and could very well have used none. Not my decision to use such
brute force, but hey, I'm just riding this train (and yes, I feel the
crosshairs on my back should it jump the track. I'm the only one left of
the original design team and I was a junior member. The others couldn't be
bothered with maintaining what they helped create and are long gone. I've
spent almost a whole year fixing one particular gift that the lead
automagically added to every form in the project one week before he left.)
It's so much easier to add things than it is to remove them. Their is a
real danger in adding things without enough thought. So I hope whatever
Rebol does in regard to components is done carefully. I'm certainly willing
to wait (it will end up saving me a lot more time in the long run.)
I understand the cross platform issues and so I appreciate the caution.
>c) if rebol.exe grows to some over 1.44 MB, it will be bad :-)
Is that still true anymore? I would agree that keeping it down to diskette
size has advantages.
>One other thing - RT code is not compilable - so no speed-up, sorry. Using
>rebol runtime will allow you to hide your sources, but that's all - no
speed-up
As I've said before, speed up is not my main concern. As long as it's no
slower than fast enough not to be perceived as slow (uh, did I just say
that?) In my mind, speed is mostly a marketing issue. I keep my computer
scientist hat on a hook until I'm in play mode.
Ok, now I turn the floor back over to my esteemed fellow Rebolutionaries,
Ken.
