Glee Blog Article

Date: Jul 22, 2003: Starting this Web Log (BLOG)

Abstract:

Glee is a language intended to facilitate the evolutionary, rather than revolutionary, development of computer applications and systems. This article introduces this Web Log and its first subject: The sculpture of the Glee Object Storage System

Article:

There are probably as many software development methodologies as there are software developers. It seems the least experienced developers employ the strictest methodologies. They believe a series of rigorous steps executed perfectly will produce a correct and robust system in the shortest possible time and within budget. Classically, such methods begin with an exhaustive exploration of the requirements. Then there are various stages of design, implementation, testing, and launch.

But this classic "waterfall" method of system development seldom works in practice. Why? Because it relies on perfection. It relies on "trapping" the problem. Real analysis won't be perfect ... it must be evolved. Real problems won't be trapped. They must be "tracked". When you get down to it, the users only "sort of" know what they want. When they see what the rigorous methodology delivers, they then have a better idea what they want ... and it's not what they said ... and even if it was, the analyst usually doesn't correctly grasp what they said. Ah ... but then it's too late.

What is really required is a method of "tracking" the problem through an evolutionary development process. You need to get the computer working for you as soon as possible. And that means coding as soon as possible. Strongly typed languages don't allow this. I know. I've written Glee in C++ which is as strongly typed as they get. Any time I need to change the underlying structure to accommodate some oversight or new feature, I have some pretty complicated surgery to perform ... and that takes time. Of course, if I did it right in the first place, there would be no such thing as an oversight or a new feature. I've just had to come to embrace the fact that I won't get it right the first time ... no matter how hard I try and how deeply I think.

With Glee, rather than trap the problem to avoid these delicate future surgeries, I've tried to create a tool that can adapt to change. The problems it addresses surely change. So Glee needs to be a tool for sculpture in putty ... I'm not ready for stone ... ever.

Creation of Glee has been a frustrating process. On the one hand I'm working with C++ which is pure tedium. On the other hand, Glee, which is the result of this work, is really fun and simple and powerful to use. So I'm constantly bouncing between two very different environments. It's "not" hard to tell which environment I like best and in which I am most productive. I cringe when I have to do the C++ programming to add new features to Glee. But C++ is a superb "system" development language ... and creating Glee is system, not application, development.

Right now, Glee has less than rudimentary capability to make your work persistent. In other words, the file handling capabilities need serious work. So that's what I must address next.

Glee is mature enough now that I can use it to create a running model of what I want to do. I can then do the final implementation in C++. I get the sculpturing power of Glee and the performance of C++.

My next BLOG article will begin that process. I will develop Glee's Object Storage System (GOS) using Glee itself. I'll practice what I preach and use my software sculpturing and tunneling techniques. I know that no matter how hard I think and how much experience I have, I can't come up with the proper design without trying lots of things.