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

Tuples - Was Pair! thread

 [1/33] from: robbo1mark::aol::com at: 6-Feb-2002 10:22


Holger / Joel / Everybody being following this thread with interest, is there any reason then why comparators should work with tuples?
>> 1.1.2 > 1.2.1
== false seems reasonable to me, but then again so do Joels arguments / logic, saying pair! are only meant to be used strictly in a Rebol/View pixel co-ordinate context seems like a cop out to me, either that or insufficient thought goes into REBOL language design & implementation, which is it Holger? Mark Dickson

 [2/33] from: jeff:rebol at: 6-Feb-2002 11:43


Hello, robb0l:
> seems reasonable to me, but then again so do Joels > arguments / logic, saying pair! are only meant to be used > strictly in a Rebol/View pixel co-ordinate context seems > like a cop out to me, either that or insufficient thought > goes into REBOL language design & implementation, which is > it Holger?
Hmm.. nice piece of flamebait. -jeff

 [3/33] from: joel:neely:fedex at: 6-Feb-2002 14:46


Here's one example, Mark: [Robbo1Mark--aol--com] wrote:
> Holger / Joel / Everybody > being following this thread with interest,
<<quoted lines omitted: 3>>
> == false > seems reasonable to me...
Aside from the generic argument that all built-in types should (IMHO) be allowed to participate in the widest possible range of primitive operations, consider the fact that tuples can be used to represent a wide range of concepts based on a small ordered sequence of small integers: section numbers (e.g., in a document) and IP addresses are the first two that come to mind. Simple lexical/dictionary order (compare first, second, etc. parts until order is established or equality is demonstrated by hitting the end of both simultaneously) serves nicely as an ordering for both of those. E.g., determining whether the IP address of a box lies within some assigned range of addresses requires that tested address be at least the low end of the range and at most the high end of the range. The fact that I can also use tuples to represent other concepts with quite different semantics doesn't change this fact; it simply means that I would need to raise my level of thinking above the "raw" data type level if I'm using tuples to represent one of those concepts. For example, tuples can also be used to represent colors -- for which there are a variety of useful orderings: lighter-than? darker-than? more-saturated-than? and so forth. But if that's what I'm doing with tuples, then I need to be thinking at that level and implementing those tests appropriately (or using code kindly provided by someone else who figured out how to do so and saved me the trouble).
> ... either that or insufficient thought goes into REBOL > language design & implementation ... >
NO! I think it is quite possible for persons of good will to have different views/priorities and to discuss those differences (even quite enthusiastically! ;-) without resorting to real or implied accusations of unprofessionalism. I freely admit to leaning strongly in the purist/perfectionist direction. However, I've done enough production software development to understand completely that highly competent developers who have specific practical goals, schedules, and various other considerations, may very well come to different conclusions than I might, and for totally wholesome reasons. My questions about ordering of pairs were stimulated by a confusing error message (which Holger quite readily agreed was not the best possible phrasing), but I continued the exchanges in the hopes of providing rationale for RT to reconsider the present state of the language WHEN THEY HAVE TIME TO DO SO, IF THEY EVER DO. And if they never do so, or (as has happened before on this list) RT considers a discussion and declines to accept an offered suggestion, that's OK too! Persons of good will can disagree and still continue to work together. I might also point out that -- over the years -- RT has been VERY GOOD about accepting discussion and suggestions from the folks on this list and acting on many of those to the mutual benefit (I hope) of REBOL, RT, and the REBOL community. I appreciate the attitude and track record of RT in this regard very much. I would like to think that we (list members) can use this list as a forum for discussions with each other and RT to try to understand (and occasionally make suggestions with the goal of improvement) this language that we all enjoy using. However, if my questions/discussion regarding language features are used as the basis for uncharitable accusations about the very folks that support this list and this community, I'll either keep my thoughts to myself or communicate offline with RT. -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;

 [4/33] from: carl:cybercraft at: 7-Feb-2002 21:02


