Carl's REBOL Blog - Vive la REBOLution

Our primary goal remains the same: to move the project from the "lab" and get it out to more developers in a structured and organized way. ---During December *We released seven new R3 versions, alphas 19-25, each with various bug fixes and improvements. *The first two weeks of the month were focused on fixing various problems related to windowing, graphics, text handling, scrolling, and auto-scrolling. *Clipboard (cut and paste) device was re-integrated into the system, now with support for Unicode clips. *New documents continue to be added to the DocBase wiki. Guidelines for alpha testers were updated and notes about source code contributions were posted. *Mid-December serious work began on solving what we call the "Developer Forum" problem. That is: how to get the REBOL community all on to the same communications channel. I've written a lot about this problem in my blogs (for example, Better Developer Communications), so I won't go into the details here. *This project has the code name RebDev, and for the last two weeks it has had my full attention. The RebDev server is now up and running and achieves the messaging objectives. A full description of RebDev features posted on the wiki. *In addition, the first client for RebDev was built using R3 itself. This first client was a CLI (command line interface) version of it. It allows users to access the full range of discussions directly from the R3 console. This client also helps prove and test R3 itself. The CLI client is useful in another way too: its same core functions can be used to write small scripts that help automate parts of the messaging system. For example, "provisioning" the server with its initial topic structure was accomplished with a short script. In the future it will also make it easy to do things like auto-post messages when a bug is marked as fixed. You get the idea. *And finally, as a test of concept, I wrote a small web mobile phone interface so I can now browse RebDev messages from my iPhone. The "show me what's new" feature is of key importance to me. More work can be done on this during January (hopefully by someone other than me.) ---Plans for January Last month I described my "perfect picture" of what needs to happen. We achieved a lot over the month and will push forward toward completing that picture during January: *Release R3.0 alpha to the larger development community. *Setup the R3.0 download URL and provide a sensible auto-update mechanism. *Move to RebDev as our primary communication channel. We will do it in stages, just to be sure it all works as intended. *Combine DevBase and RebDev. This merges our source file version management into our multi-sectioned threaded messaging system. *Implement the RebDev/DevBase R3 GUI client. *Merge developer-contributed improvements including Henrik's work on the GUI and Brian's improvements to mezzanine functions. My hat is off to them in appreciation of their accomplishments. *Continue with bug fixes and general development. Also, if time permits: *Begin REBOL.com website revisions in preparation for R3.0. This is just a start. *Module system See last month, and I hope more can happen this month.

I wish you the very best for 2009. Be sure to make 2009 a great year, in whatever way counts in your life, family, and business. Personally, I'm glad 2008 is over. It was an unusually difficult year in so many ways. It's funny isn't it, the character of each year? It's just a symbolic representation, isn't it? On with 2009, and let this be the best ever. And for REBOL 3.0, let's move forward at light speed toward realizing our visions, plans, and dreams.

Here's a nice little REBOL forum that I should mention: Forum REBOL, powered by RebelBB. It's mainly a group of French speaking REBOLers, and since learning French has been a hobby over the last couple years, it's interesting and a challenge for me. The members have been kind regarding my awkward posts, and I appreciate the feedback. I know I have a long way to go to perfect my parlance. Of course, if you don't read French, then the forum script itself may still be of interest. It is an open source (GNU) bulletin board with an IMAP back-end, written in REBOL of course. The source code for RebelBB looks clean and tidy, easy to read, thus making it easy to modify for your own needs. Anyway, it's always good to see sites like this, and I'll try to make time, between so many projects, to drop in and say bonjour.

