R3 Priorities: Modules

With DevBase now operating, it's time to return our focus to R3 completion.

Today, I surveyed a few developers for their opinions, and there were a few common threads in the replies. Of those, the modules component stands out the most.

In R3, modules are more than just a method for selectively including other run-time features. Modules are the fundamental component of namespaces, the primary mechanism for program component isolation. Although, in current versions of REBOL we do this quite well by wrapping an object around program sections, modules provide a formal way to do it, and also offer greater control over what needs to be exported.

In today's survey, some developers replied that plugin components, tasks (threading), or media codecs were important. All of those depend on the module system itself. For example, plug-ins have been working for more than six months, but to be completed (to properly isolate the new words a plugin installs), modules are required.

I have to admit that so far modules have been, well, too much like taming a tiger. And, so far, the tiger has been winning... often, ripping me to pieces. The tiger is the main reason R3 is running late. Yes, blame the tiger. I've got many scars.

The tiger is a dangerous creature to allow into an ecosystem that prides itself in being agile and lightweight. It is all about PITL (programming in the large) when we live in PITS (programming in the small). So, in essence we've got to tame the tiger with something like "think global, but act local" but modified along the lines of "think PITL, but act PITS". Am I being too abstract?

Anyway, it's time to face the tiger again. This time, there can be no retreat.

5 Comments