On 07-Feb-02, [Robbo1Mark--aol--com] wrote:
> Holger / Joel / Everybody > being following this thread with interest,
So have I.
> is there any reason then why comparators should > work with tuples?
<<quoted lines omitted: 5>>
> either that or insufficient thought goes into REBOL language design > & implementation, which is it Holger?
I'd say neither, though it wouldn't surprise me if Holger thought his comments regarding View and pair! could've been better put, or at least more fully explained. (I wonder if you do regarding the above?) But anyway, let's rephase your first question: Is there any reason then why comparators shouldn't work with tuples? I'd think not, but with pairs there is a reason, in that it could be confusing. Tuples have a few common uses - as RGBs, version numbers, net-addresses and such, but they don't favour any of them (as far as I know). Pairs though do favour 2 dimensional coordinates and sizes as apposed to other uses of them, hence their x and y refinements. Given that, what should a pair comparison compare? Size? As in the area of two pairs? Well no, as we can at least check if two pairs are equal, and it says 3x2 isn't equal to 2x3. (No doubt someone's already pointed this out.) Coordinates? As in the distance from 0x0? Well, perhaps, even though I'd guess you're more likely to want to compare a coordinate with a point other than 0x0 most of the time. This would be useful sometimes, anyway. Or should it be treated like a series? I'd say no, as even if I needed a series of just two numbers, I don't think I'd choose a pair for the job. (How many of you have used pairs for other than coords or sizes?) My point here is that comparing pairs as if they were series is the least intuitive and probably the least likely use for comparing them, which to my mind is a good reason not to allow it. If pairs are to be compared then it should be as coordinates, as I think this is what you'd expect a comparison of pairs to be doing. All things considered though, it's quite easy to see why RT thought comparing pairs is confusing and decided not to support it. -- Carl Read

 [5/33] from: robbo1mark:aol at: 7-Feb-2002 3:41


HOLGER / JEFF / EVERYBODY After re-reading the tone of my earlier message I apologise if it came across as offensive and flamebait and please accept my apologies for this. However I still think the reasoning or justification Holger gave was flawed hence the tuple example I gave. Sorry for any offence caused and I'll try to ensure my future mailings are focused more on the issues at hand rahter than being misconstrued as flamebait. Is Pair! a lame datatype? cheers & sorry, Mark In a message dated Wed, 6 Feb 2002 2:59:43 PM Eastern Standard Time, Jeff Kreis <[jeff--rebol--net]> writes:

 [6/33] from: chaz:innocent at: 7-Feb-2002 13:45


>For example, tuples can also be used to >represent colors -- for which there are a variety of useful >orderings: lighter-than? darker-than? more-saturated-than? and >so forth.
The primitive operators '>, '=, and '< have very clear and unambigous meanings when applied to scalar values. Neither pairs nor tuples are scalar. That being said, I'd love to be able to sort colors. Imagine picking one of the recognized color solids, taking slices through it and sorting based on the slice that a color is a part of. Since there are several color solids, and many ways to slice them, perhaps the REBOLish solution would be to use the system object to explicitly specify which solid and through which axis one is slicing.

 [7/33] from: chaz:innocent at: 7-Feb-2002 13:55


After reading another of your lame "oh dear, I'm sorry if I offended anyone, how did that happen, excuse me for your misunderstanding me yet again", I realized how very sharply your posts stand out from everyone else's. Made me appreciate, once again, how very high the signal-to-noise is on this list. Thanks, Robbo, I guess. ----- Original Message ----- From: <[Robbo1Mark--aol--com]> To: <[rebol-list--rebol--com]> Sent: Thursday, February 07, 2002 12:41 AM Subject: [REBOL] Re: Tuples - Was Pair! thread HOLGER / JEFF / EVERYBODY After re-reading the tone of my earlier message I apologise if it came across as offensive and flamebait and please accept my apologies for this. However I still think the reasoning or justification Holger gave was flawed hence the tuple example I gave. Sorry for any offence caused and I'll try to ensure my future mailings are focused more on the issues at hand rahter than being misconstrued as flamebait. Is Pair! a lame datatype? cheers & sorry, Mark In a message dated Wed, 6 Feb 2002 2:59:43 PM Eastern Standard Time, Jeff Kreis <[jeff--rebol--net]> writes:

 [8/33] from: robbo1mark:aol at: 7-Feb-2002 7:29


okay charles, what you say is right. I guess I've been keeping my head down, studying, REBOL, Hardware, Maths, Assembler, buying a house amongst other things. I only really read Joels & ladislavs & maarten's posts usually as I don't have much time these days and I admire these guys and their signal to noise ratio is lowest on this list and the quality of their opinions, ideas & commentary are amongst the highest on this list and who's comment s I value. I also tend to read the RT folks posts but Iam ocassionally dismayed by the high handed "Nope We're right , your wrong" attititude they sometimes take in regards to what some users like myself see as inconsistancies or imperfections in REBOL as it currently is. Sure they're busy folks and they DO A GREAT JOB! if only they wouldn't debate REBOL with a Nixon type view of better to appear strong (tho' wrong) than weak and right. Right and wrong here are solely my interpretations of the discussions / debates I've seen on this list. Zero Indexing is a great one that springs to mind. But If it keeps people happy in future I will keep my opinions to myself. Best wishes everybody, keep on REBOLling ;-) Mark Dickson In a message dated Thu, 7 Feb 2002 5:27:21 AM Eastern Standard Time, "chaz" <[chaz--innocent--com]> writes:

 [9/33] from: greggirwin:mindspring at: 7-Feb-2002 11:25


Hi Mark, << Is Pair! a lame datatype? >> Nope, at least not IMO. For one thing, it can save lots of effort when scaling and sizing. Using them as direction guides for gradient effects seemed a little odd to me at first, but I got over that pretty quickly. They also make it very easy to write rectangle intersection and union routines. --Gregg

 [10/33] from: robbo1mark:aol at: 7-Feb-2002 14:29


Hi Gregg, I don't mean that the pair! datatype is not useful or attractive, it is for the reasons you outlined and many more. I have lots of ideas about pair like datatypes. Co-ordinate! 1.234x5.678 Complex! 1.234-5.678i Ratio! 1/3 However I don't get to decide what goes into REBOL ;-) My point is that by conciously deciding to disable the pair! datatype to be used with the greater than / less than comparator function, for the reasons Holger outlined, which i disagree with and are an unneccesary and artificial restriction in my opinion, then the pair! datatype is "lame" in comparison with some of the other numeric datatypes, tuple!'s as I gave in my example spring immediately to mind . But REBOL is RT's baby so it's really up to them, I suppose I can only keep working away to increase my understanding of REBOL and it's behaviour / implementation because I really do still believe in A better means of Expression, A better means of operation. I've no wish to open up the whole old open / proprietary debate again, so I'll shut up now. Cheers Gregg, Mark Dickson. In a message dated Thu, 7 Feb 2002 1:50:25 PM Eastern Standard Time, "Gregg Irwin" <[greggirwin--mindspring--com]> writes:

 [11/33] from: greggirwin:mindspring at: 7-Feb-2002 17:17


