[om-list] meeting

[Mark Butler]

Luke Call wrote:
> 
> Long experience has shown me over and over again that choosing a
> language and divvying out tasks before an architecture is done, is going
> to result in inflexibility and will lead to a product far short of our
> goals. I want to get the design right, above all, then the class
> structure we create will have headroom to grow or adapt without constant
> painful redesign. I have seen this time & time again.  We may find that
> we want to use CORBA as a comm layer between modules, or we may find
> that our needs require a different distribution of responsibilities
> among components than any one person could come up with on their own.

Anything we program right now can virtually be considered to be a "throw-away"
proof-of-concept prototype.  Even for a non-prototype, C++ is about a safe a
language choice as possible.  There just aren't any well known high
performance cross-platform alternatives.
 
> These things matter. If we get a design right, it can lead to an API
> where multiple front ends, in multiple languages, can access it--whether
> a GUI, text-mode interface, multiple-user, external software systems,
> etc. It is essential to get our core model good enough to scale up to
> the kinds of requirements we have defined. 

The logical model is really what we need to develop and has little to do with
scalability.  Truly scalable implementations tend to be much more difficult to
implement than non-scalable ones, which is why Tom and I are  inclined to make
an in-memory only, non-networked, non IPC prototype to start with.  

> I'm really not trying to be a king here. But a design process, guided by
> experience (which is why I like Rational's--there is so much wisdom in
> it from so many people, but others are good too), is the only way to get
> it right. And the creation of design and module specifications has to be
> a group effort, because no one of us is smart enough to do what we can
> all do together.

The problem is that this is almost impossible over an email list.  Individual
members need to come up with proposed designs for components of the system and
then submit them for review.  I have volunteered to come up with a proposed
design for the core meta-meta-model and to implement a prototype (probably
with a text only UI) in C++.
 
> I realize things have been slow. But let's not rush it to the point
> where we skip the foundation and rush to the product phase. I will not
> be able to participate in that, because I have to be able to envision
> the whole before creating the separate parts.

Fortunately, most high level user requirements have no bearing on the core
meta-meta-model.  The only requirement is that it be complete enough to
implement arbitrary meta-models (e.g. Mathesis or English). 
 
> Would someone other than me like to propose how we will design? Maybe we
> can get some discussions going that way.

I think we should proceed with the process you have started.  It will be very
necessary for determining the user interface design and various processes in
the system.

> And, this product should be multiplatform!! C++ won't be adequate for
> that--what GUI toolkit will we use? GTk?

I think the most likely choice is GTK++, although Qt wouldn't be bad either.

> X--Is it available on NT, or
> the Mac? We are creating something here that is supposed to affect the
> whole world. 

I agree that the prototype should be compilable on Win32, which is why GTK and
Qt are both reasonable choices.

>Also, we are at a prototyping phase. C/C++ is not for
> prototyping but for optimizing. 

What do you propose that we use for the prototype instead of C++?

> Have you tried writing and debugging a
> multithreaded engine in C++ vs. doing it in some other language? 

The last thing I would be inclined to do is make any prototype multi-threaded.

I have,
> in both. Yes, performance matters, but we are developing such an early
> version that performance can't be allowed to displace our development
> speed and our ability to be flexible as we create initial systems that
> help us learn about the consequences of our design choices. We can
> rewrite sections for performance later, once higher-priority
> requirements are in place.

The core piece of the system is a database engine, which automatically
excludes most common user interface prototyping languages - I.e. Perl, Python,
Tcl, etc. are out of the question.  The only practical prototyping languages
for a database engine are (quasi-)compiled languages like C,C++ or Java or
possibly a symbolic engine like LISP or a full Smalltalk environment.
 
> I beg you to get a copy of The Rational Unified Process, or UML
> Distilled, or the one by Craig Larman with title like Applying UML and
> Patterns (recommended). Or propose a design path that I can understand
> and envision the whole--I have a hard time functioning without
> envisioning the whole.

I actually design software for a living, so I know where you are coming from. 
Certainly we are not remotely close to being ready to implement a full system
prototype without lots of additional design work.  I volunteered to design a
meta-meta-model because that is the portion of the design least likely to be
affected significantly by the higher level discussions we have been having. 
As far as C++ is concerned, that is certainly my preference, but I imagine
other languages could be used as well.

- Mark

-- 
Mark Butler	       ( butlerm at middle.net )
Software Engineer  
Epic Systems              
(801)-451-4583