REBOL Technologies

Carl's REBOL Blog - Vive la REBOLution

Carl Sassenrath Carl Sassenrath, CTO
REBOL Technologies

Private feedback

1046978 visits since 12-Mar-2007

Search:

RSS

Purpose:
A few words from REBOL's architect.

Other Blogs:
REBOL 3.0 Front Line
REBOL Update News

Recent Comments::
0377 0374 0376 0373 0375 0347 0363 0045

Recent Articles:

3-Nov-2008 - R3.0 Project Status Update [0377] 20 Cmts
23-Oct-2008 - Hitting that App Installation Nerve [0376] 20 Cmts
21-Oct-2008 - An old OS idea is new again: non-installation [0375] 44 Cmts
15-Oct-2008 - REBOL, Not for Everyone? [0374] 52 Cmts
27-Aug-2008 - In reply to comments about grindstones, caves, focus. [0373] 26 Cmts
23-Aug-2008 - Grindstones, caves, focus, and multitasking not. [0372] 25 Cmts
30-Jul-2008 - About the Access Error: Port none not open [0371]
23-Jul-2008 - REBOL Boat for Sale... (sold) [0370] 4 Cmts
9-Jul-2008 - Is a 44 magnum really a better mouse trap? [0369] 6 Cmts
2-Jul-2008 - I want my MTV... whoops, I mean OSX SDK. [0368] 12 Cmts
2-Jul-2008 - Nit PICKing [0367] 14 Cmts
Contents - Index of all articles.

3-Nov-2008 - R3.0 Project Status Update [0377]

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.

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.

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 begin 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.

20 Comments


23-Oct-2008 - Hitting that App Installation Nerve [0376]

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 "you're 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.)

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."

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?

20 Comments


21-Oct-2008 - An old OS idea is new again: non-installation [0375]

Also see...

Due to the number of comments on this blog, a follow-up article has been posted.

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.

44 Comments

View index of all articles...

Updated 12-Nov-2008   -   Copyright 2006 Carl Sassenrath   -   WWW.REBOL.COM   -   Edit   -   Blogger Source Code