Hi Mark, << My point is that by conciously deciding to disable the pair! datatype to be used with the greater than / less than comparator function, for the reasons Holger outlined, which i disagree with and are an unneccesary and artificial restriction in my opinion, then the pair! datatype is "lame" in comparison with some of the other numeric datatypes, tuple!'s as I gave in my example spring immediately to mind. >> I can see things both ways. On one hand, we can say "we want all datatypes to support all operations", OTOH that may not be the best design choice and, if doing so severely impacted performance for the most common usage, or added bugs, we'd probably complain about that. :) I think it's RT's job, maybe their hardest one, *not* to give us everything we ask for. If they did, REBOL would become a language designed by committee and would suffer greatly for it, IMO. That's one of the reasons I'm *opposed* to them making it open source at this time. Maybe someday, when the language has matured, it would work but I'm not even sure about that. I'm a big believer in the power of conceptual integrity and that's hard to maintain in a large group, or even a small one. :) --Gregg

 [12/33] from: carl:cybercraft at: 8-Feb-2002 17:52


On 07-Feb-02, Carl Read wrote:
> Given that, what should a pair comparison compare? > Size? As in the area of two pairs? Well no, as we can at least check
<<quoted lines omitted: 4>>
> point other than 0x0 most of the time. This would be useful > sometimes, anyway.
Doh! Coords are the same as sizes, in that points can be the same distance from 0x0 but not equal. (:
> All things considered though, it's quite easy to see why RT thought > comparing pairs is confusing and decided not to support it.
Couldn't have put it better myself. (; -- Carl Read

 [13/33] from: m:koopmans2:chello:nl at: 8-Feb-2002 8:43


I agree with Gregg. The model of the benevolent dictator (is that correct English?) seems the best. See Linus(x) as well. --maarten

 [14/33] from: robbo1mark:aol at: 8-Feb-2002 4:00


Maarten / Gregg The good thing about benevolent dictators for example Linus Torvalds (Linux), Larry Wall (Perl), Guido Van Rossum (Python) is that they make their program / project source code available, that is why they are benevolent. Yes they strictly control and decide upon what goes into the "official" code base or release and that's where the dictator part of the title comes from. However with Linux, Perl & python, if some feature is missing or something doesn't work for you then you can change it or implement it differently yourself ( or pay someone to do it for you) and create your own modified version that works for you. These changes don't affect the "official" released versions but if they're useful and provide value then they may or may not find their way into the official code base if the benevolent dictator eventually decides to accept your patches, or not! THIS it aint so with REBOL, BUT I aint complaining about that. however I for one would much prefer it if Carl Sassenrath adopted the benevolent dictator model but Iam not going to hold my breath waiting. Best wishes, Mark Dickson In a message dated Fri, 8 Feb 2002 3:13:22 AM Eastern Standard Time, "Maarten Koopmans" <[m--koopmans2--chello--nl]> writes:

 [15/33] from: carl:cybercraft at: 8-Feb-2002 23:56


On 08-Feb-02, [Robbo1Mark--aol--com] wrote:
> Maarten / Gregg > The good thing about benevolent dictators for example Linus Torvalds
<<quoted lines omitted: 11>>
> official code base if the benevolent dictator eventually decides to > accept your patches, or not!
That may be fine for some software, but it isn't for a cross-platform, cross-Internet language. You can be sure that once people started rolling their own REBOLs the Net would fill up with scripts that weren't compatible with your version of REBOL.
> THIS it aint so with REBOL, BUT I aint complaining about that. > however I for one would much prefer it if Carl Sassenrath adopted > the benevolent dictator model but Iam not going to hold my breath > waiting. > Best wishes, > Mark Dickson
-- Carl Read

 [16/33] from: robbo1mark:aol at: 8-Feb-2002 6:43


Carl, what you say may be true if indeed people used non standard interpreters / protocols or whatever for REBOL or any other internet messaging & communications system. Of course you have to have an agreed standards & protocols otherwise the whole internet wouldn't function. Perl & Python both have internet functionality via modules & extensions, and tru they are not as natural & inbuilt or as easy to use as REBOL's however surely your not trying to say that because these languages are open source that they are not suitable for multiplatform internet communication / messaging are you? The internet is based on agreed communication standards and protocols & functionality regardless of whether your working in REBOL, Perl, Python, JAVA or Microsoft DotNet. Webservices & the executable internet will be totally reliant on open specifications & messaging standards non of this precludes "roll your own" or open source as long as you meet the agreed minimum standard. That's my opinion, which are more successful & gaining more traction Perl, Python or REBOL? I see new books & tutorials & resources coming out for these other languages all the time. I love REBOL and it's potential but i think it's losing the battle to become mainstream and part of the reason for that I believe is it's closed proprietary nature. We need REBOL to at least be specified, Sun at least got that right about JAVA. cheers, Mark Dickson In a message dated Fri, 8 Feb 2002 6:12:24 AM Eastern Standard Time, Carl Read <[carl--cybercraft--co--nz]> writes:

 [17/33] from: carl:cybercraft at: 9-Feb-2002 1:52


On 08-Feb-02, [Robbo1Mark--aol--com] wrote:
> The internet is based on agreed communication standards and > protocols & functionality regardless of whether your working in > REBOL, Perl, Python, JAVA or Microsoft DotNet.
I was talking about REBOL scripts, not Net protocols. Let's say you got your wish and REBOL was open-sourced and some here gave their REBOLs the ability to compare pairs for lesser and greater. Now, what's to stop them puting scripts on the Net that require those comparisons? It's a recipe for a mess. Like HTML and Javascript are a mess. When HTML and Javascript are updated, are all browsers updated at the same time? No, because they're produced by a wide range of competing factions. With REBOL we're currently avoiding that kind of mess and yet still getting it on a very wide range of platforms. I wish REBOL did everything I wanted too, but open-sourcing it would stop it doing what's most important, and that's being compatible across platforms. -- Carl Read

 [18/33] from: robbo1mark:aol at: 8-Feb-2002 8:32


Carl, with the greatest respect, I have to totally disagree with you here. When REBOl get's changed or improved or functionality is upgraded do all changes get upgraded across all platforms immediately? The historical answer is no! REBOL/View was introduced only on certain platforms which is still only increasing gradually across new revisions as and when RT can find the time to increasing /Views availablity. Similarly with /View/Pro & /Command & (/IOS whenever that is realeased) all have additonal features and functionality which mean thatREBOl scripts written for these targets can only run on certain platforms and not the full range which REBOL/Core currently supports. Just like HTML & Javascript and everything else you have to use the most up to date programs if you want to incorporate all the newest functionalities. Write Once / Run Anywhere is and always will be a terrific ideal and target to shoot for but this state of perfection is always an ideal and rarely a reality. In a REBOL context only achievable if your scripts stick to the lowest common denominator which is REBOL/Core and even then you have to specify which version of /Core your script relies upon. I've got old verrsions of /Core on my machines which will not run every script that Core 2.5 will. Programming is always in a state of flux between releases that is why in most languages you will find that the published "Standard" usually always lags a version behind the latest compiler / interpreter functionality & feature set. Automatic Upgrades can help to seamlessly upgrade to the latest version, security systems allowing of course, but this will never catch all systems everywhere and of course you don't need to be proprietary you incorporate automatic versioning and upgrade systems. Perl's CPAN provides this excellently. Old software exists and continues to be useful that is why it is so difficult to be compatible across all platforms unless you shoot for the lowest common denominator. This has got nothing to do with open source or proprietary software it is a logistical and practical distribution and versioning problem. Cheers, mark Dickson In a message dated Fri, 8 Feb 2002 8:13:43 AM Eastern Standard Time, Carl Read <[carl--cybercraft--co--nz]> writes:

 [19/33] from: joel:neely:fedex at: 8-Feb-2002 7:36


Hi, Carl, I must disagree with the assumption that open source software will "be sure" to fork. (I assume we're talking about the issue of random incompatibilities due to the uncoordinated fiddling about of various random individuals, and not the kind of version-to-version evolution -- and occasional lack of backward compatibility -- that every real programming language I've used during my 30+ years in computing.) Carl Read wrote:
> That may be fine for some software, but it isn't for a cross- > platform, cross-Internet language. You can be sure that once > people started rolling their own REBOLs the Net would fill up > with scripts that weren't compatible with your version of REBOL. >
The history of the open source movement doesn't bear this out. Instead of sending the impassioned pages of deathless prose that I was first inspired to write ;-) I'll simply point out that some of the most important languages and tools, and IMHO one of the most significant developments in operating systems in many years, are all open source. Perl, Python, Ruby, gcc, Linux, GIMP, gawk, gnu-make, emacs, vim, gtk, Gnome, Apache, ... Far from destroying these languages and tools, the availability of source has caused them to be ported to far more platforms than the inventors ever would have been achieve to do on their own, and debugged far more rapidly. Most of these use some combination of respected-leader-guidance, delegated-responsibility-network, and marketplace/democratic let-people-try-it-and-see-what-wins strategies to effect the evolution and maintenance of the software. Do people try out different, unorthodox, and even hairball ideas? Absolutely! But the open source community does a good job of distinguishing experimental/unstable/work-in-process releases/branches from stable versions that represent the collected wisdom, preferences, and QA of hundreds, thousands, or tens of thousands of eyeballs and brains. Serious developers also know -- assuming they want their work to be accessible to the widest range of users -- that they should be cautious about depending on uncommon features, libraries, etc. The wild-eyed crazies who go off in random directions trying to make their pet version of emacs scriptable in VisualIntercal++ are free to do so, but their gibberish isn't taken seriously. Unless, of course, it's really good, in which case it will gain enough of a following that it will begin to influence the addition of capabilities to the "official" version. But people still know which is which. That's called massively-parallel progress. On the other hand, the very nature of highly-extensible languages such as FORTH, Smalltalk, and REBOL tends to work in *exactly* the direction you feared. How many people on this list have a library (or two, ...) of their own favorite tweaks and functions and then write new code based on those extensions? How many experienced REBOL users have customized their user.r files? How many times have we seen: - A bug reported and someone responding with a fix of the form "here's a rewrite of that function; put this in user.r" ? - A posted script, followed by a post that says "It doesn't work on my box", followed by a post that says "Ooops, here's my foo.r" or "Go get so-and-so's quux.r"? and so on. Open source doesn't create such problems; it actually helps alleviate them because it's a more efficient mechanism for fast-cycling both the bug finding/fixing process and the rate of scrutinizing (and then adopting or rejecting) potentially useful new ideas. I truly believe that open source works, and is in the long-term best interests of the advancement of our art. Consider where we would be without a modern educational system, which is founded on the notion that one achieves value to society by creating new ideas (or new ways to express useful ideas) ang giving them away as rapidly and enthusiastically as possible. Consider the fact that students of architecture can learn their field by going and looking at all of the details of the design and construction of great buildings. Even in the failure of specific projects, there is value in openness. What if the design of the Tacoma Narrows bridge had been kept secret? How many more bridges might have collapsed (and with what potential loss of property and life) if the next generation of engineers had been prohibited from seeing both the design and construction of Galloping Gertie? All of that said (and aren't you glad I shortened it ;-) , I am a firm believer in the right of a creator to determine the fate of his creation. REBOL is Carl's baby, and he (alone!) has the moral right to decide whether he will make it available via open source or whether he wishes to keep it closed. Likewise, prospective users of REBOL (or any other tool) have the right to make their choices: either to invest their time and energy in a language that they know in advance is not an open source project, or to take themselves and their time and energy elsewhere. Either way, all parties should respect the rights and decisions of the others. -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;

 [20/33] from: m:koopmans2:chello:nl at: 8-Feb-2002 14:43


