What language am I looking for?
[1/51] from: kenneth::nwinet::com at: 12-May-2001 21:13
Hi all,
I've spent too much money and a large percentage of time in the past quarter
century (since that old HP2000F time-shared BASIC, back in high school)
looking for a language that would meet my needs. Although I've used dozens
of different languages over the years, I have always rejected the idea that
I couldn't find one with both the depth and breadth to do what I ask of it.
So the quest for the perfect language, described in the first section of the
forward in the book, "Rebol: The Official Guide," strikes close to home for
me as well as for others I'm sure. It doesn't need to be perfect either,
just close enough that I can enjoy working with it without always bumping
into it's limitations. Anyway, while I admit I haven't given it the chance
yet, my intuition tells me Rebol is not the end of my search, but I'm
willing to be convinced otherwise. So I would seriously and sincerely
appreciate whatever comments this group has to offer.
I'm not interested in language as a religion. I have two uses for a
language, to get work done, and for recreation. When I can't actually get
work done with it, I tend to lose interest in it as a hobby.
Before I mention the things that bother me about Rebol, it might help if I
say what has drawn me to it. This is my second look at Rebol, I downloaded
it a few years back. I didn't stick with it then because the timing just
wasn't right. I was involved in a steep development phase of a project and
couldn't afford the distraction. But I didn't forget it was there and one
day I typed in www.rebol.com to see if the page had gone away (as I'd seen
with other languages in the past.)
It's the little things that count, like using square brackets to begin and
end a block. [] seems so obviously right to me. It may seem odd to some,
and I really wouldn't want to argue the position, but I am more impressed by
that than all the cool one liners I've seen (APL had a lot of great one
liners, but where is it today?)
The language needs to fade into the background when programming and that
only happens when the syntax is wisely chosen.
If your shocked at that, my response would be, "Hey, I'm a programmer.
Within reason, as long as the language gives me the tools to express my
thoughts; I don't care if it's done in one line or five. I'm going to
reduce it to one word anyway." Please, no arrows, I understand the value of
a succinct expression. I just don't put it as the highest item on my list.
The highest item on MY list is, can I do that? (With a minimum of grief.)
I've tasted the power of machine language but I understand why we don't all
use it. Safety isn't the issue, productivity and hardware abstraction are
the issues. Safety is something that should be handled at the operating
system level, that it isn't is appalling.
I've followed the discussion of scope with regard to Rebol with some
concern. The idea that variables that are all static and global does not
give me the warm fuzzies (or that you have to declare variables local in a
function. Just the act of declaring them should make them local.)
Another thing that bothers me is that redefining a word should be explicit.
If I have to remember every word in an application before adding another
then that is placing a burden on me that computers were made to carry. It
would be fine if there was an "Option Explicit", but protect and unprotect
misses the point.
I'm a VB programmer these days because that's the language the project was
written in when I joined my present employer. We do have to use C where
it's the only option, although I personally haven't touched the language in
years. The project has about 700,000 lines and hits a database with over a
hundred tables. I need to be able to write this kind of application in my
language of choice.
I need to be able to compile my application. That means should I choose
Rebol, I'm going to need to pony up the $800 for the unlimited license.
Anything less is to admit that Rebol is a hobbyists toy. I need to be able
to compile for two or three reasons; for ease of distribution, to protect my
source (you'd be surprised at my position on open source but now's not the
time for that discussion) and also performance. Although I take an
engineers view of performance which is that as long as it makes spec. it's
good enough (usually, it's not or the spec. lacks a certain imagination for
how hard an application is going to be hit.)
While I'm impressed with the self documenting features of Rebol, what
happens to all that documentation in a compile? Is it contained within?
The compiler should remove it.
Which brings us back to that highest item on my list. As an example, if the
layout dialect didn't exist, could I write it myself in Rebol or would I
have to go begging RT to include the feature in a new version? What other
things do I need that are not included? How do I create a new widget that
isn't already provided for me?
Please don't direct me to some other favorite language or yours, I'm asking
about Rebol. I've already got my copy of Delphi 5 Pro that I paid for and
never used.
I don't post much, which considering how long winded and opinionated I am is
probably a good thing! ;-)
But you do have my grateful acknowledgement for any of your replies.
Thanks,
Ken.
[2/51] from: dean:clockwork-technologies:ab:ca at: 13-May-2001 0:53
For me, the eternal quest has always been "What languages (plural) am I looking for?"
As a
programmer, I've used more languages than I can keep track of myself, from various dialects
of
Assembler to 4GLs, and everything in between, and I am convinced that no one language,
not even
REBOL, is the magic bullet that will replace all else.
I've spent only a short time working with REBOL, but can definitely see a place for it
in my toolbox.
Here's my concrete example: My current employer (I am a contractor) is in the midst
of getting rid of
their old, underpowered mainframe and replacing it with a sleek new Sun box. Our current
slate of
COBOL programs is being re-compiled to work on the new platform. I connect to both the
mainframe
and the Sun through my desktop PC, which runs Windows NT. The mainframe and the new
Sun box
do not directly speak to one another.
Because the systems are isolated from one another, testing is a chore. Steps are: 1)
Run a slate of
programs on the mainframe. 2) Copy the data files from the mainframe to my PC (via Windows
FTP --
yuck). 3) Copy the same files from my PC to the Sun box. 4) Run the same test slate
on the Sun.
Using my PC as a way-station is most annoying. REBOL, however, allows me to essentially
copy
directly from the mainframe to the Sun box, and compresses steps 2 and 3 into a single,
more
homogenous step. The script took all of 10 minutes to write and is extremely fast to
run. Yes, yes, I
realise that my PC is still a way station, but using a REBOL script makes the whole transfer
process
much more invisible.
>From what I've seen, REBOL excels in situations where files are spread across a network,
but still
need to be easily accessed. The built in protocols (FTP, HTTP, POP, etc) really help
to make a
heterogeneous network much simpler to work with. The other strength lies in the fact
that it's scripted,
not compiled. For the numerous quick and dirty jobs I need to do, scripting languages
simply make
more sense than ones I need to compile. I can write the script, run it, and then throw
it away if I know
I'll never need it again. Simplicity itself. I'd certainly write REBOL scripts over,
say Perl scripts any
day.
Does all of this mean I'm going to throw away my beloved Smalltalk compiler? Hardly.
Would I go to
my employer and suggest that they rewrite their current COBOL applications in REBOL?
Not in this
lifetime! If anyone were to ask me what language I would use to write a large business
system, I'd say
COBOL, every time. If someone were then to ask me what language they should use to manipulate
and share files across a networked environment, I'd certainly mention REBOL. Ask me
about some
other situation, and I might well say that Smalltalk is by far the best choice.
Every language has its purpose. For me, the better question is: Does REBOL fit in your
toolkit? From
what little I've used, it certainly fits in mine.
This was rather longer than I had hoped. Sorry, all...
Regards,
Dean Powell
Edmonton, Canada
Original message from: "Ken Anthony"
[3/51] from: kenneth:nwinet at: 13-May-2001 2:01
Thank you for your thoughtful response Dean,
Dean Powell said:
> For me, the eternal quest has always been "What languages (plural) am I
looking for?"
You described a programming language as being a tool in your toolbox which
is certainly a useful metaphore. OTOH, Carl himself (and correct me if I'm
wrong) likens Rebol to a natural language. There's the concept of dialects
which I haven't fully grokked and that's ok. I don't know any mortal that
understands all the dialects of a spoken language either, but that doesn't
seem to limit us.
People see Rebol as a cool networking language, but is that all it is? The
English language is expressive and malleable; it has adapted to whatever
people throw at it. I'm sure this is true of other spoken languages as
well, my fiancee speaks several languages, but I find that one spoken
language suits me fine.
Although no example may exist, I still reject the status quo, which is that
one language can not fill my needs. Of course I'm not going to rewrite a
legacy system, but that's not the point. Starting today, could I use this
language to do all the things I want to do? In the late 70's I thought
Forth might fit the bill. It didn't. If you imagine me tilting at
windmills, well... perhaps you have an insight into my soul. Somehow the
object of my search seems to be just outside my grasp.
> Every language has its purpose. For me, the better question is: Does
REBOL fit in your toolkit?
Yes for you there is a better question, but I don't think it takes anything
away from my question... What language am I looking for?
I enjoyed reading your post,
Ken.
[4/51] from: woodward:shore at: 13-May-2001 11:14
Hey -
I would refer you to the following article concerning language selection:
http://www.paulgraham.com/paulgraham/avg.html
Basically it describes how the Yahoo Store system was built - primarilly
in LISP! The basic argument made by the author is that you should always
use the most powerful language that you have available to program in...
The major feature that he cites for LISPs power is it's macro capability -
in other words it's ability to write code for you.
To quote the author:
I ll begin with a shockingly controversial statement: programming
languages vary in power.
...
Everyone knows it s a mistake to write your whole program by hand in
machine language.What s less often understood is that there is a more
general principle here:that if you have a choice of several languages,it
is,all other things being equal,a mistake to program in anything but the
most powerful one.
I would argue that REBOL is as powerful as LISP - maybe not as mature, but
certainly as powerful. In any case it makes for an interesting read. I'm
not sure that I agree that LISP is the most powerful language available -
it really depends on what you're going to be doing. If I want to write a
device driver, LISP would be worse than anemic for that kind of task. C
would be a much more powerful choice. Languages vary in power - depending
on the context in which they are used.
- Porter
//\[Woodward--shore--net] - finger [woodward--shore--net] for PGP key.
// \http://www3.shore.net/~woodward/
\\ //----\Out of sorts? Heck, I'm out of most algorithms.
\X/ \MiGA - Make up your own mind. "Spoon!"
In a world without fences, who needs Gates?
[5/51] from: gjones05:mail:orion at: 13-May-2001 10:11
Hi, Ken,
Thanks for taking the time to write such an articulate letter of query.
If I had your skills of articulation, I would probably become a writer!
We share similar roots (time-shared BASIC back in high school in the
early seventies for me on a teletype machine -- oh, I still remember the
heart-pounding pace of Star Trek through a 300 baud modem and the
teletype ;-), but my career training took a different trek. As a
self-described "advanced hobbyist", I've been on a similar search for
the right language, but in my case the emphasis is on providing the most
productivity for the least investment of grief, time and money.
I'm not feeling particularly evangelical this morning, so no sales
pitches will be forthcoming. After overcoming the inevitable paradigm
shifts required in trying any new language, I suspect that a language
will sell itself to those who can efficiently reach maximum expressivity
for the tasks undertaken. But I can address a few of the
questions/issues raised in your message.
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.While
the appropriate work-around has been clearly explained in the other
message thread, I have to "pitch in" with Joel Neely that this approach
seems disconcerting in a language that promotes itself for making easy
things easy and for following the principle of least surprise. Open
source languages allow the community to assess the inner workings that
explain language behavior and to more readily assess alternative
approaches that might appeal to the larger community. But I must give
Rebol Technologies credit for being extremely response to the opinions
expressed by the community, especially give their relatively small
development team.
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.
VID is the dialect that RT has provided that allows for the easy
programming of gui's. What seems to be no longer stressed, is that VID
is just one implementation of the /View interface, accessible through
the 'face object. If a picture is worth a thousand words, the Doc
Kimbel demo on a "Windows Skin" for /View will quickly demonstrate what
can be accomplished outside of VID. I've not tinkered with this aspect,
because VID or derivations thereof have largely met my needs, but I
found some comfort in knowing that with some additional effort, it is
possible to implement totally new 'face styles. As a side note, I have
found the VID to be more approachable than Tk that is found in numerous
other languages, but I suspect that that, too, is largely a reflection
of personal preference. In terms of Rapid Application Development of a
GUI, it is hard to beat VisualBASIC or Delphi's approach, in my opinion.
I have become quite proficient in REBOL VID in a surprisingly short time
(it took about a week of immersion in REBOL and REBOL VID to feel
comfortable in both).
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. Like VID, it is a dialect
that requires a little time for familiarity to grow. I'm not proficient
in either approach, but my glimpses suggest that there is more room for
easy extension of REBOL's parse. I suspect that it would be easier to
emulate the regexp found in Tcl, than for regexp to emulate REBOL's
parse, but this is just a guess.
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. Like most, I suspect that you will be surprised, and
like many, you may just get addicted. Final warning, this language has
not been evaluated by the US Food and Drug Administration for routine
use; as with all products, there may be a potential for addiction!
Good luck with your language "vision quest." Maybe you and Carl
Sassenrath can co-author the "The Hitchhiker's Guide to the Programming
Language Universe". Hey, maybe I should write that book --- dibs!
With regards,
--Scott Jones
Original submission from: "Ken Anthony"
[6/51] from: petr:krenzelok:trz:cz at: 13-May-2001 17:23
----- Original Message -----
From: "Ken Anthony" <[kenneth--nwinet--com]>
To: <[rebol-list--rebol--com]>
Sent: Sunday, May 13, 2001 6:13 AM
Subject: [REBOL] What language am I looking for?
> Hi all,
> I've followed the discussion of scope with regard to Rebol with some
> concern. The idea that variables that are all static and global does not
> give me the warm fuzzies (or that you have to declare variables local in a
> function. Just the act of declaring them should make them local.)
Hmm, maybe it was done so to keep things "easy"? Simply - if you want to
define your word local, you have to state it. Or use the 'use block, or
create separate 'context ...
> Another thing that bothers me is that redefining a word should be
explicit.
> If I have to remember every word in an application before adding another
> then that is placing a burden on me that computers were made to carry. It
> would be fine if there was an "Option Explicit", but protect and unprotect
> misses the point.
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" - lear more about series and maybe things will be a little bit
cleaner for you .. (http://www.rebolforces.com/series.html by Ladislav
Mecir)
> I'm a VB programmer these days because that's the language the project was
> written in when I joined my present employer. We do have to use C where
> it's the only option, although I personally haven't touched the language
in
> years. The project has about 700,000 lines and hits a database with over
a
> hundred tables. I need to be able to write this kind of application in my
> language of choice.
I am not sure Rebol is ready to handle it. We miss components. Rebol chosed
to finisn many of usefull functionality first, instead of finishing main
language concepts first - one of them being run-time dynamic components. We
currently have several rebol products, and sometimes RT doesn't want to
inculde feature x or y, because rebol executable size would grow fast. Once
components will come, it will allow
a) per component pricing
b) one kernel thru all rebol apps, which in turn means that change in
component doesn't require you to update/download all your rebol product.
c) if rebol.exe grows to some over 1.44 MB, it will be bad :-), while it
would not look so drastic, if separate math, sound, streaming media etc.
took 500KB each.
You will surely miss rebol data browser, which I am thinking about to write
(no free time yet), as I don't find scrolling lists the way to go, while
they are usefull in most cases. We need strong columnar data browser, with
abstracted data connectivity API, caching, etc., so only visible data +
cached data are in memory. Long lists make rebol app resource hungry beast
...
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
BUT - on the other hand - bear in mind that RT provides us with library
component, so you can put your heavy stuff into library, but you probably
lose some of multiplatform advantages, but with clever app design (isolated
layers) it should not be much of a problem ...
But - rebol is young ... and ... rebol is cool. We all hope many things
will come (e.g. modules, components, async. networking protocols, maybe
threading). Rebol also stil waits for killer app to appear. :-)
Cheers,
-pekr-
[7/51] from: gjones05:mail:orion at: 13-May-2001 11:46
From: "Porter Woodward"
> I would refer you to the following article concerning language
selection:
> http://www.paulgraham.com/paulgraham/avg.html
<snip>
That is an interesting read. Thanks for the contributed link.
--Scott Jones
[8/51] 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
<<quoted lines omitted: 8>>
> 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.
[9/51] from: rishioswal:yaho:o 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.
<<quoted lines omitted: 171>>
> syntax is fine, it's the scope question that still
> nags
=== message truncated ===
[10/51] from: tim:johnsons-web at: 13-May-2001 22:35
On Sat, May 12, 2001 at 09:13:27PM -0700, Ken Anthony wrote:
<snip>
> But you do have my grateful acknowledgement for any of your replies.
>
I program in C, C++, rebol, python, VBA and Assembler. Have also done
commercial work in dBaseIII, and studied Pascal, Cobol, Vax Basic.
All things being equal, rebol is my favorite, however things aren't
always equal. <sigh>
For a small-scale CGI application, rebol would be my first choice:
IF my client found that acceptable, and most of my clients don't care.
I designed an online course (first semester : high-school freshman/sophomore
level) using rebol as the medium for an introduction to programming.
I rewrote one of my small projects (600 record database/15 fields) which
was originally done in C++. It took about a third of the time as
the "C++" edition.
I'm currently setting up a server written in Object-Oriented Ansi C.
I'll probably use several small rebol clients with it.
I would prefer that words like "elegant" and "powerful" be eliminated
from any conversation about computer programming languages. They
mean nothing to me.
I agree with pekr in that rebol has much maturing to do (and will do).
Given the increase of processor speeds, and the increasing legacy
of rebol code, along with the above-mention maturation,
I believe rebol may be the flagship language of the future.
--
Tim Johnson <[tim--johnsons-web--com]>
"My shroe, my shroe, my dingkom for a shroe!"
--TheManWhoSpeaksInAnagrams (Monty Python)
[11/51] from: joel:neely:fedex at: 14-May-2001 22:31
Hi, Dean,
Dean Powell wrote:
> ... I connect to both the mainframe and the Sun through my desktop
> PC, which runs Windows NT. The mainframe and the new Sun box do not
<<quoted lines omitted: 9>>
> station, but using a REBOL script makes the whole transfer process
> much more invisible.
Having played "shove the bits around the intranet" game myself,
I must admit you've got me curious. If you're using FTP to glom the
files from the mainframe to the PC, I would assume that the
mainframe
supports TCP/IP. Is your PC using two NICs to connect to two other-
wise unconnected networks? If not, why couldn't you put REBOL on
the
Sun box and grab the files directly?
Just wondering...
(And I do agree that REBOL can be a very nice tool for just the sort
of rawhide-cattle-drive bit-pushing you've described.)
-jn-
[12/51] from: kenneth:nwinet at: 14-May-2001 21:07
Hi,
The lever is my favorite analogy; all machines are levers. Which begs the
question: so what kind of leverage does a computer provide and what is the
best way to take advantage of it?
Rishi Oswal said:
> load and save ...<snip>... It's really easy
Yes, because the data type contains the missing information that otherwise
would require parameters. It's brilliant.
It takes the burden off the programmer (less to remember) so the
programmer's brilliance can be focused on what it should be focused on.
>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!
Yes it is ok, but does it put more or less burden on the programmer? You
used the expression 'chances are.' Isn't that the thing you want to avoid
when writing code (given how literal computers tend to be?) Unforetunately,
every solution I come up with this problem carries it's own burdens or is
just plain ugly...
Here's an example of what I mean... If we change the default to no
reassignment we could use another symbol for explicit reassignment.
word: [to assign]
word:: [to reassign]
But I've always found double colons to be ugly. Any thoughts?
> Rebol is one of the easiest languages to pick up after
> you haven't used it in a while!
I believe this to be an extremely profound statement. It says something
about the essense of the language. The rightness of it. This is a quality
of natural language.
> the most fun language i've ever used.
Thanks Rishi, if it wasn't fun, they couldn't pay me enough to do it!
[13/51] from: joel:neely:fedex at: 14-May-2001 23:17
Hi, Ken and everyone else,
Having been out of town a couple of days, let me belatedly add
my $0.02.
Ken Anthony wrote:
>... Although I've used dozens of different languages over the
> years, I have always rejected the idea that I couldn't find
> one with both the depth and breadth to do what I ask of it...
>
You're certainly entitled to your quest, "to follow that star..."
(Oops. About to break into song there. ;-) Seriously, good luck!
If you ever find that ideal language, please let me know!
My experience has been that I ask my computers to do so many very
diverse things that I'm better off using different languages for
different tasks. The last two major efforts (of which I'm aware)
aimed at building one-size-fits all languages produced PL/1 and
ADA, and I don't know of very many people that even *use* either
of those, much less regard them as "final solutions".
Finally, the reason I regard this quest as a "never-ending story"
(I can't seem to avoid literary allusions tonight ;-) is that we
(the human race in general) are still learning what to do with
computers. A significant part of my programming concerns daily
applications of concepts that didn't even exist (or barely
existed as laboratory exercises) when I was in graduate school.
As we learn how to do more, and think of new things to do with
our digital toys, we'll continue to have new ideas for how to
conceive of what we're doing -- *and* how to express those ideas
to ourselves and our gadgets.
OK. Enough soap box.
What I *can* tell you is what I think REBOL is good for. You
can decide for yourself whether those things are central enough
to your interests to give you a return on the effort of learning
REBOL.
> ... I have two uses for a language, to get work done, and for
> recreation. When I can't actually get work done with it, I
> tend to lose interest in it as a hobby.
>
I have quite a bit of difficulty distinguishing between work and
play myself! ;-)
> ... It's the little things that count, like using square brackets
> to begin and end a block. [] seems so obviously right to me.
>
The first not-so-little neat feature of REBOL is that blocks are
just blocks, neither exclusively code nor exclusively data. This
opens up a whole world of expressive power. (Incidentally, that
is the sense in which I use the word "power", as almost synonymous
with "expressivity". The ability to twiddle bits and flog registers
at the bare metal level is just speed. ;-)
The next big strength of REBOL is platform-neutrality. I've moved
the same scripts (some useful web-site-generation tricks) among w95,
MacOS, Solaris, HP-UX, Linux, and w2K, with nary a platform glitch.
I can work on it anywhere and it works anywhere.
The specific things that pushed me over the edge into using REBOL
regularly were the built-in (albeit primitive) XML parser and the
rich suite of network support features. One of the first things I
wrote in REBOL was a web-server stress-tester. I've used XML as a
configuration file format for many REBOL-based projects, and found
that to be very useful.
With regard to parsing, the best quick summary I can give is to
think of the PARSE dialect as extended BNF, and forget you ever
heard of regular expressions. (I happen to like regular
expressions,
and in fact use Perl quite often -- put that tomato down, Ralph! --
but BNF and REs are just so different that it doesn't pay me to
try to think of both at once.)
> The highest item on MY list is, can I do that?
> (With a minimum of grief.)
>
My experience is that it depends VERY much on what the "that" is.
I gave up trying to use REBOL for 2- and 3-dimensional array
computation. The notation was too awkward and the performance
just wasn't there.
OTOH, I would hate to do much text parsing and cgi work in c!
(And don't even MENTION c-octothorp!)
To be objective, some of REBOL's current weaknesses are:
1) Lack of comprehensive specifications and documentation for
the language, especially the newer features. Let's face it;
REBOL is a work in progress, and the lack of polished docs
is the price you pay for being on the cutting edge of new
developments.
2) Speed. Or lack thereof. If you need the raw bit-crunching
velocity of gcc with all optimizations turned on so that
you can drive your 21-inch monitor and 100-base-T NIC to the
wall, you won't be doing it in REBOL. (However, for moderate
volumes of CGI hits, development, rapid-turn-around scripts,
trying ideas out, and any situation where plus-or-minus 50%
on the run-time is no big deal, REBOL is quite adequate.)
3) Binary compatibility with other languages. (Of course, you
may not care, if you are looking for the One True Language.)
Being able to write chunks of an app in different languages,
variously compile them and link them together with off-the-
shelf libraries and make one self-contained binary... well,
you aren't going to be doing that with REBOL (at least not
Real Soon Now).
> I've followed the discussion of scope with regard to Rebol with
> some concern. The idea that variables that are all static and
> global does not give me the warm fuzzies (or that you have to
> declare variables local in a function. Just the act of declaring
> them should make them local.)
>
If my posts have created a misconception here, let me apologize and
try to clarify. It is *not* the case that all variables are static
or global. REBOL simply has such a radically different approach to
scoping (i.e., contexts) that conventional comp sci terminology runs
the risk of being very misleading.
REBOL primarily controls scope by "definition", be it of a function,
an object, or otherwise. The *defaults* in some cases favor speed
over encapsulation, but given that REBOL can create functions,
objects, etc. on-the-fly as often as needed, one can implement
ideas that go well beyond the defaults.
As far as words in a function being "local" by default, well I've
been learning and imagining new languages for lotsa years, and it
seems to me that there's virtue in allowing a function/procedure
to access data both in its own scope and in previously-existing
scopes. Which of these cases (local vs. non-local) one makes the
default seems to boil down to:
1) politics and "religion",
2) which case is used more, and therefore should require less
typing to utilize,
3) how much the language designer wants to protect me from myself
vs. give me the power to say what I want (including saying
things I don't understand well myself and then get bitten by)
> I'm a VB programmer these days because that's the language the
> project was written in when I joined my present employer. We do
<<quoted lines omitted: 3>>
> I need to be able to write this kind of application in my
> language of choice.
Does embedded SQL count as another language? ;-)
> Which brings us back to that highest item on my list. As an
> example, if the layout dialect didn't exist, could I write it
> myself in Rebol or would I have to go begging RT to include
> the feature in a new version?
>
VID is a dialect built on top of the more fundamental UI
concepts in REBOL/View. You can rewrite it yourself if you
want to change the way it works. But you have to do so in
REBOL/View, not REBOL/Core. Similarly, if you want to write
some nice dialect that lets you replace bash or ksh with REBOL,
you can do so, but only if you're working in REBOL/Command.
The different flavors of REBOL provide *both* some critical
basic mechanisms and some nice syntactical sugar for using them.
> What other things do I need that are not included? How do I
> create a new widget that isn't already provided for me?
>
Use the source, Luke!
Look at how VID implements the basic
set of widgets it offers, then look at the WinSkin demo, then
try your hand at creating another widget.
I know this reply has rambled severely (it's late here...), but
what I've tried to do is say, "Here's what I personally think
are some of the strengths and weaknesses of REBOL. If those
line up well with the kinds of programs you want to write, then
I recommend it."
Hope this helps!
-jn-
[14/51] from: kenneth:nwinet at: 14-May-2001 21:31
Tim Johnson said:
> I rewrote one of my small projects (600 record database/15 fields) which
> was originally done in C++. It took about a third of the time as
> the "C++" edition.
When a language is put into the class of 'scripting language' it's use is
assumed to be only for very small projects. Why is that? Is there some
intrisic reason a language must be so limited? I think of languages of
having only two intrinsic levels, machine and virtual machine. Everything
else seems to me to be an artificial limitation. I'm not speaking here of
the limitations of languages, but rather, our own limitation in our
perception of them.
Many scripting languages are typeless for instance. Rebol is not. Does
this mean it's not a good choice as a scripting language? I don't even have
to point out how absurd that is. So what are the barriers that prevent it
from being capable of major applications? Can they be overcome by
intelligent (and careful) expansion of it's core features?
We don't have to ask these questions, but if we do, and we find positive
answers...
I want to do everything in one language (a fool no doubt) and have my
challenges be the barriers I have to overcome outside my language, not from
within.
Give me liberty or give me death (I heard someone once said.) One fluent
language without artificial barriers is my idea of liberty. Feel free to
come up with your own examples of ...
> I would prefer that words like "elegant" and "powerful" be eliminated
> from any conversation about computer programming languages. They
> mean nothing to me.
Oh come now! You've just spent too much time listening to customers give
you specs in qualitive terms rather than quantitive ones. :-) I know how
that works. But, I'd hate to give up the idea of elegance in an algorithm
or a language. It has much more than a surface meaning. Consider the world
without Rebol, then tell me it doesn't introduce a certain quality of
elegance into the mix.
> I believe rebol may be the flagship language of the future.
See! You do have the heart of a poet!
[15/51] from: dean:clockwork-technologies:ab:ca at: 15-May-2001 1:32
Hi, Joel:
You are correct, the mainframe in question (Unisys 2200) does support TCP/IP, and it
_should_ in fact
be able to speak to the Sun box. Unfortunately, there's a "network configuration problem."
The
networking boys assure me that it's a simple problem to fix -- but with only 4 mainframe
programmers in
a company of over 450 employees, and with a dozen or so ornery Production servers to
constantly
babysit, you can imagine how far down the totem pole we are. In the meantime, I have
testing to do
and firm deadlines to meet...
As for putting REBOL on the Sun box...good idea, but the Powers-That-Be won't give the
OK to put it
on said server. They don't seem to mind it being on the hard drive of my workstation
PC. They don't
even seem to mind that I use it from time to time to make my work life easier, but they're
visibly
uncomfortable with letting it go anywhere else in the company, and I'd rather not push
the issue right
now. It boils down to "Corporate Standards" I suppose.
Reading the other posts on this topic, it seems I've taken a rather narrow-minded view
of REBOL and
its potential. I will need to re-examine my approach the the language, I guess. In
the meantime
though, I'll stick to my original proposal that REBOL nicely fills in numerous gaps for
those of us who
work in highly networked (read: very decentralised) environments. I've never seen anything
else that
quite compares with it.
Original message from: Joel Neely
[16/51] from: petr:krenzelok:trz:cz at: 15-May-2001 10:17
Dean Powell wrote:
> Hi, Joel:
> You are correct, the mainframe in question (Unisys 2200) does support TCP/IP, and it
_should_ in fact
<<quoted lines omitted: 8>>
> uncomfortable with letting it go anywhere else in the company, and I'd rather not push
the issue right
> now. It boils down to "Corporate Standards" I suppose.
Ah well, what to say? What is the "standard"? If you would ask your Sun folks, they will
probably answer
you Perl, PHP etc. I sincerely hope we are not far away from Rebol becoming standards.
I hope few upcoming
articles and help of further Rebol promotion (e.g. by Eight Inc.) will help companies
(or its IT emloyes)
raise from the shadow and openly say - yes, we use rebol, because of its advantages.
My friend in my programmers group wanted to manually enter currency information for 24
currencies, because
Rebol is not widely used. I hate such opinions. I programmed the solution, another friend
helped me to
program bridge app (filling downloaded & parsed currency info into database table) and
nowadays we can't
imagine our life without such small util.
My impression is - we have to "fight" our positions a little bit harder! Remember the
Linux some 5 years
ago? Linux is pretty much a hype nowadays. And why? Becuase once ONE single big player
says - it is good
and I will adopt it - others will look into solution to don't stay behind ... that's
the world we live in
... :-)
I am not suggesting you to make any hard push at folks inside your company :-) There
is several ways of how
to do it - program solutions yourself using Rebol and maybe one day someone notices you
have some very
handy utils (looking nice in View :-), or you can do workshop for your friends, of course
if they are your
true friends, not just corporate ego partners.
One suggestion - read following site: http://www.rebol.com/quotes.html - I found it pretty
encouraging ...
I found also pretty much encouraging email by Mr. Chang sent to Ally list. It seems that
Rebol will be
covered in John C. Dvorak's column, Washington Post and there is also possibility for
the article to appear
in the MIT's Technology Review magazine, which is being read worldwide by many CEOs.
Let the Rebol be with you!
:-)
-pekr-
[17/51] from: lmecir:mbox:vol:cz at: 15-May-2001 10:25
Hi,
you wrote:
...snip...
> Here's an example of what I mean... If we
> change the default to no
reassignment we could use another symbol for
> explicit reassignment.
word: [to assign]
word:: [to reassign]
But
> I've always found double colons to be ugly. Any thoughts?
You seem to address the same issue I tried to solve in http://www.sweb.cz/LMecir/rep.html
To pick the right style for reassignment seems to be really hard.
[18/51] from: petr:krenzelok:trz:cz at: 15-May-2001 10:42
[lmecir--mbox--vol--cz] wrote:
> Hi,
> you wrote:
<<quoted lines omitted: 5>>
> word: [to assign]
> word:: [to reassign]
word:-< :-)
... the question is if RT 1) even got to properly read your rep 2) finds suggested changes
usefull/applicable ...
-pekr-
[19/51] from: joel:neely:fedex at: 15-May-2001 7:13
Dean Powell wrote:
> Hi, Joel:
>
> You are correct, the mainframe in question (Unisys 2200) does support
> TCP/IP, and it _should_ in fact be able to speak to the Sun box.
>
Unisys! That's a name I haven't heard in a while... I was involved
with the Burroughs users' group back when it was still a company.
Their B1700/1900 family was a striking example of a great idea that
went unappreciated in the marketplace at large. (A 24-bit RISC-like
processor with dynamically-reconfigurable microcode, and a multi-
tasking OS that ran in 32K of memory -- in 1973!)
> Unfortunately, there's a "network configuration problem." The
> networking boys assure me that it's a simple problem to fix...
> In the meantime, I have testing to do and firm deadlines to meet...
>
I understand fully. Reality intrudes. Been there myself.
> As for putting REBOL on the Sun box...good idea, but the
> Powers-That-Be won't give the OK to put it on said server. They
<<quoted lines omitted: 4>>
> the issue right now. It boils down to "Corporate Standards",
> I suppose.
Standards are good. That's why we have so many of them.
Standards are about consistency and predictability, not about
productivity.
;-)
Hmmm, I think I've heard the like somewhere back in my long career.
Not that I'd EVER suggest anything even faintly subversive, but...
Just as a matter of academic interest, you can put the binary for
REBOL in the bin directory of your own account and prefix all your
scripts with
#!/export/home/myuserid/bin/rebol
to run the interpreter from there. I usually do something similar
when the sysadmin isn't handy to install an upgrade...
> Reading the other posts on this topic, it seems I've taken a
> rather narrow-minded view of REBOL and its potential. I will
> need to re-examine my approach the the language, I guess.
>
Well... no criticism was implied. It's just that the value of
ANY tool for me depends on the intersection of what that tool
does well with what tasks I'm currently working on. Changes in
my task load somehtimes makes significant changes in what tools
are useful/relevant for the tasks at hand.
> In the meantime though, I'll stick to my original proposal
> that REBOL nicely fills in numerous gaps for those of us who
> work in highly networked (read: very decentralised) environments...
That is certainly one of its "sweet spots"!
Good luck with your challenges, both technical and political!
-jn-
[20/51] from: joel:neely:fedex at: 15-May-2001 8:09
Hi, Ken and all,
Ken Anthony wrote:
> > In my opinion, it is ok to overwrite words...
> Yes it is ok, but does it put more or less burden on the
<<quoted lines omitted: 4>>
> word:: [to reassign]
> But I've always found double colons to be ugly. Any thoughts?
We could go the other way and tackle the problem ourselves; leave
the colon suffix as is and try something like the following (where
the "p" presumably stands for "protected" or "paranoid" or even
possibly
):
REBOL/View/Pro 1.2.0.4.2 8-May-2001
Copyright 2000-2001 REBOL Technologies. All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM
Type DESKTOP or SET-USER for settings.
>> glorp: [this is a test]
== [this is a test]
>> pset: func [[catch] 'wref expr] [
[ either value? wref
[ [throw make error! "Word already set!"]
[ [set wref expr]
[ ]
>> pset glorp [this is another test]
** User Error: Word already set!
** Near: pset glorp [this is another test]
>> pset glonk [this is another test]
== [this is another test]
>> glorp
== [this is a test]
>> glonk
== [this is another test]
>>
So that PSET will only SET words that currently have no value (that
are valueless? that are clueless? Well, you know what I mean! ;-)
-jn-
--
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[21/51] from: kenneth:nwinet at: 15-May-2001 6:56
From Petr Krenzelok:
> > explicit reassignment.
> ... the question is if RT 1) even got to properly read your rep 2) finds
suggested changes
> usefull/applicable ...
Don't be so pessimistic. They may or they may not.
I had a friend that was a gold minor that told me an interesting thing. He
asked me what I thought was the most useful tool for his profession.
You might think, mercury, or that machine for separating out the gold, but
he told me it was a simple spoon.
Here's how he used it. He would go to areas where other minors where
operating (not claims, just others out in the mountains hunting.)
He knew from the contour of the land where gold was likely to be found, but
then so did all the other minors.
He'd find someplace where another minor had spent all day shoveling and
picking a pile of dirt.
He'd find the place where the other minor had given up because the rock came
together too hard.
He'd get out his spoon and dig the other six inches or so and pull out a
sizable nugget.
Then he'd do it again where some other minor had spent a day or two digging.
My point; the difference between greatness and just another big pile is that
last six inches.
This was a great article:
> http://www.sweb.cz/LMecir/rep.html
Rebol has a great advantage of youth. It may just be the language of the
stars someday. I'm sure they listen.
I've got to get to work now, but I do want to respond to the other comments
when I get home. Thanks all...
[22/51] from: kenneth:nwinet at: 15-May-2001 7:13
I really do have to get to work guys, but you have such great comments...
> > > In my opinion, it is ok to overwrite words...
> >
<<quoted lines omitted: 13>>
> the "p" presumably stands for "protected" or "paranoid" or even
> "possibly"):
The danger as I see it, is modifying something that has a certain elegance
into something that will not be used. For instance in the article
(http://www.sweb.cz/LMecir/rep.html) it uses the degree symbol where I use
the double colon above. I would have two objections to that... 1) where is
the degree symbol on my keyboard. 2) same as the first, I chose double
colon because it seemed the least intrusive (although in general I dislike
double anything notation, it does make it easier to type and provides a
direct connection to the single colon notation)
Another example. I like the fact that C# has replace all the various
notation with the dot.notation In Rebol the / is somewhat the equivalent
and after my initial hesitation/orientation it seems perfectly natural to
me.
I think it matters.
Thanks again, I'll respond to your earlier post later today.
Ken.
[23/51] from: gjones05:mail:orion at: 16-May-2001 7:41
***Major Side-Bar Alert***
(those looking to follow the "real" thread, feel free to skip)
<snip>
> From: "Joel Neely"
<<quoted lines omitted: 5>>
> > haven't solved the problem of universally-consistent
> > notation.
From: "Ken Anthony"
> You are quite right. However, this is where my intuitive kicks
> in (and could very well be wrong, I know I'm in the minority
> here. Good thing I'm an INTJ.) My intuition tell me that
> computer programming is a finite area of mathmatics. Really
> finite, we have only two digits in the whole thing! <snip>
Here is where I have to throw in 2 more cents. From my view, you are
both saying the same thing; you are just arguing from two different
points along the path.
The ancient Greek philosphers first appreciated (or, at least, were the
first to document their appreciation) that very elemental substances
combine to form all the complexity of the universe. The reawakening of
this concept is now occurring in the fields of complexity and chaos
theory. From a symbolic perspective, two digits are all that are
required to represent even the most complex behavior. It is the
interactions and feedback amongst these elemental pieces that creates
the behavior.
In a sort of object-oriented paradigm, each piece "knows" what it can do
and can't do. It is in the interactions that complexity is born.
The universe requires no notation to work its magic. It simply "does."
As we seek to understand, we apply notations as markers (dynamic
variables, if you will allow). Mathematicians deal largely in
abstractions that may not have a physicial counterpart. Programmers
seek to create and capture behavior that is correct and reproducible (at
least where reproducibility is the goal!). Both require notation and
the notation is arbitrary.
Joel speaks of mathematicians not having "solved the problem of
universally-consistent notation," that from my perspective (in the form
of two examples), means that "namespaces" may clash, and/or that values
are not directly assignable. Joel apparently uses the mathematical
discipline as an example because of its longer heritage as compared to
computer "science" and/or programming "art/science". I think that few
would argue the mathematics, as a discipline, would benefit from having
one, true notation
(apologies to Ken), but. like delving into a
Mandelbrot graphic, the complexity extends and even seems to expand as
one goes to the smaller scales. The general purpose notations/tools
fail to be adequate in explaining and expressing this behavior. Hence,
more complexity and extension of notation is created to deal with the
new
behavior.
Ken seems to be arguing that the relm of programming falls into one
sub-plot of the Mandelbrot, and, therefore, surely one notation could be
adequate for dealing with this relm. My intuition tells me that, like a
Mandelbrot plot, that the more one delves into the behavior of a
problem, the more likely one will discover more complexity, not less.
Hence, more extension of the notation is required.
So, I hope I've made my argument that this is a "spectrum thing"
(apologies now to George Bush, The Elder), meaning a spectrum of
complexity. The beauty of this discussion is that REBOL is one of the
few languages (of which I am familiar) that allows for new expressivity
as a part of its built-in feature set. LISP was undoubtedly the great
grandpappy, but like many great grandpappies, its large around the
middle and a bit crusty when it comes to expressivity in that everything
is "parenthetical" (lame attempt at humor :-).
Spoken/written language allows for great expressivity, because of the
flexible way in which units can be combined and new dialects (nee
notations) can be created. But with extension and growth
misunderstandings
can and do occur. The same is true of REBOL or any
new/different programming language.
> I'm not arguing perfection. I suggesting... that the quest is worthy.
As I've already pitched in over the weekend, I agree. I'm sure Joel
agrees; he's just being more realistic.
With best regards,
--Scott Jones
[24/51] from: kenneth:nwinet at: 16-May-2001 6:41
Joel,
in your last post I was amazed by how much our thoughts agreed and how well
you expressed them. One of my failings (although perhaps not a failing) is
that I approach ideas from unusual angles (I was going to say weird, but
then decided to be kinder to myself, and more concise in the process.) For
example, as a child contemplating the purpose of shifting gears, rather than
seeing this as a way of making a vehicle go faster (which was obvious to me)
I saw it (and unforetunately explained it to others in this way) that gear
shifting was a way of making the engine go slower (leaving the unstated
conclusion that this allows the vehicle to go faster.) To this day my
mother loves to embarrass me by telling any that will listen that as a child
I argued that the milk in my glass at the dinner table was 'boy's milk'
knowing full well it came from cows (it was in my glass, I possessed it and
I was a boy. Made perfect sense to me.)
I agree (even wholeheartedly) with all of your response with one minor
exception which I take responsibility for because I was not explicit (as to
which question I was refering.)
> > > > What other things do I need that are not included? How do I
> > > > create a new widget that isn't already provided for me?
<<quoted lines omitted: 5>>
> >
> I didn't mean it as sheer rhetoric.
I meant that my question was the rhetorical one (but of course I state it
right after your statement and neglect to mention that I'm refering to a
question.)
BTW, in spoken conversion I think parenthetically too. Which can be really
annoying to others since the parentheticals are silent! (or perhaps it's
better that they are!)
If I were to sum up Rebol and it's relation to my quest I'd say it certainly
is not at the end of the journey, but it does include elements on the map.
As you correctly pointed out, it's not the goal that's important, it's the
journey.
Regards, Ken.
[25/51] from: kenneth:nwinet at: 16-May-2001 6:44
WOW! I wrote my reply to Joel before reading this. Scott you've confirmed
my belief that this is one smart group of people.
> > From: "Joel Neely"
> > > The only absolutely extensible "language" I know
<<quoted lines omitted: 13>>
> both saying the same thing; you are just arguing from two different
> points along the path.
I say again! WOW!
I am in awe, ken.
[26/51] from: kenneth:nwinet at: 16-May-2001 6:56
Scott,
> Ken seems to be arguing that the relm of programming falls into one
> sub-plot of the Mandelbrot, and, therefore, surely one notation could be
> adequate for dealing with this relm. My intuition tells me that, like a
> Mandelbrot plot, that the more one delves into the behavior of a
> problem, the more likely one will discover more complexity, not less.
> Hence, more extension of the notation is required.
This is my view precisely. My defense (not that such is needed, but bear
with me) is that just as Newtonian physics is useful in a relativistic world
some subset of notation would allow a generally useful language that is
simpler, more expressive and powerful that most of the examples that
currently exist.
Now I'd like to throw another challenge out to this list.
Does being able to be more expressive, through greater levels of
abstraction, always have to lead to a performance loss. This is a thorny
issue that I've had difficulty grappling with. It's easy to find examples
where this is true. I'm looking for examples where this may not be true.
Thanks all,
Ken.
[27/51] from: geoff:productivity at: 16-May-2001 13:08
Hi folks
I have been following this thread with great interest.
We are playing with an idea for a code generator that will produce highly
confurable web applications without the usual birds-nest of conditional
code. This will obviously be easier with a highly dynamic and introspective
language, which is why we are looking at Rebol.
But this thread has alerted me to the possibilities of Lisp - especially the
reference to Paul Graham's article "Beating the Averages" about building the
Yahoo webstore interface.
I had always seen Lisp as a backwater for AI specialists, but it is clear
that there is a healthy little community who are using it for general
programming, and claiming very substantial payoffs in terms of pruductivity,
power and elegance. As one of the oldest languages, it obviously has the
edge over Rebol in terms of maturity. And as there are compilers that output
ASCII C is is pretty portable.
I would be interested in the comments of anyone who has hands-on experience
of working in Rebol and Lisp. They would certainly seem to have much in
common. What are the strengths and weaknesses of the two approaches - why
did Carl feel the need for a new language rather than using Lisp?
Geoff Caplan
[28/51] from: meekerdb:rain at: 16-May-2001 18:19
It would seem to be true of all the general purpose languages I know of
that increased abstraction creates a penalty for the interpreter or at
compile time. Whether it creates a run-time penalty would seem to be a
problem the compiler could, at least in principle, overcome.
Brent Meeker
There are two ways to write error-free programs.
Only the third one works.
On 16-May-01, Ken Anthony wrote:
[29/51] from: joel:neely:fedex at: 16-May-2001 23:33
Hi, Brent, Ken, and all...
I like REBOL. REBOL is good.
(Did I mention that I like REBOL?) Having said that...
Given REBOL's compact and expressively powerful notation,
the REBOL implementation is not as fast as those of more
limited notations. It is also the case that REBOL's
notation and implementation contain some subtleties that
make it impossible for me to call it "simple". I believe
these tradeoffs are inescapable, and offer some concrete
examples in support of that belief.
I must emphasize: as a vehicle for exploring programming
ideas, REBOL comes out on the winning side of the trades.
-jn-
Brent Meeker wrote:
> It would seem to be true of all the general purpose
> languages I know of that increased abstraction creates a
> penalty for the interpreter or at compile time. Whether
> it creates a run-time penalty would seem to be a problem
> the compiler could, at least in principle, overcome.
>
Errrrmmm. What compiler? (Or perhaps I should say, "which
compiler, and when?")
Let me be clear that I'm ***NOT*** stepping into the bogus
mind-set that describes some languages as "compiled" and
other languages as "interpreted". Those adjectives describe
properties of the implementation layer, not the notational
layer. It is entirely possible to implement c via an
interpreter, as well as a compiler. It is entirely possible
to implement LISP via a compiler as well as an interpreter.
(Both have been done.)
That said, some features on notation can impose constraints
on what the implementation must deal with. REBOL notation
refuses the conventional code-vs-data distinction, instead
allowing a running REBOL program to construct a block (as
if it were "data") and then immediately DO it (as if it were
executable code
) or use it to construct a function or
object (as if it were "source code"). At the very next
moment, the program may again manipulate the contents of the
block (back to data-like treatment). And so on...
Some strategies for implementing such notational flexibility
are:
0) Interpret the language. Accept the reduced execution
speed as the cost of flexibility.
1) Restrict the notation to a subset that cannot express
such manipulations. Compile that to machine code.
Accept the reduced flexibility as the cost of higher
execution speed.
2) Use a "just-in-time" compilation strategy, in which the
compiler is part of the run-time system. Whenever a
block is first encountered in a code-like usage, compile
it to machine code and thereafter treat each code-like
use of the block as an invocation of that machine code.
However, any data-like mutation of the block voids the
warranty on the compiled representation. Flag the block
as no longer being compiled. Any subsequent code-like
use must first re-invoke the compiler.
Accept the run-time penalty of compilation, as well as
the space-wise and code-wise complexity of putting the
compiler into the run-time system, as the costs of
higher execution speed. Accept the fact that net speed
over some programs (e.g., those that keep manipulating
and evaluating the same block(s) repeatedly) may not
be much of a gain -- if any -- over plain interpretation.
(Note that "data-like mutation of the block" includes any
changes to its content, the content of its content, etc.
Such transitive closures are non-trival to compute! I'll
not pursue this aspect further, at least for now; I just
wanted to point out that there are *HAIRY* details.)
3) Use a probabilistic "just-in-time" compilation strategy,
in which a block is interpreted for the first few code-
like uses. Statistics of such use are kept. After the
number of such uses (or frequency of such uses) passes
some threshold, the run-time system then decides to make
and cache a machine-code version of the block. This has
all of the costs of (2) plus the complexity of the
decision heuristics. It also has the same property that
constant twiddle-and-run activity frustrates the speed-
up mechanisms.
I'm very interested to see if anyone can suggest any others.
Note, again, that I'm talking about implementation strategies,
not properties of the "source code" notation.
Let's see how these alternatives fare on some trade-off
criteria, with the following definitions. By "compact" I
mean both the source code and the size of the run-time
system (interpreter, compiler, libraries, whatever...)
By "powerful" I mean expressive power; others are free to
define their own contexts. ;-) By "simple" I'm referring
to the implementation and run-time system, and *NOT* to the
notation. By "fast" I mean... fast execution.
Option Compact Powerful Simple Fast
------ ------- -------- ------- ---------
(0) yep yep likely nope
(1) sort of less so less so best
(2) nope yep nope sometimes
(3) no way yep NOT! sometimes
Obviously, these are broad-brush statements. However, I
invite anyone who wants to disagree (in qualitative, broad-
brush terms, please!) either to provide another alternative
with compelling arguments why it obviously doesn't fall into
a trade-off, or to show compelling reason why one or more of
the above generalities must be flawed for some case.
> On 16-May-01, Ken Anthony wrote:
...
> >
> > Now I'd like to throw another challenge out to this list.
<<quoted lines omitted: 6>>
> > may not be true.
> >
I'd be delighted to see such examples myself. I just haven't
found any (except for highly special circumstances).
Please bear in mind (and pardon me for perhaps belaboring the
obvious) that performance loss is not the only trade-off.
Let me give a specific example.
I've often described REBOL to technically-savvy acquaintances
as being "like LISP without parentheses". The consistent
(obsessive? ;-) use of parentheses in LISP/Scheme makes the
effort of both lexical scanning and pretty-printing almost
nil ( ;-) and essentially the same task. Now consider this:
REBOL has a very rich set of data types. This makes the work
of lexical scanning a bit harder, but still quite feasible.
REBOL is a truly extensible language; you can define words to
be new "control structures" and even define new "defining
words", all within REBOL itself. This makes the work of
writing a fully general pretty-printer formally impossible!
It is not in principle even possible, except during expression
evaluation, to predict how a sequence of REBOL words could
be fully parenthesized in a semantically-transparent way!
Here's a little REBOL parlor game: how many ways can we
insert parentheses into the following block
[a + b c]
and still have a syntactically valid REBOL expression?
Depending on how those three single-letter words are defined,
how many of those parenthesizations are semantically valid
and semantically equivalent to the original block?
I quickly dashed off four; the output below shows them at
work. I'd be interested to see any others.
>> pp-NOT
How many ways can we parenthesize the block
[a + b c]
and how many of those are valid (and equivalent)
depending on how A, B, and C are defined?
Case 1
[a + b c] = [121]
1 [a (+ b c)] [121]
2 [(a + b) c] ERROR
3 [(a + b c)] [121]
4 [a + (b c)] ERROR
Case 2
[a + b c] = [11 100]
1 [a (+ b c)] [1 110]
2 [(a + b) c] [11 100]
3 [(a + b c)] [100]
4 [a + (b c)] [101]
Case 3
[a + b c] = [404]
1 [a (+ b c)] ERROR
2 [(a + b) c] ERROR
3 [(a + b c)] [404]
4 [a + (b c)] ERROR
Case 4
[a + b c] = [903]
1 [a (+ b c)] ERROR
2 [(a + b) c] ERROR
3 [(a + b c)] [903]
4 [a + (b c)] [903]
>>
In case anyone is mildly interested, here is the function
that wrote that little essay.
8<----------------------------------------------------------
pp-NOT: func [
/local a b c code-like
][
code-like: [a + b c]
case-1: does [
a: func [n] [n * n]
b: 1
c: 10
print "Case 1"
]
case-2: does [
a: 1
b: 10
c: 100
print "Case 2"
]
case-3: does [
a: func [:op left right] [
(op (left * left) (right * right))
]
b: 2
c: 20
print "Case 3"
]
case-4: does [
a: 3
b: func [n] [n * n]
c: 30
print "Case 4"
]
test-case: func [n [number!] b [block!] /local rb] [
print [
tab n tab mold b tab
either error? try [
rb: reduce b
][
"ERROR"
][
mold rb
]
]
]
test-cases: does [
print [
tab tab
mold code-like
tab "=" tab
mold reduce code-like
]
test-case 1 [a (+ b c)]
test-case 2 [(a + b) c]
test-case 3 [(a + b c)]
test-case 4 [a + (b c)]
print ""
]
print [
"How many ways can we parenthesize the block" newline
tab mold code-like newline
"and how many of those are valid (and equivalent)" newline
"depending on how A, B, and C are defined?" newline
]
case-1 test-cases
case-2 test-cases
case-3 test-cases
case-4 test-cases
]
8<----------------------------------------------------------
Have fun!
-jn-
--
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[30/51] from: kenneth:nwinet at: 15-May-2001 20:44
Home again...
Joel Neely said:
> You're certainly entitled to your quest, "to follow that star..."
Dulcinea shall not escape me! Although pictures of my fiancee standing next
to me don't seem to be enough for the INS, but that's another matter...
>The last two major efforts (of which I'm aware)
> aimed at building one-size-fits all languages produced PL/1 and
> ADA, and I don't know of very many people that even *use* either
> of those, much less regard them as "final solutions".
Which only proves that I am not alone in my quest (see, you can't discourage
a true knight errant ;-)
> > The highest item on MY list is, can I do that?
> > (With a minimum of grief.)
>
> My experience is that it depends VERY much on what the "that" is.
> I gave up trying to use REBOL for 2- and 3-dimensional array
> computation. The notation was too awkward and the performance
> just wasn't there.
Forgive me Joel, but that's the easy argument and you'll see it repeated in
various ways by many others. "We must use multiple tools because this tool
doesn't handle such and such a situation well." I don't know that I could
persuade anyone otherwise (or even myself... Heresy!) However, I believe I
have sound reasons for believing the quest not to be so foolish.
>REBOL is a work in progress...
...Ah, the possibilities...
>Speed.<snip>you won't be doing it in REBOL.
...today, tomorrow, maybe always...
>Binary compatibility with other languages. (Of course, you
>may not care, if you are looking for the One True Language.)
...yes and no...
>Being able to <snip> link them together
...when legacy code is an issue, but I'm willing to sacrifice this even
though I don't see any reason why I should have to...
Mainly the new language would meet my needs for new projects. Legacy code
eventually goes away... We might have to kick it a few times. ;-)
>REBOL can create functions, objects, etc. on-the-fly
...can't imagine any language being much good if you couldn't...
>how much the language designer wants to protect me from myself
>vs. give me the power to say what I want
Understood. My slant on this is the o/s should allocate resources and leave
me alone to do whatever in my sandbox.
> Does embedded SQL count as another language? ;-)
SQL of any flavor, yes indeed. Which very nicely allows me to express this
point. It would be a misconception to think that I am saying that having
access to the "One True Language" (that's a terrible phrase btw) means
throwing away or never using anything else. For example, years of work have
gone into making dbms engines more powerful. I want to take advantage of
that, not throw it away. Likewise, if some legacy code does something well,
I'd like to be able to call it. However, if I can do everything that SQL is
capable of doing using a simple and consistant syntax (I'm not suggesting
there is such a thing) then that's what I want to do.
> > What other things do I need that are not included? How do I
> > create a new widget that isn't already provided for me?
> "Use the source, Luke!" Look at how VID implements the basic
> set of widgets it offers, then look at the WinSkin demo, then
> try your hand at creating another widget.
This was a rhetorical Joel! But I do appreciate the thought.
> > Is there some intrisic reason a language must be so limited?
> Intrinsic to a specific language? If you design/implement it that
> way. Somehow intrinsic to the fundamental notion of "language"?
> Not really, but I truly believe there are tradeoffs in how our
> heads work -- see the sig below.
Your on, I pick simple and powerful :p ... uh ... one .... true
lang... SimPow! another language name is born (please tell me no one else
has already chosen it? Get the lawyers. Trademark attorneys... )
> > I think of languages of having only two intrinsic levels, machine
> > and virtual machine. Everything else seems to me to be an artificial
> > limitation.
> To me, even THAT ("machine" vs. "virtual machine") is artificial and
> arbitrary.
You are absolutely correct. However, let me continue my point. As you
pointed out, you can go below the machine level to the microcode level and
also build many layers of code/protocols above that. So why did I pick this
particular point? Because it is the point of machine dependance vs.
independance. If SimPow! is anything, it is machine independant. I would
even suggest that it contain a virtual machine language chosen to map
closely to actual machine language (but still machine independant.) Did
anybody ever use all 13 addressing modes of the 6502? Don't answer ;-)
> > So what are the barriers that prevent it from being capable of
> > major applications?
<<quoted lines omitted: 4>>
> all-things-to-all-people language more trouble than that required
> to learn a new small language tightly focused on the task at hand.
Probably because the were features (we all know the correlation between
features and bugs ;-)
Does this mean the 'new small language tightly focused' has to be something
outside SimPow! (you're gona' hate me for coining this new world - but
somehow I had to get away from the 'One True Language' theme which doesn't
fit at all what I'm suggesting.)
> > I want to do everything in one language (a fool no doubt) and
> > have my challenges be the barriers I have to overcome outside
> > my language, not from within.
Well, now we no where that silly idea came from!!!
> Not a fool, but certainly an optimist! Look outside of programming
> for the experience of other disciplines.
<<quoted lines omitted: 3>>
> "local dialects" for the various domains of activity, and haven't
> solved the problem of universally-consistent notation.
You are quite right. However, this is where my intuitive kicks in (and
could very well be wrong, I know I'm in the minority here. Good thing I'm
an INTJ.) My intuition tell me that computer programming is a finite area
of mathmatics. Really finite, we have only two digits in the whole thing!
I not suggesting we all start writing for a turing machine. What I am
saying is that I've used some general purpose languages that are far from
perfect, as have others, on a very broad range of subjects. Is it such a
stretch to imagine a language that is so powerful, simple and generally
useful that a very large percentage of a professional programmers tasks can
be handled by it. You can always find a case where a language can't fit
(any language, even machine language) because if the machine doesn't have
the resources, the task can't be done.
I'm not arguing perfection. I suggesting... that the quest is worthy.
> Physicists, chemists, and biologists are all presumably dealing
> with the same external, objective, real universe, but the issues
> with which each discipline deals exist on such different scales
> and levels that their "languages" for describing what they are
> doing are radically different.
...and yet, they often find themselves linked in surprising ways.
> If the only thing we ever did with computers was number-crunching,
> it would be perfectly OK for every other language to look like
<<quoted lines omitted: 4>>
> of the problem domain had matured/changed enough that the ideas
> frozen in paper specs were no longer even vaguely optimal.
...and many more state changes are ahead of us I'm sure.
> flexibility/extensibility has a cost in notation and/or raw
> performance.
I keep hearing you say it's a zero sum game (back to that sig again ;-)
> the relevant concepts get distilled into a more tightly-focused
> language with less (conceptual and implementational) overhead.
Then again, maybe not... So your saying there may still be room for
improvement (bashed that windmill a good one that time!)
> When I'm in scheme-and-dream mode, I *want* an extensible,
> expressive language. When I'm in get-the-production-server-up-
> -and-query-that-billion-row-database mode, I *need* a language
> implementation that is highly performance oriented
There are many anecdotal stories and much of life experience suggests it's
either/or... or is it? If I extend a language is it always on top of
performance robbing subfunctions? Isn't it equally possible to extend the
language close to the metal without suffering a huge performance hit?
Doctor, doctor, every time I add a new colon definition is slows me down.
It hurts, when I do this.
Don't do this.
> Thanks for the stimulating questions!!! I hope my musings in
> the vague direction of answers aren't too tedious/boring; they
<<quoted lines omitted: 5>>
> Pick any two!" joel'dot'neely'at'fedex'dot'com
> ------------------------------------------------------------
...and I follow all of your posts with interest.
Ken.
[31/51] from: kenneth:nwinet at: 15-May-2001 20:49
Thank you for the link.
> You seem to address the same issue I tried to solve in
http://www.sweb.cz/LMecir/rep.html
Progress requires critical analysis and a certain humility. I certainly
will be reviewing this article again after I've had more experience using
Rebol.
I really enjoyed reading it.
Ken.
[32/51] from: joel:neely:fedex at: 15-May-2001 23:37
Hi, again, Ken...
Many interesting points. Only time to respond to a couple right
now.
Ken Anthony wrote:
> Dulcinea shall not escape me! Although pictures of my fiancee
> standing next to me don't seem to be enough for the INS, but
> that's another matter...
>
My younger son played Don Quixote in "Man of La Mancha" this past
fall, so the Cervantes allusions strike a fond chord (no pun
intended -- yeah, right! ;-)
> >The last two major efforts (of which I'm aware)
> > aimed at building one-size-fits all languages produced PL/1 and
> > ADA, and I don't know of very many people that even *use* either
> > of those, much less regard them as "final solutions".
>
> Which only proves that I am not alone in my quest (see, you can't
> discourage a true knight errant ;-)
>
And many useful spinoffs have come from intense AI research, so I'm
all for windmill tilting, just for the side effects! However, we
still can't program computers by just talking to them in plain
English (whatever that is). It's just that if I believe that "the
journey is the reward" I'd better not pin my hopes on arriving at
Utopia.
> > My experience is that it depends VERY much on what the "that" is.
> > I gave up trying to use REBOL for 2- and 3-dimensional array
> > computation. The notation was too awkward and the performance
> > just wasn't there.
>
> Forgive me Joel, but that's the easy argument...
>
Perhaps its so easy precisely because it's true! Remember, you
asked
how close REBOL was to being The One True Language, so I was just
giving an example of something I do that REBOL doesn't handle very
well. (And, of course, I'll be the first to cheer if REBOL 3.0
turns out to be wonderful for array-based numerical computation.
However, it will take changes BOTH in performance AND notation
before that happy state arrives.)
> ...when legacy code is an issue, but I'm willing to sacrifice
> this even though I don't see any reason why I should have to...
> Mainly the new language would meet my needs for new projects.
> Legacy code eventually goes away... We might have to kick it
> a few times. ;-)
>
Well, in my day-job-alter-ego, my super-powers don't extend to
being able to persuade management that we should rewrite all of the
existing business logic in a new language just because I believe it
to be nicer than the old one(s). Many of my projects involve the
construction of new code that *must* interoperate with existing
systems, componenents, and libraries.
> >REBOL can create functions, objects, etc. on-the-fly
> ...can't imagine any language being much good if you couldn't...
>
Gigabit routers aren't written in dynamic, interactive, interpreted
languages. They have a fixed function, with severe performance
demands. I'm glad there are such languages, although I much prefer
not to have to spend too much time in them.
> > > What other things do I need that are not included? How do I
> > > create a new widget that isn't already provided for me?
> > "Use the source, Luke!" Look at how VID implements the basic
> > set of widgets it offers, then look at the WinSkin demo, then
> > try your hand at creating another widget.
>
> This was a rhetorical Joel! But I do appreciate the thought.
>
I didn't mean it as sheer rhetoric. Someone recently posted a
bug fix that he figured out by reading the VID source. Other
folks have already figured out how to extend VID by doing the
same. I was seriously trying to say that it could be done.
> My intuition tell me that computer programming is a finite area
> of mathmatics.
>
Perhaps finite, but arbitrarily large nonetheless...
> Is it such a stretch to imagine a language that is so powerful,
> simple and generally useful that a very large percentage of a
> professional programmers tasks can be handled by it [?]
>
It is for me. Computing Science is an open-ended quest, as is
Mathematics. As long as we are discovering new things to think
and program about, we'll need a steady flow of new and more
expressive notations with which to communicate those thoughts.
> I'm not arguing perfection. I suggesting... that the quest
> is worthy.
>
And, as I said much earlier, on that we agree. But my view is
that the quest is worthy because of what we'll learn along the
way, not because there's an end to the quest at which we'll
eventually arrive and from which we'll nevermore depart.
> > flexibility/extensibility has a cost in notation and/or raw
> > performance.
>
> I keep hearing you say it's a zero sum game (back to that sig
> again ;-)
>
Heisenburg thought so...
> > the relevant concepts get distilled into a more tightly-
> > focused language with less (conceptual and implementational)
> > overhead.
>
> Then again, maybe not...
>
Forgive my quoting someone else (oh, that was you ;-), but
maybe not
is an easy argument. And not very compelling
if all the actual evidence at hand points the other way.
> So your saying there may still be room for
> improvement (bashed that windmill a good one that time!)
>
Yes, but when one arm of the windmill goes up, another one
goes down! There's always room for improvement in one
specific area if you're willing to pay for it in another.
Thanks again for your challenging insights, and stay on
the horse. One of those windmills might actually roll over
and play dead!
-jn-
--
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[33/51] from: petr:krenzelok:trz:cz at: 17-May-2001 7:08
Hi Joel :-)
Joel Neely wrote:
> Hi, Brent, Ken, and all...
>
> I like REBOL. REBOL is good.
>
> (Did I mention that I like REBOL?) Having said that...
>
> Given REBOL's compact and expressively powerful notation,
> the REBOL implementation is not as fast as those of more
> limited notations.
Ladislav thinks Rebol could become much faster, if certain things are
implemented (see his rep - don't remember url now ...)
> 0) Interpret the language. Accept the reduced execution
> speed as the cost of flexibility.
>
that's ok, ... look I am no expert on languages, but reading Ladislav's
doc I came to conclusion, that sometimes we could accept some small
language limitations gaining us much more execution speed. After all -
the proposed changes are not drastic imo ...
> 2) Use a "just-in-time" compilation strategy, in which the
> compiler is part of the run-time system. Whenever a
<<quoted lines omitted: 5>>
> as no longer being compiled. Any subsequent code-like
> use must first re-invoke the compiler.
that's why Ladislav suggest immutable block representation. If you know,
that your block will not be modified during the execution phase, you
could compile it then - this partial compilation could bring us some
nice speed increase ... well, as I said - just my theory without any
experience :-)
> Accept the run-time penalty of compilation, as well as
> the space-wise and code-wise complexity of putting the
> compiler into the run-time system, as the costs of
> higher execution speed.
As for above - maybe for some of us such additions would outweight above
mentioned factors?
Just a sidenote: I like Tao's aproach here - translated and compiled
into machine independent code (Virtual Processor code). During ICOA days
Amigans looked at slim binaries principles too.
> Accept the fact that net speed
> over some programs (e.g., those that keep manipulating
<<quoted lines omitted: 5>>
> not pursue this aspect further, at least for now; I just
> wanted to point out that there are *HAIRY* details.)
ah, you are probably right here. But then it's up to app designer to
construct block the way compilation will make sense for him/her if
he/she wants to use it :-)
> 3) Use a probabilistic "just-in-time" compilation strategy,
> in which a block is interpreted for the first few code-
<<quoted lines omitted: 6>>
> constant twiddle-and-run activity frustrates the speed-
> up mechanisms.
interesting technique ....
> I'm very interested to see if anyone can suggest any others.
> Note, again, that I'm talking about implementation strategies,
<<quoted lines omitted: 19>>
> a trade-off, or to show compelling reason why one or more of
> the above generalities must be flawed for some case.
heh, I left further comments to language gurus :-)
Cheers,
-pekr-
[34/51] from: al:bri:xtra at: 17-May-2001 19:46
> ...why did Carl feel the need for a new language rather than using Lisp?
May be this acronym "Lots of Irritating Silly Parenthesis" put him off Lisp?
:-)
Andrew Martin
ICQ: 26227169 http://members.nbci.com/AndrewMartin/
[35/51] from: lmecir:mbox:vol:cz at: 17-May-2001 9:48
Hi Joel,
I wrote http://www.sweb.cz/LMecir/rep.html to demonstrate how to create
something like a 1.5 strategy. The strategy I tried to propose was to gain
as much speed as possible without losing the expressive power. The speed of
the strategy should lie somewhere between
0 and 1, while retaining the expressive power at least at the level of 0.
The compactness/simplicity doesn't seem to be a big issue to me compared to
other languages.
[36/51] from: gjones05:mail:orion at: 17-May-2001 6:15
Joel, that was a very nice analysis and discussion. I learned quite a
bit. Thanks.
Just one question right up front: have you mentioned recently that you
like REBOL?
;-)
From: "Joel Neely"
<big snip>
> I'm very interested to see if anyone can suggest any others.
> Note, again, that I'm talking about implementation strategies,
> not properties of the "source code" notation.
The strategy that I was chewing on yesterday would probably only make a
small, incremental difference at best. Unlike Petr, I am not only not a
language expert, I am not even a programming expert! (Actually, I'm not
an expert in anything that I can think of!) However, I throw this
example out in the spirit of learning. It would seem that there would
be at least a small performance hit with parsing longer "words" (using
the REBOL parlance) as opposed to shorter, and that the performance hit
is additive in loops. I think that I've read that one of the first
tasks that some compilers undertake is to create its own shortened
variable name list (I've read it as being called mangling, which seems
to carry the human-centric, perjorative connotation) in order to improve
the parsing and compilation speed, and later, linking. I was wondering
whether there would be any speed improvement having a just-in-time
word-length shortening mangler,
and then creating a type of hashed
dictionary. The one draw-back that came immediately to mind would be if
a word name then is used in its literal form, then meaning would be
lost. Additionally, the performance gain would only seem to
significantly improve for longer programs with lots of long words and
numerous or long loops (otherwise, it would seem self-evident that the
JIT "mangler" would cost more than on-the-fly parsing).
--Scott Jones
[37/51] from: joel:neely:fedex at: 17-May-2001 7:24
Hi, Petr,
My admiration for your stamina! ;-)
Petr Krenzelok wrote:
> Ladislav thinks Rebol could become much faster, if certain
> things are implemented (see his rep - don't remember url
<<quoted lines omitted: 6>>
> execution speed. After all - the proposed changes are not
> drastic imo ...
I're read Ladislav's REP. I simply haven't persuaded myself
(yet?) that the overall effect of his proposals would be a
substantial improvement in performance for the majority of
REBOL programs.
> that's why Ladislav suggest immutable block representation.
> If you know, that your block will not be modified during
> the execution phase, you could compile it then - this
> partial compilation could bring us some nice speed increase
> ... well, as I said - just my theory without any experience :-)
>
Sorry, but I disagree with the conclusion -- although after
re-reading my original paragraph I accept full blame that my
wording probably was misleading.
IMHO, block immutability has more to do with notational and
correctness issues ("principle of least surprise", avoidance
of subtle bugs, eliminating tricky cases that can "trip" the
interpreter, etc.) than performance. The performance issues
I *meant* to be describing require nothing more than block
construction and evaluation. Modifying or eliminating *these*
would have a *drastic* effect on REBOL notation.
Consider the following fragment:
>> showall: func [b [block!] /local c] [
[ foreach item b [
[ c: compose/deep [print [(mold :item) "=" (item)]]
[ do c
[ ]
[ ]
>> tot: 17
== 17
>> obj: instantiate [a: 1 b: 2 c: 3 d: 4 e: "done!"]
>> showall [tot obj/a obj/b obj/e]
tot = 17
obj/a = 1
obj/b = 2
obj/e = done!
>>
The value of C is not being mutated, but each pass through
the loop constructs a new block and then DOes that block.
Therefore, this bit of code would require recompilation of
C's (new) value on each pass.
> Just a sidenote: I like Tao's aproach here - translated
> and compiled into machine independent code (Virtual
> Processor code). During ICOA days Amigans looked at slim
> binaries principles too.
>
That idea has been around long enough to have as much grey
hair as I do! ;-) A partial list of its heritage includes
UNCOL, SNOBOL, UCSD Pascal, and Java. Clearly some people
think it works for their Language Of Choice. Perhaps for
REBOL also?
> > Accept the fact that net speed
> > over some programs (e.g., those that keep manipulating
<<quoted lines omitted: 7>>
> > wanted to point out that there are *HAIRY* details.)
> >
(My same apologies for the misleading wording. I should hav
said "data-like construction of a block" instead.)
> ah, you are probably right here. But then it's up to app
> designer to construct block the way compilation will make
> sense for him/her if he/she wants to use it :-)
>
Sure. But this increases the list of rules and heuristics
the developer must bear in mind while constructing the block.
I submit that this constitues an increase in complexity (or
reduction in simplicity, however we want to word it).
-jn-
--
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[38/51] from: agem:crosswinds at: 17-May-2001 13:35
Seems to be implemented.
You know each used word in rebol is rememberd,
never deleted.
This gives the opportunity to store words as
[index? find first system/words the-word]
for fast lookups.
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 17.05.01, 12:15:02, schrieb "GS Jones" <[gjones05--mail--orion--org]> zum
Thema [REBOL] Re: What language am I looking for?:
[39/51] from: agem:crosswinds at: 17-May-2001 13:35
Found on escribe :)
>>>
[REBOL] rebol weak points (i think) Re:(6)
From: carl (view other messages by this author)
Date: Sun, 10 Sep 2000 18:50:47
So, why don't you guys just use the 'compile function?
fast-sort: compile function [data [block!] return: [block!]] [a
[integer!]] [...]
print type? :fast-sort
native!
<grin>
Turns out, you *can* write a compiler for REBOL. However, to do so
you need to make "promises"
about a function. You, the programmer, certify that the contents of
the function is indeed
compilable (by not using very late bound tricks).
The benefit of the above is that you can use the rest of the REBOL
environment for meta stuff...
like preprocessing what you will compile.
-Carl
<<<
Volker
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 17.05.01, 08:48:34, schrieb "Ladislav Mecir" <[lmecir--mbox--vol--cz]> zum
Thema [REBOL] Re: What language am I looking for?:
[40/51] from: petr:krenzelok:trz:cz at: 17-May-2001 14:55
Volker Nitsch wrote:
> Found on escribe :)
> >>>
<<quoted lines omitted: 15>>
> environment for meta stuff...
> like preprocessing what you will compile.
Carl! Now you have to explain above?? :-) Is this planned, or was it an
irony?
->> help compile
No information on compile (word has no value)
heh :-)
-pekr-
[41/51] from: joel:neely:fedex at: 17-May-2001 8:06
GS Jones wrote:
> Joel, that was a very nice analysis and discussion.
> I learned quite a bit. Thanks.
>
> Just one question right up front: have you mentioned
> recently that you like REBOL? ;-)
>
Obviously not recently enough! ;-)
I'm probably overly sensitive on this point, but some of my
attempts at discussing REBOL features, performance, and
trade-offs several months back seemed to provoke some
REBOL, love it or leave it!
responses. Therefore, I try
hard to make clear that my comments and questions are offered
in the spirit of trying to understand and (occasionally)
suggest improvements, not in a spirit of negativity.
I certainly do *not* want to offend anyone on the list or
at RT, nor fail to show appreciation for everything that's
been accomplished to date.
> From: "Joel Neely"
> <big snip>
<<quoted lines omitted: 9>>
> the first tasks that some compilers undertake is to create
> its own shortened variable name list...
As you correctly state, this is a "compile time" issue. The
closest analog in REBOL is "load time". I suspect that once
a REBOL block has been loaded (converted from external string
form into an internal data structure) that the words are
actually represented by pointers into a context. If that is
correct, then run-time access to the word is a constant-time
operation with no dependence on the name length.
Of course, the construction of a new context requires some
sort of handling of names (or at least pointers to names).
REBOL functions/processes that do this include FUNC (and
it's siblings FUNCTION and MAKE FUNCTION!), MAKE OBJECT!,
and USE.
However, even if we drove the time for those operations to
zero, it wouldn't speed up most running REBOL scripts by
too much.
You might be amused to know that early implementations of
FORTH had a related technique which often tripped up newbie
FORTH programmers. (Remember that FORTH was a truly tiny
language, capable of being implemented in a 4k-8k footprint
on most microprocessors. Saving memory space was even more
of an issue than speeding word lookup.) A common technique
for storing word names in a dictionary was to use the first
three characters of the word and a one-byte length. This
meant that it was all to easy to accidentally create name
collisions, such as
first -> "fir" 3
firms -> "fir" 3
You can image the possibilities for bug-breeding!
-jn-
--
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[42/51] from: gjones05:mail:orion at: 17-May-2001 8:03
From: "Volker Nitsch"
> Seems to be implemented.
> You know each used word in rebol is rememberd,
> never deleted.
> This gives the opportunity to store words as
> [index? find first system/words the-word]
> for fast lookups.
Oh. Thanks, Volker.
--Scott Jones
[43/51] from: gjones05:mail:orion at: 17-May-2001 8:41
Thanks, Joel, for the additional explanation about implementation
strategies for flexible, expressive languages. Also, regarding ...
> You might be amused to know that early implementations of
> FORTH had a related technique which often tripped up newbie
<<quoted lines omitted: 9>>
> firms -> "fir" 3
> You can image the possibilities for bug-breeding!
Wow. Almost as effective at breeding bugs as leaving food on a kitchen
counter in the US Gulf Coast areas!
--Scott Jones
[44/51] from: joel:neely:fedex at: 17-May-2001 10:08
Hi, Geoff,
Geoff Caplan wrote:
> We are playing with an idea for a code generator that will produce
> highly confurable web applications without the usual birds-nest of
> conditional code. This will obviously be easier with a highly
> dynamic and introspective language, which is why we are looking at
> Rebol.
>
While I'm sure it's not at the level of sophistication that your
description implies, I've written a site generator which uses XML
to express the structure, navigation, and search information for
a site, then constructs the entire site (including per-page
navigation links) using html templates. I wrote the first version
in Perl, then rewrote it in REBOL. The REBOL version is still in
daily use.
> But this thread has alerted me to the possibilities of Lisp...
> I had always seen Lisp as a backwater for AI specialists, but it
<<quoted lines omitted: 4>>
> maturity. And as there are compilers that output ASCII C is is
> pretty portable.
I would agree with your characterization of LISP. I have, in fact,
often described REBOL as being like "LISP without the parentheses".
I'd suggest that REBOL has a few advantages on its side of the
ledger:
1) Platform independence - IIRC, REBOL/Core runs on 40+ platforms
(and counting). The site generator I mentioned above can run
unchanged on Windows, MacOS, HP-UX, Solaris, and Linux. I've
often moved my development effort from platform to platform,
working on whatever box is conveniently at hand, then simply
carrying the code to the next. I've NEVER had breakage as a
result of such movement. Color me happy!
2) Built-in networking - How could it be any easier?
write %localdir/localfile read http://server/path/file
and many other similar variations.
3) Compactness (both of source code and run-time system) - How
many languages these days fit entirely on one 3.5-inch floppy,
complete with documentation and a generous library of samples?
> I would be interested in the comments of anyone who has hands-on
> experience of working in Rebol and Lisp. They would certainly
> seem to have much in common. What are the strengths and weak-
> nesses of the two approaches?
>
See the above, although I must confess that my LISP/Scheme
experience is a bit dated by now.
Hope this helps!
-jn-
[45/51] from: lmecir:mbox:vol:cz at: 17-May-2001 20:32
Hi Joel,
> IMHO, block immutability has more to do with notational and
> correctness issues ("principle of least surprise", avoidance
<<quoted lines omitted: 23>>
> Therefore, this bit of code would require recompilation of
> C's (new) value on each pass.
Well, the speed penalty for the above code seems to be obvious. But then, is
this a "typical code sample"? I don't think so, and I want to speed up an
average program. The cases like this can run as slow as interpreted and if
you want to make them faster, you may try a faster rewrite to something more
easily translatable.
[46/51] from: kenneth:nwinet at: 17-May-2001 19:38
Hey all,
Joel Neely wrote:
> I'm probably overly sensitive on this point, but some of my
> attempts at discussing REBOL features, performance, and
<<quoted lines omitted: 3>>
> in the spirit of trying to understand and (occasionally)
> suggest improvements, not in a spirit of negativity.
Not to worry. The general population often confuse analytic skills with
negativity. Contemporaneous (is that a word or did I just make a Bushism?)
writing often means leaving large wholes (<= is that Freudian or what?) in
the thoughts expressed that others like to drive trucks through. I could
show you the tread marks ;-)
When a language becomes a religion I think there's a problem. When people
feel they are personally being critisized they need to consider first that
they opened the door before they start shooting arrows back. (I personally
like listening to a good flame war, but I'm demented!)
> You might be amused to know that early implementations of
> FORTH had a related technique which often tripped up newbie
<<quoted lines omitted: 9>>
> firms -> "fir" 3
> You can image the possibilities for bug-breeding!
Your just trolling for the Forth guys, aren't ya? You know it's
first -> "fir" 5
firms -> "fir" 5
Not to be confused with...
firetrucks -> "fir" 10
But Seriously Joel, tell the love it or leave it crowd to get a life (but
not so they can hear it, it just encourages them.)
Ken.
[47/51] from: geoff:productivity at: 18-May-2001 10:14
Joel
> I've written a site generator which uses XML
> to express the structure, navigation, and search information for
> a site, then constructs the entire site (including per-page
> navigation links) using html templates.
Our idea arose out of our need for a sophisticated online catalogue.
Contractor quotes ranged from $30,000 to $60,000, which is a lot of $$ for a
small business. Yet once you have your underlying error/session/validation
etc libraries in place, the task of generating any specific catalogue is
essentially trivial. These guys were going to charge us $x00 per hour for
hand-hacking simple code that we suspect could be generated automatically
with a few switches, given a little craft and guile, (provided we can
develop a data model with sufficient flexibility). After all, the final
output of any dynamic web app is just a string - hardly rocket science.
.
> I have, in fact, often described REBOL as being like "LISP without the
parentheses".
> I'd suggest that REBOL has a few advantages on its side of the ledger:
>
> 1) Platform independence <snip...>
> 2) Built-in networking - How could it be any easier? <snip...>
> 3) Compactness <snip...>
This is interesting. It helps clarify why Carl places so much emphasis on
Rebol as a tool for distributed apps. These advantages carry most weight
when a client built in Rebol will be widely distibuted. The size, in
particular, is a spectacular achievement. But compared with Lisp, these
advantages seem less compelling where the whole app is on a central server,
as with a web app.
Would you agree, or am I missing something here...
Thanks for the input
Geoff Caplan
[48/51] from: gjones05:mail:orion at: 18-May-2001 5:06
From: "Ken Anthony"
> Contemporaneous (is that a word or did I just make a Bushism?)
No, you're on safe ground. Now, if you had said contemporaneosity ...
<g>
--Scott Jones
[49/51] from: joel:neely:fedex at: 18-May-2001 6:42
Well, Scott...
GS Jones wrote:
> From: "Ken Anthony"
> > Contemporaneous (is that a word or did I just make a
> > Bushism?)
>
> No, you're on safe ground. Now, if you had said
> contemporaneosity ...
> <g>
>
I'm glad to see your vocabularity experiencing some
contemporaneitification. <;->
-jn-
--
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[50/51] from: mtalbert:ebicom at: 17-May-2001 22:57
Ken, I am so new to Rebol, I am not even sure what it is, but your battle of
the semantics of discovery and criticism fascinate me since by profession I
deal in not the meaning of words, but the meaness of words. Every word has
two sets of definitions in a dialogue: the set of the speaker; and the set
of the listener, and unlike the rhetoric of a program either economic or
profligate as a microsoft update, their precision is non-existent.
comment ["criticism"] contructive
does not yield a cut and dried structure. Indeed the reciving communicant
can actully receive the communication in his own processing unit as:
beware ["asshole"] flatus
THere is no CCCC+++ in interhuman interpretation of commentary, it is analog
not digital, and results are generated by self-programming software open to
misinterpretation
[51/51] from: kenneth:nwinet at: 21-May-2001 20:12
From: "Mike Talbert"
> Ken, I am so new to Rebol, I am not even sure what it is, but your battle
of
> the semantics of discovery and criticism fascinate me since by profession
I
> deal in not the meaning of words, but the meaness of words. Every word has
> two sets of definitions in a dialogue: the set of the speaker; and the set
> of the listener, and unlike the rhetoric of a program either economic or
> profligate as a microsoft update, their precision is non-existent.
If your saying that attitude colors understanding then you have my
agreement.
Ken.
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted