REALLY DISCOVER THE POWER OF REBOL

is for those of us language buffs sufficiently intrigued by the internal workings of REBOL is to develop our own REBOL Interpreter. WHY ? 1. To further our understanding of REBOL's inner workings. 2. To experiment ourselves with various implementation features. 3. To provide a REBOL for use on DEBIAN & free software systems. 4. To ensure the protection of REBOL language from corporate control or abuse or neglect, i.e. The AMIGA fiasco's / sad stories. 5. For the fun of it!. Carl stated in the past on of the reasons REBOL would not be opened sourced until much later would be to prevent fragmentation. This would be the prime directive of OSCAR if it goes ahead, All official user releases must look like REBOL, smell like REBOL & for all intents & purposes mimic REBOL behaviour as best as possible. This need not deter experimentation, if fact useful new development features could be sent to REBOL.com for consideration & possible inclusion in official REBOL releases, however that is much later in the game. Firstly those of us interested enough need to harness our knowledge skills & expertise of compiled programming languages like ANSI C or Modula-2 / Pascal or SCHEME etc to discuss & develop an interpreter for a small subset of REBOL/Core, probably the natives!, datatypes! & operators! from which everything else is built upon. However I digress, those sort of discussions are for the OSCAR project to decide, the purpose here is to stimulate opinion, enthusiasm, critique & hopefully momentum for such a project. Project 2 - REEMACS REEMACS Rebol Extensible Environment MACroS REEMACS Rebol Engineered EMACS REEMACS Rebol Engineered Environment Makes Advanced Computing Simple As the name suggests the intention here is to create an advanced extensible editor & environment written entirely in REBOL built on a REBOL interpreter. View GUI versions & Command versions could be developed later. REEMACS would be an advanced editor & environment extensible with REBOL functions, macros & scripts, in the spirit of Richard Stallman's GNU EMACS but bettered by applying REBOL human-centric principals & features including a more intuitive & easy to use interface whilst retaining all the power & flexibility that REBOL provides. In short REEMACS would be a state of the art Editor / Environment for the 21st Century including; * Advanced Text Editing & Formatting * File & Directory Control * Diary & Calendaring * Email & FTP * Language Syntax Highlighting * Documentation & Help * Everything else not yet thought of....... As above the intention here is to stimulate interest & discussion about a REEMACS project and call to arms for those REBOL Coders looking to show off their REBOL skills on a project that can harness & collate the combined skills & scripts of the REBOL Community to provide a generally useful REBOL Utility. There is no reason for REEMACS not to collaborate with other on going projects such as REBMAIL to produce a world class REBOL application. So there you have it OSCAR & REEMACS, they are my suggestions, now Iam looking for your responses. I would be obliged if all comments & discussion could be kept to this list & all replies sent to [list--rebol--com] and not to me personally. All the best, Mark Dickson

-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 We are what we think. All that we are arises with our thoughts. With our thoughts, we make the world. --Buddha

No problem, my preference actually. Here is my rebuttal: Does Coka-Cola handout thier recipe? Nope. Does Pepsi have the recipe to Coka-Cola? I am sure they have it figured out. But if Coka-Cola handed out thier recipe from day 1, do you think Coka-Cola would be what it is today? Maybe, though maybe not. Given the fact that REBOL has been around for 3 years, we could roughly estimate it would take the same number of excellent programmers the same amount of time to complete the task. This delay is the protection. When (if) it becomes appearent to the larger companies that REBOL's business plan is successful, they will look into doing such a thing themselves (monkey see, monkey do). Recreating an open source implementation is like taking a test with the answers on the chalkboard. In such instance, I would guess that a REBOL competetor could be made within a year, quadruple the number of programmers, within 6 months. 6 months and a good marketing campaign could easily capture "first in mind" from REBOL, the chess equivelent of check--with REBOL likely bieng outnumbered. Sure there are Coka-Cola fakes out there, but they're not the real thing. First in mind is an important marketing law, especially so when dealing with languages. This is why I think we should let things play out a bit longer before showing everyone how its done. --Ryan Veitchi Edinburgh wrote:

-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 We are what we think. All that we are arises with our thoughts. With our thoughts, we make the world. --Buddha

showing everyone how its done. Python, PHP, MySQL are all wildly popular, and Open Source. No mammoth marketing team has swept in and taken them over. Your arguments might sound reasonable to suits who don't know any better, but the software marketplace doesn't actually work that way. In practice, very few Open Source projects ever splinter. The people smart enough to make them splinter are smart enough to keep that from happening. Things like Javascript have splintered badly, but that's because they were not Open Source, and vendors implemented their own closed source in different ways. All that happens is that people like Elan, Gabrial, Lemir, and Joel don't waste time ruminating about how REBOL is implemented. Rather, they can contribute working code to the project. Carl would still control what goes into the kernal. But Carl doesn't want that to happen, and so it won't. Pity, because it might free up some of his developers to create real-life reference applications, and then maybe more people would put REBOL to work. -Ted.

are the biggest bottleneck to the future direction & speed of development of REBOL, as a language & technology. Personally, I believe the real bottleneck is REBOL Corporate's refusal to provide an industry-standard support systems for developers. The lack of a bug list and knowledge base is inexcusable and unrealistic. Heck, there's not even a formal specification of the language. The documentation is fair -- even good when Carl writes it himself. But for ongong support, all that's provided is a entry-level mailing list with a short-lived archive. The new Command Care script shipping with /COMMAND looks like a step in the right direction -- but where's the /VIEW version? There's a lot of glitz on REBOL.COM about Express, which would be cool IF IT EXISTED! Of coure this is probably why there are so few ready-to-run real-life REBOL applications shipping today - what is there? Vanilla, News Site, and Elan's DBMS. Otherwise, the example being set is that REBOL is a fun toy for quick and dirty puzzles, and that's all anyone seems to write. Even many of the samples are just underpowered clones of other softwares. (Take SELMA for example.) And here we go again, let's write another REBOL interpreter; let's write a EMAC's clone, let's write an email client. Hey, we got those already, let's move on. I know this seems harsh, but I do believe in REBOL, and I would like to recommend it to my clients for paying work. But I'm having trouble seeing the emporer's clothes. My development schedule, including overtime, is booked through November, but if I were going write something in REBOL, I'd start with a Web site control panel, or an enterprise portal, especially ones that looked great in a browser and fantastic in VIEW. Still new ground to cover on those fronts. -Ted.

developers because a closed source product can be taken away as quickly as it is given. It's kind of like not wanting to commit to a relationship with someone who hides things from you. This is how I perceive this behavior, at least. That's very true Ryan. Once a product sucessfully goes Open Source, many of us believe that it is now here to stay. Many products which have not gone Open Source (like Mini-SQL for example) die when the developer loses interest, even when the product has a loyal following. I also see the terms "standards-based" and "open source" becoming strongly linked. Many people in the industry have finally come to realize that the development of a product is only the tip of the iceberg. The real investment (Cost of Ownership) is with training, integration, customization, and maintenance. Many people are much more willing to make that investment when they know the source for the product cannot be taken away. /COMMAND is a good example. My business decision isn't about whether the library costs $300 up front, it's about whether I want to pay someone $300 a day to build something with it. -Ted.

a viable alternative. In real life, it's never been about which platform is better, it's always been about which applications are better. Java was ignored for years (ironically, the years when we needed it the most), until Sun finally wrote a browser with it. That was the proof of concept that pulled Java up by it's bootstraps. It's not enough to roll out the barrel, you have tap the keg. Express could easily do this for REBOL, if it ever ships. But something like it should have been done already. The RT team has poured out dozens of sample scripts demonstrating useful snippets, but what's really need is actual working applications. Successful language vendors have often bundled fully functional text editors and databases with their packages, or worked closely with tool vendors who write "the rest of the language."

application development as RT's responsibility, feeling REBOL itself could be maintained by the open source community. With the proper support structure, this community could definately help with the development of REBOL, and release some of the paid staff for other work. But I sincerely doubt that REBOL Corporate has the proper mindset to make open source work for them. Heck, unlike everyone else in the industry, open or closed, they can't bear to publish so much as a bug list. -Ted.

And making REBOL open source would likely lend to its popularity as well. But, as far as I know, Python and PHP are not businesses. Although, If I remember correctly, MySQL is a business, free for non profitable use or something. I would expect its biggest competitor to be PostgreSQL, which is ironic to me. It would be interesting to know how the? You also make me think of an interesting question, could making REBOL open source actually scare away big business competition?

I agree there are many benefits, but so far I see it being dangerous if done before "first in mind" has been well achieved. Also, I remind you investors scare away easily--No matter how nice the rocket, you still need fuel to launch it. Speaking about first in mind, REBOL could achieve this easier if they do more to introduce themselves as an entirely new class of programming languages (divide and conquer). This has had subtle mentions here and there, but no phrase sticks in my head. I might mention something to that effect on top every piece of company literature. --Ryan Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 We are what we think. All that we are arises with our thoughts. With our thoughts, we make the world. --Buddha

Hi Ted, You are starting to sound a little disheartened in your recents posts.. :-( Since money is currently to be made in writting custom solutions in REBOL, it is not surprising that many of the REBOL apps don't see the public light of day. With the usual contract I.P. clauses and lack of source code hiding, it would be foolish (and often illegal) for many of us to publish those apps openly to the web. ;--- If something gives a company a competitive advantage, they try not to tell their competitors about it. ;--- Now with /command and Ralph's forthcoming e-commerce book, REBOL for server-side db work will be easier to pitch. I would expect to see growth in this area over the next year (can we do ssl? though). If we had the ability to compile code / or hide source in distributions, it would help spur the development of 3rd party add-on industry and the off the shelf apps too. In terms of not having a knowlege base of known bugs & issues, I think that with people paying for support contracts, a knowledge base will be something RT will have to address/provide. It would be a cost effective mechanism to reduce the support load. Cheers, Allen K

It would be interesting to know how the? Excuse me. What was going to say is it would be interesting to know how the market place evolved. --Ryan

profitable use or something. They were on the fence for a while, especially as to the NT version, but it did go full open source this year.

Until today, when COMMAND shipped, neither was REBOL. Though the point was if the theory of the opportunistic marketer were valid, it would have happened already.

open source actually scare away big business competition? Definately. But it's a moot point. REBOL couldn't handle open source.

The glib answer would be: open source, survival of the fittest; closed source, survival of the richest. -Ted.

posts.. :-( Oh, I've always been a little cranky, just haven't been posting as much. The sad part is I'm still saying the same things I said a year ago. My concern is that people get so excited about REBOL as a language, they overlook its basic needs as a competitive product. It would be nice to see thoughtful, efficient design actually win for a change.

server-side db work will be easier to pitch. I would expect to see growth in this area over the next year (can we do ssl? though). Actually, what first attracted me to REBOL was an article that mentioned someone who was doing all their ecommerce applications in REBOL. See relatively few posts about this sort of thing though. Though, I think most of the people who would use REBOL for eCommerce don't have access to an ODBC or Oracle database. I'd like to see the marketing research on that decision.

distributions, it would help spur the development of 3rd party add-on industry and the off the shelf apps too. Maybe. But PHP and Perl don't have this, and apps are legion. Meanwhile, Java does have this are apps are relatively sparse. Realistically, I think the biggest difference is probably Apache Mod support. The Java apps seem to be waxing with the solid progress they are making with Apache support. So if /APACHE every ships ...

REBOL, it is not surprising that many of the REBOL apps don't see the public light Be interesting to at least see some of these listed on people's resumes, or a developer's exchange on REBOL Web site. It's also commonplace for a developers to write a general version of a custom application, or to customize a general app, but we don't seem to see much of that either. -Ted.

PERL was created awhile before Java, and I would expect had "first in mind" to many of us for many categories, CGI, script language, *n?x programming, internet programming, and maybe even cross platform. Java came in later in the game, successfully aquiring the cross platform category, but too late and under equiped to gain popularity anywhere else. Such as my father always says, "a day late and a dollar short." Now Java has just recently overtook Visual BASIC as the most widely used programming language in the world. I must attribute its success to many factors, the primary of course being it "owns" cross platform, but arguably the secondary factor is the fact its compilable. All that hype did'nt hurt either. --Ryan Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 We are what we think. All that we are arises with our thoughts. With our thoughts, we make the world. --Buddha

platform category, but too late and under equiped to gain popularity anywhere else. Such as my father always says, "a day late and a dollar short." Java was actually developed and available for many years before it became popular. My point is that it became popular when Sun used to to developed a working browser. And bang ... it took off. That's what REBOL needs, a useful application that people can point to and say "it works!"

mind" to many of us for many categories, Again, my point here is not being able to hide the source hasn't stopped people from developing killer Perl applications.The fact that Perl is ridiculous and ugly didn't stop them either. What started them is that Larry began by writing useful, working applications, and people followed his lead. In contrast, Carl began by writing very cool test programs, and so that's been the REBOL status quo ever since. A good example is the List Archiver at REBOL.ORG. It uses some very cool technology, which I barely understand, to archive and index the messages. Unfortunately, the script is quick and dirty, and difficult to abstract into a toolkit or port to another site. Which is a pity, since it could easily be used to archive any type of email, not just the REBOL list. -Ted.

I´ll second to that Ted... Sharriff Aina med.iq information & quality in healthcare AG Gutenbergstr. 42 41564 Kaarst tel.: 02131-3669-0 fax: 02131-3669-599 www.med-iq.de

They dont have to be. PHP and python programmer, as well as perl programmers, make money on making applications with them. The same developers who code PHP/Python/perl are the same people who create applications with them. That's why it works so well. -- kolla

spreading FUD? (Fear, Uncertainty and Doubt) ;-) I know you're kidding me Jeff, and that you and the others in the trenches are doing your best, but, since the door's been opened, I might mention that REBOL's tendency to pre-announce products has created a lot of FUD around here. While /COMMAND was simmering no one wanted to work on other DBMS connections (like say hooking up to MySQL via TCP). Likewise with the pre-announcement /EXPRESS, independant developer's aren't going to want to work on something like that either. I'm sure that is not the intention, but it is the effect. And, I don't think it's FUD to offer candid advice with specific suggestions for change. His Majesty's Loyal Advocate, -Ted.

ruminating -- Wow! I though I was just guessin' ! ;-) -jn-

Naw, my intention was not to rebuke your efforts toward calling it as you see it. Just the feeling was a little demoralizing and ominous the way it comes across on my side of the screen--

We are all the new Jedi knights of the computing world and we must not turn to the darkside! As say Master Yoda: "Fear leads to anger, anger leads to hatred, hatred leads to suffering!!" :-) :-) ;-) -jeff

-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 We are what we think. All that we are arises with our thoughts. With our thoughts, we make the world. --Buddha

It works very well indeed, but my point is subtly askew. Essentially by your logic Python and PHP are money making operations by those who use them, who are often the same people who create them. REBOL is a money making operation for RT, its investors, and hopefully its users. And yes, it is also a outlet for Carl and other RT staff giving them a great sense of fullfillement in life. Albeit, thier are strong arguments for open source REBOL, but I remind you that my position is that it is a dangerous move at this time, and dangerous does not does not mean it will turn out bad, it means it has the potential to turn out bad. To the best of my knowledge, it is relatively unproven business model. I am not saying it would fail, and I could easily argue its success, but from a current investors point of view, it is just too dangerous. If RT is covered in the money area, and thier is evidence that open source would scare away big business or have at least a nuetral effect, then I would say go for it. Going open source would surely boost popularity. I just think in the current tech money market thier is not alot going around, plus at REBOL's youthful stage, combined with some uncertainty in the programming language of the future, releasing source could be very dangerous. Its a one shot deal, and I believe that its a risk that should'nt be attempted unless it became clear that popularity was sagging. When REBOL becomes popular, or at least widely enough known, releasing source could be done more safely. I know its strong temptation, a quick fix to the popularity issue. I suppose if RT had lots of money, it could release the source and use that as a spring board for an add compaign to grab "first in mind" before any competition could catch up. But, If they had lots of money they could just go with the add campaign, topping it off with a source code release if needed. Or they could just spend the money making better products? --Ryan Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 We are what we think. All that we are arises with our thoughts. With our thoughts, we make the world. --Buddha

There is nothing done yet, so that if some of you want to join me please contact me. I can't offer to do any coding right now, but here's a description of my favorite collaborative dreamware. -- In essence, this application would act like like dmoz.org hooked up to hypertext articles, rather than just links, with the same group editing features dmoz provides for just links. Objective Collect, organize, and maintain a collection of hypertext documents via a HTML browser or SMTP/POP3 email. Audience Knowledge workers connected by a network, already familiar with Internet browsers, portals, and search engines. Requirements - Knowledge Base The knowledge base allows people to create and update articles. The articles are submitted as plain text and converted to HTML. An advanced version allows articles to be formatted according to a template and include various CGI components. Allow text articles and one standard image to be submitted by browser or email. Track article title, ad-hoc and standard keywords, original author, creation date, last editor, edit date, edit history Save articles to HTML files + Title, meta keywords, link to author profile, edit history + Email comment form to author and editors + Back link + Convert HTML meta characters to macros (< >), et cetera Parse saved articles into component fields for editing or indexing Allow author and authorized editors to add target and anchor links to article, when available Create and update author profiles by browser or email Allow new author registration and first article submission as an unified transaction Hold new submissions to queue pending approval by editor Allow updates to article by original author or authorized editor Grant editor rights to an author profile Track articles authored or edited with each profile Full-text search: Responsibility of Web site. Organization by topic: Responsibility of Article binder. Possible Refinements Store articles in alternate format (database, XML / RDF ), and generate HTML pages upon request Maintain companion annotation/history pages linked to main article + May be enabled by template (infra) Allow for submission of multiple images Full-text/keyword search of articles Plain-text formatting of simple HTML elements ("pidgin HTML") *bold* - _underscore_ - ~italics~ - :hot zone: {target} (anchor) bold - underscore - italics - hot zone {{ A: [block] }} - no evaluation - fixed font [heading]:1 {target} (anchor) | col | col | Create articles with various layouts or features based on templates. The template would determine both the input form (by the browser) and the display format (as an HTML document). Knowledge Base | Author Profile Job Postings | Resume | Employer profile / Classified ads Link Directory / Article binder (hint) Common CGI components (some may require registration with a cron script) + Time/date stamp + Guest books | Link Lists | "Talk Back" replies + Email response forms | Confirmations + Email page to reader + Exams | Surveys (Rate it) - - Optional real time tallies + Table of contents (from anchor page to target links) + + What's new index + Blue sky | Kitchen sink - - Includes | Scheduled includes - - Display or comment block - - Variable substitutions - - Hit Counters - - File uploading / downloading - - Shopping carts - - Managed banners - - Slide shows Requirements - Article Binder / Link Directory The article binder allows people to organize hypertext documents into a hierarchy, and also generates alphabetical and chronological indexes. When someone is authorized to edit a topic in the heirarchy, they are also authorized to edit its sub-topics and the associated articles. An advanced version also provides for other features to be associated with topics in the hierarchy, including email, remote updates, and secure viewing of topics or articles. An important feature is that articles can be associated with more than one topic in the hierarchy. Index articles into a hierarchy, with headings and sub-headings Allow articles to appear under more than one heading or sub-heading Authorize editors by heading and sub-heading, with rights for a heading descending to its sub-headings Create hyperlinked heading index in HTML + Top-level headings / Heading and sub-headings for each top-level Create hyperlinked alphabetical index to articles titles in HTML Create hyperlinked author index to articles in HTML, with public portion of author's profile Possible Refinements Email new articles to list of subscribers by heading, or heading and all sub-headings + Articles only; Articles and Replies. + Viewer-only registration / email address Route replies to author and editor, and (optionally) other subscribers Smart update of remote Web site from local machine + May disallow default updates by Internet mail or browser Allow for updates to mirror sites (complete hierarchy or selected branches) Merge and delete articles between binders Secure (members-only) headings or articles Links to off-site articles + Meta-link option to allow update of URL and/or description for entire hierarchy + Or, URL search and replace? Constraints Must be cross-platform + Available to any client platform with a HTML 3.2 or later browser + Run through any popular HTTPD CGI - Apache, IIS, et cetera. -Ted.