There is no link between benevolent dictators and success. There is no link between open source and success (Delphi, VB, ...) --Maaten
> Carl, > > what you say may be true if indeed people used non standard interpreters /
protocols or whatever for REBOL or any other internet messaging & communications system.
> Of course you have to have an agreed standards & protocols otherwise the
whole internet wouldn't function.
> Perl & Python both have internet functionality via modules & extensions,
and tru they are not as natural & inbuilt or as easy to use as REBOL's however surely your not trying to say that because these languages are open source that they are not suitable for multiplatform
> internet communication / messaging are you? > > The internet is based on agreed communication standards and protocols &
functionality regardless of whether your working in REBOL, Perl, Python, JAVA or Microsoft DotNet.
> Webservices & the executable internet will be totally reliant on open
specifications & messaging standards
> non of this precludes "roll your own" or open source as long as you meet
the agreed minimum standard.
> That's my opinion, which are more successful & gaining more traction Perl,
Python or REBOL?
> I see new books & tutorials & resources coming out for these other
languages all the time. I love REBOL and it's potential but i think it's losing the battle to become mainstream and part of the reason for that I believe is it's closed proprietary nature.

 [21/33] from: joel:neely:fedex at: 8-Feb-2002 8:28


Hi, again, Carl, Carl Read wrote:
> Let's say you got your wish and REBOL was open-sourced and some > here gave their REBOLs the ability to compare pairs for lesser > and greater. Now, what's to stop them puting scripts on the Net > that require those comparisons? >
Absolutely nothing. Except their own good sense and wish to have other people actually USE their scripts. (And my earlier post touches on the point that variations of this sort are *already* happening WRT various libraries that people base subsequent code on.) Why do we have to make the assumption that programmers must have a centralized, absolute control "to stop them" from destroying the universe?
> It's a recipe for a mess. >
I must disagree. Let's use me as an example. A few months back we had a discussion of zero-origin vs one-origin WRT blocks. There is absolutely nothing *currently* preventing me from writing my own custom definitions of AT , PICK , POKE , INDEX? etc. that use zero-origin design, putting those definitions in my user.r file, then writing code that depends critically on that choice of origin. And then posting that code to the list. Actually that's not correct. There's no *external*authority* telling me that I can't do so, but I am restrained by my own sense of ethics and my desire to have others use my work and take it seriously. If I kept posting such code to the list, I'd run the risk of confusing newcomers to the language, and causing them to waste their time, energy, attention, enthusiasm, and interest on code that they wouldn't be able to use (and might think was their fault or representative of the state of REBOL). That would be wrong. If I kept posting such code to the list, I'd get the reputation of being "that crazy zero guy" and regular readers of the list would simply ignore anything I posted. That would be detrimental to my ability to contribute anything meaningful to the REBOL community, which would make me unhappy. However, both of those hypotheticals assumed that I failed to provide appropriate disclaimers and explanation. Anyone should have the right to post experimental or demonstration code along the lines of "Here's what we could do if we had the foo feature" as a part of a discussion of how things might be done. By the same token, anybody who isn't interested in the discussion of the foo feature is free to ignore such discussions. IMHO it's just a truth-in-labeling issue. Let's not forget that Freedom of Speech is A Good Thing, but it also implies the equally important Freedom Not To Listen.
> Like HTML and Javascript are a mess. When HTML and Javascript > are updated, are all browsers updated at the same time? No, > because they're produced by a wide range of competing factions. >
You left out the important adjective "commercial". In the dog- eat-dog mentality epitomized by The Nameless Company From Redmond, one must introduce incompatibilities in order to lock one's customers into using only one's products, to the exclusion of all alternatives. One's value is largely determined by how much one can control other people's behavior. In the marketplace-of-ideas mentality of open source (and the entire educational system, I might add), there is the freedom for vigorous debate, exploration, experimentation, and difference of opinion, but the outcome is usually convergence on what works best for the greatest number of people. One's value is largely determined by how much one can contribute that others find to be useful to their needs and circumstances. However, the number of outright geniuses that can blaze brilliant new trail and accumulate a following is an incredibly small portion of the total community (and the community usually figures out who they are fairly quickly -- massively parallel processing works!) The bulk of the community are pragmatic folks who want to get a job done. They are motivated to stay with what has been shown to work well, rather than chasing the latest fad. Therefore their work tends to be portable and re-usable. And -- if it's open to the community -- others are usually more than willing to help them make it more so. I might point out that there's another variation on this issue; in a standards-and-interoperability-driven world, much of the energy of competition goes into doing the BEST job of delivering tools that conform to the standard, so that the consumer gets to make her/his own choices within the price/performance/features space. Having a published standard for residential electrical outlets (and then letting companies do their best to produce desirable outlets and extension cords) is IMHO a far more beneficial state of affairs than requiring everyone to buy their cords from a single manufacturer. Is that a perfect solution? Probably not, for most definitions of perfection. Does it always make everyone maximally happy? No. But as one wag remarked regarding democracy, "It's the worst system possible, except for all of the alternatives!" -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;

 [22/33] from: robbo1mark:aol at: 8-Feb-2002 9:37


Maarten, Your quite right that there is no guarenteed formula for success, however is will say one thing about the advantage of open source over proprietary software for software users. OPEN source software doesn't die with the company that produced it but thousands on proprietary programs have been orphaned when the producer went out of business or decided to no longer support it. Look at Eazel Inc. they produced a wonderful File/Viewer/Shell utility Nautilus for open source unix platforms. The company went out of business about year ago but the program & development lives on precisley because it is opne source. I agree with Joel Neely's recent excellent post and that I do not expect REBOL to be open sourced nor would I ever wish to deny RT their natural right to do as they wish with their software, I only offer my opinion ocassionally as to how they / we might help REBOL progress better as a technology. Bets wishes, mark Dickson In a message dated Fri, 8 Feb 2002 9:13:46 AM Eastern Standard Time, "Maarten Koopmans" <[m--koopmans2--chello--nl]> writes:

 [23/33] from: joel:neely:fedex at: 8-Feb-2002 8:43


Hi, Maarten, Maarten Koopmans wrote:
> There is no link between benevolent dictators and success. > There is no link between open source and success (Delphi, VB, ...) >
Let me suggest that there's not a single yardstick for "success". There are certainly some measures by which some people would call Visual Basic a "success". There are certainly different measures by which Perl is considered a "success". An open marketplace allows the consumer to use her/his own criteria to select the product(s) that meet her/his needs, rather than forcing all consumers to live with the criteria of a single authority. I consider that to be a system-level "success". It will be interesting for us to look back in ten years and see whether there are still languages called "Perl" and "Visual Basic" being widely used, and -- if so -- what resemblance they bear to the artifacts of those same names in 2002. But even long-term viability of a label is only one measure of success. Almost nobody uses Algol for serious development any more, but it placed a number of crucial computing concepts into play which are fundamental to current programming practice, thus earning for its creators significant standing in the history of computer programming. Almost nobody remembers the name of the leading wool merchant in London during the late 1660's, but almost every educated person around the planet knows of, and benefits from the work of, Sir Isaac Newton. How's that for success? -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;

 [24/33] from: rotenca:telvia:it at: 8-Feb-2002 17:47


Hi, Mark
> I see new books & tutorials & resources coming out for these other languages
all the time. I love REBOL and it's potential but i think it's losing the battle to become mainstream and part of the reason for that I believe is it's closed proprietary nature. I'm not sure this is the goal of RT in this moment. Are you? If this is the goal, from my point of view, RT has already been defeated. --- Ciao Romano

 [25/33] from: m:koopmans2:chello:nl at: 8-Feb-2002 18:07


Hi Joel, As a physicist I may add that computer science is in the stone ages compared to other natural sciences. Somewhere round 1500-1600 compared to physics. Wish there was a Newton available! Succes in this context ;-) was meant to evaluate to short-to-midtime survival via commercial success. Wouldn't want to call VB a success in any other way ;-) Now Perl is a different thing... --maarten

 [26/33] from: robbo1mark:aol at: 8-Feb-2002 12:43


Hi, Romano, What I mean by mainstream is that REBOL gains enough traction with users and developers that the market for REBOL products, be this interpreters, applications, books, tutorials, websites etc. becomes more active and self enforcing. Just a quick look at computer stores / magazines / websites / bookstores / IT emplyment opprotunities etc. is enough to show you that REBOL isn't barely noticeable even in relation to other new small time languages like Ruby. PERL, Visual Basic, Java, C, C++, C#, Delphi, Python, Javascript, HTML, even Lisp / Scheme / ML / Haskell have a more noticeable profile than REBOL and this hasn't changed much since 1998 when I first encountered REBOL. We had a brief period about two years ago when the 2 english language books came out, but nothing since then. At my local bookstore these two REBOL titles have sat in the clearance shelfs at bargain basement prices and still nobody buys them. News articles, books, conferences, new applications, upgrades, job vacancies etc happen for these other languages every other day / week / month. RT inc are doing a great job in advancing REBOL but they are a very small in terms of manpower and there is only so much they can do with the resources they have, that is why they could be considered a bottleneck as virtually everything major in relation to REBOL has to happen through them. Becoming multivendor and / or open source is the only way I can see REBOL ever taking off as a technology unless RT Inc are bought out by one of the industry giants who would then hopefully promote REBOL and give it a higher level of visibility and commit greater resources to it. None of these scenarios is by any means a certainty. I hope for the best, and try to increase my understanding of the multifaceted aspects of REBOL in the belief that someday I might in someway make a contribution to greater choice & growth of REBOL as a technology. cheers everybody, Mark Dickson In a message dated Fri, 8 Feb 2002 11:58:11 AM Eastern Standard Time, "Romano Paolo Tenca" <[rotenca--telvia--it]> writes:

 [27/33] from: m:koopmans2:chello:nl at: 8-Feb-2002 22:47


Hi Mark, I agree there as well, but.... Rebol is some ten years younger than most of the languages you call there. Maybe it just takes time. All of us see the potential of REBOL, yet so few of us release something to attract attention to it. My best shot was Rugby, but it sure is not good enough for that (or by now people would know). If only we would code and promote REBOL half as much as writing to this list..... but then again, why would we? --maarten
> Hi, Romano, > > What I mean by mainstream is that REBOL gains enough traction with users
and developers that the market for REBOL products, be this interpreters, applications, books, tutorials, websites etc. becomes more active and self enforcing.
> Just a quick look at computer stores / magazines / websites / bookstores /
IT emplyment opprotunities etc. is enough to show you that REBOL isn't barely noticeable even in relation to other new small time languages like Ruby.
> PERL, Visual Basic, Java, C, C++, C#, Delphi, Python, Javascript, HTML,
even Lisp / Scheme / ML / Haskell have a more noticeable profile than REBOL and this hasn't changed much since 1998 when I first encountered REBOL.
> We had a brief period about two years ago when the 2 english language
books came out, but nothing since then. At my local bookstore these two REBOL titles have sat in the clearance shelfs at bargain basement prices and still nobody buys them.
> News articles, books, conferences, new applications, upgrades, job
vacancies etc happen for these other languages every other day / week / month. RT inc are doing a great job in advancing REBOL but they are a very small in terms of manpower and there is only so much they can do with the resources they have, that is why they could be considered a bottleneck as virtually everything major in relation to REBOL has to happen through them.
> Becoming multivendor and / or open source is the only way I can see REBOL
ever taking off as a technology unless RT Inc are bought out by one of the industry giants who would then hopefully promote REBOL and give it a higher level of visibility and commit greater resources to it. None of these scenarios is by any means a certainty.
> I hope for the best, and try to increase my understanding of the
multifaceted aspects of REBOL
> in the belief that someday I might in someway make a contribution to
greater choice & growth of REBOL as a technology.
> cheers everybody, > > Mark Dickson > > In a message dated Fri, 8 Feb 2002 11:58:11 AM Eastern Standard Time,
Romano Paolo Tenca <[rotenca--telvia--it]> writes:

 [28/33] from: rotenca:telvia:it at: 8-Feb-2002 23:12