An old REBOL friend recently suggested I use Twitter to post messages about R3 progress. I thought about it for a bit, and it seemed like a good idea. After all, I want to communicate more, and I like things that help make REBOL more visible on the web. If I can do both at the same time, then it seems like a win. So, last week, I visited Twitter, but the site was down. Then again, as I began writing this blog, I checked Twitter: "Server not found." Maybe that's a message of some kind? It prompted me to Google "twitter down" -- the results of which made me rethink my Twitter strategy. Sorry, I'm not bashing Twitter. The idea of "What are you doing right now" is a feature I implemented in REBOL/IOS seven years ago... just to help organizations and their members keep track of each other's status. It's useful. But, with Twitter twitching like that, let's just say it was a nudge to think more deeply about what I really wanted. My goal is to communicate more about what's going on. It's really that simple. Certainly, using a "featherweight" method for doing that is handy. If it only takes a minute or two, then it's more likely I will be inclined to keep it up-to-date. Putting the "feed" somewhere like Twitter may be nice, but it's really not critical. I can trade the "make REBOL more visible over big public websites" objective for "keep the community more up-to-date on progress, but without a hassle." Do you agree? And, in the end, if I keep my messages short, posting to this blog and/or the 3.0 Frontline isn't going to be any more difficult than Twitter.

As you know, REBOL uses .r as its script and data file suffix. This is done by convention. It is not an enforced rule. That is, you can use whatever suffix you want; REBOL does not care. You can evaluate a .txt file as a script and that works fine. Of course, the suffix is useful within the context of an OS -- for general identification of the file type, such as within your favorite text editor. In most OSes it also associates the icon and default action. So, in order to avoid problems between R2 and R3, I am considering changing the suffix. And, such a change will also help on systems that use .r for other files types. However, it might create some problems for HTTP server downloads, MIME type, etc. But, those should be solvable. What do you think?

Look, bottom line: REBOL makes me productive. And, to me, productivity is everything. That's why I write and use REBOL. That's why I keep writing and using it. I'm not a techie. Maybe you think I am. No... I live in the mountains. I plant Redwood trees, grow grapes, make wine, learn French, watch the wildlife (the coyote, deer, and a lot of wild turkeys this week), the fog, the sunsets. I seldom leave the ranch, maybe to play tennis. I watch the antics of the world from here - the news feeds, as many as I can find. =image photos/coyote-nov2008.jpg I like useful things. I like systems I can control, shape, and put to work. Small systems. Smart systems. Don't give me a 500MB software program if a 1MB can do what I need, or even better, 10KB. You know, I have to face up that in most regards, I've lost productivity over the last decade. These days, for me, computers seem to create more problems for me than they solve. And oddly, when I look around, most businesses and families seem to have those same problems with their computers. I think back to 1998... when computers actually worked well for me. I wrote all my docs, created my diagrams, built web sites, created necessary web images, managed spreadsheets, sent faxes... from a fine little Apple Macintosh of that era. (I know that some of you want me to say Commodore Amiga here, but remember I worked in development at Apple Computer too.) Well, I really don't want to tell you what I use these days. It's not that I haven't kept up, it's that I'm tired of managing office suites, multi-gigabyte software packages, messed up installations, dealing with incompatible libraries, fixing registry conflicts, on and on. What's up with computing? It's suppose to make us more productive, isn't it? I don't mean more productive fixing our computers, I mean more productive making products, offering services, or enjoying our lives. I don't have time for modern software. Every hour of my day needs to count for something. I spend my time making things, writing, building... not repairing my computer or updating endless components to make Bill richer or Linus cooler. Well, ok, maybe I sound like I'm getting old. Maybe I am? But you know, a mattock pick and a Winchester 1894 lever-action 30-30 are still useful and elegant tools. Time has not changed them. Bill has not improved on them. Linus has not reforged them as free. Look, small systems are better systems. Period. Don't tell me how your 12 layered software technology can do great things. Maybe it can, but next week it will crash. For me, that many layers says it's a broken design, not a better design. It's like credit default swap financial derivatives. Wow, don't those sound great? The house of cards may bring us all down. Anyway... let's see... where's that coyote? He was out front. I need to keep an eye on him.

Here is an update on our 3.0 plans... Our primary goal is to move the project from the "lab" and get it out to more developers. But, we recognize that it must be done in a way that does not create chaos or it will stop us in our tracks. ---During November *Our main focus remained on the GUI system. (Even if you think it's not that important for your use of REBOL in console mode, the GUI is a great stress test for natives and I/O devices.) *Fixed various internal 3.0 bugs, mainly ones creating problems for the GUI. *Continued enhancements to the GUI look and feel, and enhanced the operation of a range of GUI styles. *Built a prioritized list of PARSE enhancements to add to 3.0. *Added the primary popup/modal and requestor mechanisms. It's a good model that solves many of the problems we faced in R2. *Moved the 3.0 bug database for more open access via the web. *Built the first 3.0 reblet, RebTalk, as an overall stress test of the system. Includes HTTP server backend. *Added more doc pages to DocBase, mainly related to the GUI. I would like to thank Henrik, BrianH, DocKimble, and BrianT for their efforts last month. ---For December If I can paint a perfect picture of the future, here's what I'd like to see this month: *The REBOL development community using and testing R3.0 in a much bigger way. It's time to jump forward. With that in mind, read the list that follows. *Provide R3.0 download via web URL. It would run as a bootstrap that would connect to the web and download various modules and reblets. The benefit for us is that a single exe gets a longer life because updates (and patches) can be made. *Easy source code access. Personally, I know that when I look at other open software projects, if there's an easy way to get the source code and submit my changes/fixes, I feel like I'm contributing in a useful way. I want that for R3. But, it needs to be easy and clear. *A centralized forum for developer discussion. We've been using AltME, but it's a darknet (private), and we know it's not the best thing for large multitopic discussions. Last month the community talked a lot about a range of possible solutions, including web-based BBSes. But, the more I consider it, the more I want a REBOL solution. As I've said before my reasoning boils down to this: most forums waste my time. So I need a system that I can easily enhance, extend, reprocess, etc. I'm really picky. *A finished GUI. Well, at least one that has the default look we like and all of the primary components (styles) used to write reblets (and much more easily than in R2). *The module system. Most of the hard part (namespace handling) is already in the current R3.0, but we need to implement the policy layer, a set of mezzanine functions mainly. We don't want (and I will reject) anything too complicated. I've been there before, and it gets problematic really fast. *Fix bugs as listed in the bug database. Yes, it's a lot to do, and this is a holiday month, but I want 3.0 out! Don't you?

Microsoft talks about how they like to eat their own dog food, meaning, they like to use their own development tools. I agree with that general concept, except of course, as a winemaker, I rather prefer to drink our own wine. (I've never tasted the food I give my dog, but it doesn't smell that great, so why eat it.) Nothing helps improve REBOL more than when we use it for our own purposes. It's a type of stress test where you discover the deeper problems, because you're not just writing tests, your actually trying to get work done. It's not theory, it's reality. As I wrote earlier this month, it's time to get R3 into the hands of more developers. In order to do that, there are a number of important issues that need to be solved, and this has been the week to solve them. It's been the week of making decisions. \table Issue Solution Discussion =row Distribution Website URL Nothing fancy is needed here, as long as developers recognize that they are using a test version of REBOL that is not 100% complete (will have bugs and more changes). In fact, the biggest task here is to automate the web page so we can make updates as easy as possible. =row Documentation DocBase wiki I think we all agree that Mediawiki (the wiki tool) is not perfect, but it is at least a starting point. We can revisit this issue again, if someone wants to supervise a better alternative to it. =row Bug Database CureCode For keeping track of bugs, we will be using CureCode, a REBOL product from SoftInnov. We thank them for hosting it on their site. So, we're drinking some good wine here. =row Source Archive DevBase Here's where we really need to drink our own wine. I spent a lot of time on DevBase earlier this year, and although it's missing a few remaining features, I think it can be improved to do the job. In addition, a new R3 GUI will be created for R3 to directly access DevBase. I expect it to be less work than R2, and it will greatly help us to improve R3. =row Communications (undecided) This has been difficult to solve, and the development community has discussed a range of possibilities. Unfortunately, when something is difficult to solve, it means that the requirements are not well defined or are overly complicated. (See earlier blog.) /table As I wrote before, the schedule is to get the above completed this month (Nov). So far, we're 2 of 5. The distribution web page is minor, because we have tools for that. The DevBase improvements are very important to me personally, and I'm eager to reshape it in R3, because it's an excellent test (and a superior motivator).

As R3 moves toward larger test releases this month, we've been having various discussions about how to improve developer communications, but we've yet to find the perfect solution. I think part of the problem may be that we've not defined our requirements well enough. With that in mind, here's a list of requirements from my viewpoint: :Developer audience - It's intended mainly for developers to discuss topics related to R3, including design, docs, code, bugs, etc. :Low overhead, rapid flow - Meaning we can easily discuss things at a rapid pace. We've been using AltME for this so far (but it's not the perfect tool). :Web visible - Although the forum system need not be web based, it's useful if most discussions can be found on the web. (We did this with AltME in the REBOL3 world, and it works pretty well.) :Threaded - Code development normally focuses on various topics for short periods of time, until the code is design is decided, the code is written or the bug is fixed. Thread mechanisms work best for this; however, they can be inefficient because they require users to jump around to the different topics to see what's been posted. :Sectioned - Thread topics can be grouped into sections. For example, threads related to graphics. :Multi-associated - We want to see discussions in the chat area, but also next to their focus of attention. For instance, a discussion about a bug report would appear in the chat area, but also in the bug system view itself. :Open and scalable - More than just a few dozen developers have access to the discussion. I'm not talking about technology here, just the concept that any developer should have quick access. We don't want to create barriers to developer growth. :Tagable - A way of tagging messages that are key, have future relevance, or need to be flagged to the attention of someone. :Searchable - We need to be able to search prior messages, with various control options for dates, tags, etc. :Carl must use it - This is perhaps the most difficult requirement. I do not like to waste time, and if I feel I'm wasting my time, I stop. I've been using AltME because it's fast and partitioned. I can quickly scan the top discussion groups. So, now that we know what we need, we can find the best solution now, right?

As we move toward the completion of REBOL 3.0 and it's related components, it is time to say a bit more about our progress and plans. For the last few months, the main focus has been on the graphical user interface (GUI), with the objective of creating a GUI system that was powerful, flexible, but remained lean and lightweight. This was no small requirement and has consumed a great deal of my time. In fact, more than any other aspect of the GUI project, reduction of the number of concepts and simplification of each separate concept has taken more time than I had anticipated. As a result of that mind voyage, I have concluded a general rule that: *Simplicity is a delicate thing; *it must be recognized as an objective worth achieving and maintaining, and *simplicity can easily be destroyed, so *therefore, it must be guarded with great care. Said another way: simplicity isn't free. In fact, it's more work at the start. \note Sidenote The merits of that rule apply to more than just software. Look at the last few months of financial market meltdown mainly due to years of using financial instruments that were so complex that no one, not even head executives, understood their true value (or lack thereof) or could properly weigh their associated risks. Now multiply that by ten and you have most modern software systems. Now multiply that by ten and you have the US federal government. In any system, when you build layers upon layers of complexity, the system will ultimately fail, in a huge way, to do the most damage possible. Avoiding that, to whatever degree is possible within our human capabilities, is what drives me. /note Anyway, regarding the project, good progress was made so that by the end of September, we started a new private group for testing, discussing, improving the GUI. (I did not want a lot of voices at this point, so I intentionally kept the group very small. It will be expanding soon.) ---During October During the month of October, the project objectives were: *To review the basic GUI design/concepts and provide feedback. *To contribute improvements, especially focusing on providing a modern graphical appearance and a standard set of styles (widgets). *To track and fix bugs as necessary. *To increase developer awareness of the project in advance of the next stage. Also included for October was to build a documentation strategy: *To produce a new organization of documents based on the new design, for the purposes of educating new developers. *To provide clear and easy-to-understand examples and how-to articles. *To being explaining the finer points, to enable developers to build more complex types of styles, but within the bounds of the design. And finally, to write a few example reblets, from the GUI point of view and in order to help evaluate the design and to serve as examples: *The GUI test control panel (with numerous subpanels, as needed) *A simple submission form, such as that used for contact information. *A super simple REBOL source file browser. *A mini draw program, along the same lines as Sievertsen did in R2, including a few shapes, and controls, as well as undo. *A first pass at a color selector/requestor. *An analog clock as a resizable, setable, getable style. More important than the specific features of any of these reblets is that they provide the opportunity to explore the methodology of the GUI and evaluate its current level of capability. In other words, you cannot complete a good GUI system without using it to do real things. So, we achieved those objectives for October. ---For November For November, our main goals are: *To expand the GUI group to include more developers. *Discover and resolve various bugs or problems with the GUI or the SVG draw system that it's built on. *Wrap up the first skin that has an acceptable appearance for R3, its developers and their initial reblets. *Finish off the required base GUI styles (widgets), including more of the compound styles (e.g. combo box), standard requestors and the popup mechanism. *To determine documentation priorities, make a list of what's missing, and get those written and published in DocBase. *To add several more example reblets, with increasing features and capabilities. *To get a real reblet running, such as DevBase itself, which will allow us... *To get the source distribution back online and available to interested developers. And, as you may guess, these last two items that are important because not only do they help move R3 toward completion, but they also help us build and improve the tools we need to do so.

Judging by the responses both here and on various comment sites, my last blog about application non-installation seems to have hit a nerve with a few people. Hey, that's a good thing, and I thank you for participating in the discussion. As usual with a blog like this, the comments ranged from "your absolutely right" to "you're an idiot." That's ok. Over the years, I've learned to respect all comments because there's usually at least a few grains of truth in every perspective, and I need not agree with a person in order to gain greater insights toward my own goals. BTW, my main point is that we really should avoid going down a road of ever-increasing system size and complexity. If you understand systems and "systemantics" then you know that complexity kills systems. This is why my TV satellite box crashed five times last week and even why my iPhone wants a 250 MB download every few weeks. (I do not consider that a non-trivial download for a mobile device running simple applications.) \note Systemantics? BTW, if you've never seen it, I recommend you to read John Gall's great book, Systemantics, The Underground Text of Systems Lore - How systems really work and how they fail. It's about more than just computer systems, it's about general systems, and we only ignore his insights at our own peril -- this month's financial market meltdown was a shining example. You can find a summary of Gall's system rules here. For example: "The larger the system, the greater the probability of unexpected failure." /note ---Is OS X The Answer? Many of the OS X guys in the crowd stood up and took a bow for believing that they have the right answer, and also took a few shots at me for not pointing it out. (Some even claimed that I had never tried it, oddly enough, not knowing that I once worked for Apple as an OS kernel designer, have owned and used dozens of Macs since 1985, and now own a few OS X boxes, one being what I would call my favorite "personal computer" -- a term of special designation.) Even before OS X, the Mac had an advanced concept of resources used for both data and application. Although the forked file implementation of resources was problematic, the general concept was powerful, but also easy to use and understand. I have to admit I liked the concept, but not the fork. On OS X, resource forks are gone and file bundles are used to hold all of the necessary components for apps and data. As long as that's all an app needs to run, it seems pretty good. But, I have to admit I've never tried installing new apps just by copying their bundles, nor have I tried removing apps by deleting their bundles. Nor have I tried to overload runtime DLLs with app-local copies, assuming that's possible, which I imagine it must be. I suppose I'm just overly paranoid. ---Other Systems? Are there other systems out there that also work toward solving this problem? Certainly, and if you read the comments to my post, you'll see quite a few mentioned. BeOS/Haiku, Syllable, Starkits, JARS, Citrix, and others all aim to solve or minimize these installation problems, using a few different methods. Check the comments for details. Personally, I tend to like approaches that minimize the effort on the end user's side, especially if it makes application management trivial. I can't stand wasting time installing apps. If you're asking me to download a 50 or 100 MB app system to do that, then it's not really as minimal as I'd prefer. And, finally, that brings me to... ---Does it Matter? I guess we really need to ask that question, don't we? Is the traditional concept of an app just a dinosaur dying off? The concept of web-based apps is building faster than ever now that the web has gotten a bit smarter -- finally recognizing the great advantage gained by using the power of the client, what we've been pushing for quite a few years. As a result, the requirement of installation has been replaced with just reloading the app whenever it's called for. Not very efficient is it? But then, for those who are not programmers nor system experts, who else really cares? Yeah, I know, that's heresy, but most users can just get right to using the app, not deal with app installations and related problems. Yes, I suppose not very many people care, as long as they've got a good, fast, and cheap connection to the Internet. They will be online at all times and all places with pages and JS scripts that download quickly, network requests that have no latency and are transported by IP carriers that will give you all the bandwidth you want at no extra charge. So, those are rock-solid guarantees for the future, right? Most computer technologists would say so. Just like bankers would about banks that are too large to collapse. Call me a techno-skeptic. Ultimately, everything changes. Like the CDS derivatives that brought down financial market giants, when you build a house of cards based on complex mechanisms that are difficult to understand, build, monitor, repair, improve, or remove, then ultimately, even a single glitch can bring it down. Hmmm... it seems like I drifted from my opening topic. Or have I? Look, I just want a tool I can use efficiently, reliably, and at fairly low cost. Now, I've got to get back to work. Let's see, where was I? Has my app install finished?

As an OS designer who prefers well-thought-out simplicity over ever-deeper-layers of complexity, I've been annoyed for the last couple decades as I've watched most OS designs pack more and more files into their system and library (including DLL) directories. Eventually, the entire system becomes a mangled wreck of software components that require complex installers, tools, and conventions in order to manage. Take a look at any "modern" operating system as an example, Windows or Linux for instance. What a mess. This concept of throwing shared libraries into OS global directories has long been thought of as a necessity to allow for greater sharing of common code and data. Back in the days when disks were small and RAM was only a few MB, that approach made a lot of sense. But, those days are long gone and every so many years you've got to re-examine your requirements relative to the advancements in hardware. ---Non-installation Since the late 1990's, I figured if I ever wrote another OS, I'd set it up differently. I never liked the concept of installation of anything (apps, devs, libs), with perhaps the OS kernel itself as the only exception. While it's useful to perform some kind of unpacking or decompression step as part of app setup (unzip), the idea of scattering application files into all sorts of mysterious places just makes things harder for everyone, developers and users included. And then, there's also the system registry, but don't even get me started on that. The nice thing about "non-installing" is that your entire app is in one place -- pretty much just a copy of the distribution itself sitting right there. And, wouldn't that be handy in itself, both in terms of backup and also for ease of app removal? So, you ask, if an app isn't installed, how does the OS know about it, it's icon, file types, boot options, related tools, and other such things? Well, I'm glad you asked. That's the concept of binding, and there's no reason it needs to be done during installation. You could quite easily perform that step during boot by inspecting application header files (preferably written in REBOL) that define those relationships, located in each application directory, of course. I would claim that step would take less boot time than that required these days to sort through the tangled mess of files in the system directories. In addition, you need a user-specific storage area for prefs and other special data. But, there are several ways to do that, even via user-specific symbolic links. Not a problem. ---New or old idea? Is this really a new concept? No, in fact it's a really old idea. You could setup apps this way on the Amiga back in 1985-86. You'd use an assign (essentially a symbolic link) to access the app's base dir. Pretty simple. Is it possible on modern OSes? Aren't they just too complex for such a simple approach. Well, it's nice to see someone put together a Linux distro called GoboLinux that does just that. And, they even kept it compatible, so check it out. Are there others? Quite possibly, and I know you'll post a list in the comment section. Anyway, I point this out because I really like to see rebellious developers working to make computing systems cleaner and simpler, rather than the usual case of making them insanely complex. Good work, keep it up. Now, if we can just get rid of the rest of the garbage that clutters up modern OSes, maybe I will find an OS (other than AmigaOS, of course) that I actually like using.

Many years ago, when I first released REBOL, I decided to introduce it as a simple approach to programming. In order to help convince new users, I posted a great number of examples on our website and in the REBOL.org library to prove my point. I wrote simple scripts of all kinds. My motivation was to attract new users to try our unique approach, and the scripts were just the candy. Of course, although I knew that REBOL scripts were often quite simple, we should be very careful not to invert that statement. The existence of one or more simple scripts does not mean that REBOL itself is simple. No, quite the opposite. Early on, many programmers who encountered REBOL looked at our simple scripts, and not diving any deeper, concluded that REBOL was too simple. Little did they know. REBOL is one of the deepest languages ever designed. Since those days, I've glanced over a lot of REBOL code written by a wide variety of programmers, and quite often I'm floored. Many programmers use REBOL like they're writing in C or BASIC. I can spot it in an instant; they did not bother to learn the fundamental concepts of the REBOL language. When I see that kind of code, I wonder why they bothered to use REBOL at all. C is better written in C. You will never hear me contest that fact. I think it's time to change our message. REBOL is not for everyone. REBOL is advanced. It promotes the concepts of symbolics, context, and environment as powerful tools, going far beyond the traditional ideas of functions, objects, loops, and if statements. REBOL is for a different breed of programmer. It is for those with open minds; those who are reflective, observant, and those who do not simply bang out any kind of junky code that works, but consider each detail of their design, and sculpt it perfectly as a lasting work of thought. In REBOLville, we often like to boast, just a bit, about how we wrote a cool reblet that was only 15K or perhaps 50K. Yes, we all love that result. But, I think our love of it isn't just because we built useful applications in less than the typical size of a single web page. Sure, that's fun. But, for many of us, it's more the fact that we can, in the year 2008, easily manage the entire software process: getting it built, finding and fixing the bugs, distributing it to our organizations or friends, and then, a year later, add some nice enhancements, often in just a few minutes. We needed no huge multi-gigabyte, complicated, trouble-prone development system or run time monstrosity. I think we REBOLers have different priorities, different values. REBOL is for a different kind of programmer. We are of the old school but of the next generation. We want more from our language. Sure, we can write simple scripts, but even better, we can write powerful programs that are the size of simple scripts. I think it has come time to update our message and website. I should not pretend that REBOL is for everyone. It is not. REBOL is for those who of us who think differently. Frankly, I would not want it any other way.

Thanks for your comments on my prior blog, Grindstones, caves, focus, and multitasking not. Because this is an important topic, rather than reply to your comments within the comment section, I'm posting replies to each of the main points. If I missed something important on the topic (there was off-topic chitchat), let me know. ---On Communication Pekr's point is very reasonable, and Graham, Shadwolf, and others agree: \in Just expose yourself via some one-sided communication channel. And what is better than some blog? Why not, at least once per 2-3 weeks, to write small blog about how you added some cool function to VID, show some diagram, screenshot, piece of code, whatever... /in I agree, but I know that I'm reluctant to discuss the project during development when many design decisions are still pending and up in the air. Let me explain by way of a current project: The GUI project is deep. I could write up a message from time to time, but when you see it, a lot will have changed. For instance, the original GUI design specified important concepts of "look" and "feel". After several weeks, I tossed those concepts entirely. Why? Because they had become non-beneficial to the design. So much of good design is not just about adding and improving concepts, it's also about removing and simplifying concepts. Think of architects that create large buildings. They don't just keep adding new ideas. They constantly refactor and reduce. Still, it seems there must be some way to write more about it... so, essentially, I agree with your point. ---On Creative Process This comment from Kaj is so true I want to print it in big letters and hang it over my desk... \in I think the point of creativity is that you don't know exactly what will come out at the end of the process. It's a continuous backtracking process and pretty much impossible to write and tick to-do lists for. This mistake is made often by other people who work serially. /in Yes, this "truth of development" I've seen my entire career, even at HP, Amiga, Apple (but often ignored). However, I still use todo lists... because they are lists of end requirements and less of how it works. I always measure against those objectives. ---Public Lists Carl Read is reading my mind again with: \in Have a public to-do list, where you can add comments to each item as well as just tick them 'done'. It'd show activity as well as bits of your thinking here and there. /in It is a good idea and I want to see that happen. I think of it as a requirement of the R3 project. There are many components that need to be done, not by me, but by others. The question then becomes, what are the best methods of making this happen? ---Evanglists Karim writes: \in Maybe, Rebol Technologies needs an "evangelist". A kind of guru who likes to speak about Rebol. /in I've thought this for a long time, and I really would like to, but it's not clear to me exactly how it would work. The reason is that most developers want real meat, not tap-dancers... as we see from so many other websites. Now, it could be that the evangelist is really more like the lieutenant concept that Brian Tiffin noted. It's a job based on specific needs... like coordinating source contributions or validating their quality, getting other websites to promote REBOL, filtering and funneling questions to me, and other things that I might think of, if I spent more time on it. ---The Masses Popper talks about the masses... \in the masses are only interested in real world working code and apps that do the job, they see an app, use it, get interested in its construction then start advocating its use were ever they go, its not rocket science. /in Yes, that's a good summary of the state of computing and the Internet, and why I've concluded that we (humankind) may be doomed in the next decade or so. That's the main reason why my DirecTV box is a piece of junk, why most of our friends own computers that are a wreck, why my cellphone was totally messed up (but, I got a new iphone this month), and even why a gas pump at a gas station recently crashed on me (but not in the way that gave me 10 gallons of free gasoline.) The problem is this: real physical designs (like buildings, planes, highways) require real design. However, computer sofware designs can be made to work without any real design... just by using enough bandaids, gum, and tape. (Just imagine if we could see those designs as buildings... we'd run for cover!) ---Picking a language Thaddeus is thinking over his choices of languages... \in I intensely dislike C, Java, and their progeny. Also, pretty much all of the other languages I've seen have some kind of major downside, like not being supported anymore, or not being on more than one platform. The way I see it, I now have the choice of using Euphoria 3.1, using REBOL 2.7.6, waiting for Euphoria 4.0, or waiting for REBOL 3.0. /in Henrik's reply makes sense: "it's a good idea to learn 2.7.6, because no matter what, you'll need some of the skills for R3." My reply is always: use the language that makes the most sense for your product. For example, I don't like using C code, but that's that REBOL is written in (and, of course some of you will way... I don't have a REBOL compiler, yet. ;) Also, always be sure to point out features you find useful in other languages. We can't always do them, but as R3 progresses, many may be possible. And finally, I think R3 will make it easier to build much better GUIs... in much less time. ---What is the focus? Icarii cuts through the chitchat with: \in WHAT is the top level thing you are currently working on? You mention that you are working on something but we have no idea what it is. /in Answer: it's the GUI, the new "VID" (quoted, because I want to rename it, as it is not that much like the old VID.) This project is huge... and has been through many design stages and revisions. But, it is running, and I want to say more really soon... if this wild horse will just calm down and stop its endless bucking.

Ok, I will be the first to admit that I am a horrible communicator when I have a top level focus that requires all of my attention, energy, and creativity. During those times, I'm in the cave, nose to the grindstone. (That's not a mixed metaphor, is it?) I've always been like that... even back into the 1980's when I wrote the Amiga multitasking OS kernel. I would focus entirely on it for months and ignore just about everything else. That's what it took. The passion produced the result. Nothing else could. I joke with my friends... as the person who brought multitasking to personal computing in the 1980's (back in the day when people would say "multitasking, what is that?") I am very single-task oriented when it comes to big projects. That's what it takes to get them finished. I don't think I'm alone in this behavior. Most of the best developers, creators, builders I know do the same thing. In fact some of them won't even get on the telephone, let alone send email or IM. They just vanish. Then, one day, they return, usually with something wonderful and finished... a well constructed well thought-out design. (I will never forget RJ Mical locking himself in an office at Amiga for three weeks, and he did not reappear until Intuition, the Amiga's revolutionary new GUI was finished... and documented too.) Yes, I know that as REBOL chief the seclusion is a problem... and our friend Pekr nags me constantly. But, it is difficult. In fact, if you search the web, you'll find my prior attempts. I mention all of this publicly because... #I know it hurts the REBOL cause to not be out there talking and promoting our revolution constantly and with every opportunity. #Bringing others into the communication would probably help, no? (As long as they are experts in the REBOL domain.) #It would be cool to find a solution that works. Post your comment or contact me directly via feedback.