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

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