Hi, Mark,
> What I mean by mainstream is that REBOL gains enough traction with users and
developers that the market for REBOL products, be this interpreters, applications, books, tutorials, websites etc. becomes more active and self enforcing. Yes, I understand, and agree. But I'm not more sure that RT, in this exact moment, is working to arrive to this goal with Rebol. In this moment, and for now, i do not think that RT hope to gain "success" with Rebol. It was true some months ago, but now i feel that IOS is their main product. And IOS is a proprietary solution for small-middle-big companies who want to use the net for inner/outer connectivity. Rebol is the internal powerful language of this solution. It could be a necessary step, which permit at RT to find a solid base to start new projects (or remember the old ones). The only new about Rebol in these months is the Morpheus history (and Holger unofficial announce on new effect pipeline in this mailing). No new doc, no new how-to, no reference, no release date for new versions of Rebol, no visibility of future.
> Becoming multivendor and / or open source is the only way I can see REBOL
ever taking off as a technology unless RT Inc are bought out by one of the industry giants who would then hopefully promote REBOL and give it a higher level of visibility and commit greater resources to it. None of these scenarios is by any means a certainty. I think that RT hope to follow another strategy. From the faq of IOS: Is IOS free or commercial? IOS is an important part of our business strategy. We've given away more than a million copies of REBOL software over the last four years, but IOS is our commercial software. How to say: IOS is the way we make money, our main project. RT is becoming a service society, like IBM, hopefully like Sun. If Rebol could gain some success depends by the commercial success of IOS: more IOS systems, more Rebol programmers, more Rebol docs, more Rebol tools, visibility and so on. Today nobody (only Microsoft) can hope (without to dream) to break the market with a proprietary scheme like the Rebol's one, not when alternativies are free and not so bad, like Perl, Python, Ruby... But perhaps this can achieved when the product is something like IOS. It is a hope, not more, at least for me. I have already seen many excellent projects to go in the no man's land these years, to believe that the market always rewards the best ones (or its best idea is not mine).
> I hope for the best, and try to increase my understanding of the
multifaceted aspects of REBOL
> in the belief that someday I might in someway make a contribution to greater
choice & growth of REBOL as a technology. Adopt now Rebol IOS and hope. Market rulez! :-) --- Ciao Romano

 [29/33] from: joel:neely:fedex at: 8-Feb-2002 16:16


Hi, Maarten, Maarten Koopmans wrote:
> Hi Joel, > > As a physicist I may add that computer science is in the > stone ages compared to other natural sciences. Somewhere > round 1500-1600 compared to physics. >
There's no question that hardware advances have GREATLY outpaced our grasp on treating programming as a scientific discipline.
> Wish there was a Newton available! >
I'd nominate your countryman, Edsger W. Dijkstra, and an Oxfordian, C.A.R. Hoare, as two candidates for that role. Unfortunately, I am convinced that the true value of their work will not be recognized until many more years pass. Wasn't it Paul Dirac who was asked "When will quantum mechanics be the standard model in Physics?" and replied When all the old physicists die! ? ;-) -jn-

 [30/33] from: carl:cybercraft at: 9-Feb-2002 11:24


On 09-Feb-02, [Robbo1Mark--aol--com] wrote:
> Carl, > with the greatest respect, I have to totally disagree with you here. > When REBOl get's changed or improved or functionality is upgraded do > all changes get upgraded across all platforms immediately? > The historical answer is no!
If I remember the last upgrade correctly, they either nearly all or were all upgraded together. As an Amiga user I noticed this, as the Amiga version nearly always had been the last to be upgraded. Whatever, they were getting better and better at the upgrades in my opinion, and currently all Core and all View versions are at the same version numbers. Can you show me an open-source project on a similar number of platforms where that is the case? Where all versions are at the same version numbers /across platforms?/
> Similarly with /View/Pro & /Command & (/IOS whenever that is > realeased) all have additonal features and functionality which mean > thatREBOl scripts written for these targets can only run on certain > platforms and not the full range which REBOL/Core currently > supports.
True. How would open-sourcing REBOL stop that from happening?
> Just like HTML & Javascript and everything else you have to use the > most up to date programs if you want to incorporate all the newest > functionalities.
True, and the most up-to-date Cores and Views are available to all that want them on the platforms RT supports. Do you think that's the same with browsers within platforms, never mind across them?
> Write Once / Run Anywhere is and always will be a terrific ideal and > target to shoot for but this state of perfection is always an ideal > and rarely a reality. In a REBOL context only achievable if your > scripts stick to the lowest common denominator which is REBOL/Core > and even then you have to specify which version of /Core your script > relies upon.
So ignore trying for the ideal? I think there's general agreement that Core and View being seperate is a good idea, and in an evolving language, breaking some older scripts is inevitable as it's improved. (Unless that not happening is part of the languages design, which I think is in Perls's case.)
> I've got old verrsions of /Core on my machines which > will not run every script that Core 2.5 will.
Gosh. Just think, if they did RT wouldn't even have had to write 2.5! They sure got it wrong there, eh?
> Old software exists and continues to be useful that is why it is so > difficult to be compatible across all platforms unless you shoot for > the lowest common denominator.
I wouldn't say RT's shooting for the lowest common denominator. If they were, they'd be trying to use the GUIs that came with the OSs they're targeting. But they're not - they've designed their own GUI, which will allow them (and us) to have the GUIs of our desires, windows use excepted. -- Carl Read

 [31/33] from: carl:cybercraft at: 9-Feb-2002 14:03


On 09-Feb-02, Joel Neely wrote:
> Hi, Carl, > I must disagree with the assumption that open source software
<<quoted lines omitted: 4>>
> of backward compatibility -- that every real programming > language I've used during my 30+ years in computing.)
Yes.
> Carl Read wrote: >>
<<quoted lines omitted: 6>>
> Instead of sending the impassioned pages of deathless prose that > I was first inspired to write ;-)
Pah - you just broke it up into two emails. (;
> I'll simply point out that some > of the most important languages and tools, and IMHO one of the > most significant developments in operating systems in many years, > are all open source. > Perl, Python, Ruby, gcc, Linux, GIMP, gawk, gnu-make, emacs, > vim, gtk, Gnome, Apache, ...
Firstly, I'm talking specifically about cross-platform, cross-Internet languages. (See above.) How many of those with GUI support can you name that can run programs without modification across as wide a platform base as REBOL does? That you can do the likes of this with... do http://www.wherever.com/a-view-script.r and have in most cases no problems with it?
> Far from destroying these languages and tools, the availability > of source has caused them to be ported to far more platforms than > the inventors ever would have been achieve to do on their own, > and debugged far more rapidly.
Okay, let's assume REBOL's open-sourced. Now, it seems there's good reasons why RT hasn't put it on Palm, but being open-sourced, no doubt someone would try to port it to Palm anyway. Now, let's also assume they partially succeed, in that they get a version that sort of works, though it's restricted in what scripts it can run, and it doesn't function quite like REBOL should, so we're talking not just about a subset of REBOL, but a modified version. (ie, RT is right in that a real port isn't possible.) This they release as despite its flaws they think it'll be useful. If this became popular on Palms, you'd then get OS-specific scripts of REBOL appearing, thus defeating the cross-platform ideal.
> On the other hand, the very nature of highly-extensible languages > such as FORTH, Smalltalk, and REBOL tends to work in *exactly*
<<quoted lines omitted: 8>>
> on my box", followed by a post that says "Ooops, here's my > foo.r" or "Go get so-and-so's quux.r"?
Yes, but the fixes are in REBOL, not C, and don't require you to recompile your REBOL for them to work. These are just basic oversights and no different than forgetting to upload pic9.png and the like.
> and so on. Open source doesn't create such problems; it actually > helps alleviate them because it's a more efficient mechanism for > fast-cycling both the bug finding/fixing process and the rate of > scrutinizing (and then adopting or rejecting) potentially useful > new ideas.
I'm not criticising open-source in general, just the belief that it's a good idea for a language where you want the programs to run on as many OSs as possible without modification.
> All of that said (and aren't you glad I shortened it ;-) , I am > a firm believer in the right of a creator to determine the fate
<<quoted lines omitted: 7>>
> elsewhere. Either way, all parties should respect the rights > and decisions of the others.
Well said. And I do know the risk involved in puting my time and effort into a language that isn't open and which may go in directions I don't like. I consider REBOL's worth that risk.
> -jn-
-- Carl Read

 [32/33] from: carl:cybercraft at: 9-Feb-2002 14:50


On 09-Feb-02, Joel Neely wrote:
> Hi, again, Carl, > Carl Read wrote:
<<quoted lines omitted: 12>>
> a centralized, absolute control "to stop them" from destroying > the universe?
The assumption is based on experience, the experience being that the OS that's dominant will be where cross-platform software gets mostly tested and if it's found to run on that then it's assumed it'll be okay for everywhere else - or if it proves not to be, it's elsewhere where the problem lies. Good central control can almost make that second assumption true. Don't forget that one day a large percentage of the "programmers" of REBOL could be of the amateur web-designer type who now hand-code their own HTML. REBOL might be the only programming they've ever done, (they of course starting with VID), and if their scripts work for them, that'll be good enough for them to place their scripts on the Net. REBOL's very like HTML in my opinion, (why else do we have a "reb"?), and I'd hate to see it go through some form of browser war. "At least the bugs are cross-platform" is a comment one of my REBOL scripts received. I want it to stay that way. (Big snip of the rest of Joel's comments - but all read. Oh, and the wag was Winston Churchill, Joel.) -- Carl Read

 [33/33] from: robbo1mark:aol at: 10-Feb-2002 14:17


Carl, I agree with what you are saying in your post and Iam not saying open source REBOL would solve these problems because as the main thrust of my post was that these problems highlighted have nothing to do with source code availability they are practical & logistical distribution & upgrade problems. My post was made to assert these points in reference to your initial mistaken (mistaken in my view) that open source REBOL would lead to a total mess in these areas. It wouldn't help nor hinder becuase these same problems would appear no matter what the development model is, open or proprietary. Your initial point that open source would directly lead to this "mess" was at best misleading and at worst complete FUD. (Fear, Uncertainty & Doubt) But Iam sure we've all beat this subject to death over the last few days. cheers, Mark Dickson In a message dated Fri, 8 Feb 2002 5:32:41 PM Eastern Standard Time, Carl Read <[carl--cybercraft--co--nz]> writes:

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted