On design processes

[Hans-Dieter Dreier]

Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------15A2639B9ED8B30D4137B0AE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Matthew Tuck schrieb:

> Ursula Dreier wrote:
>
> > I feel that I should say something about what I think is important in
> > a design process like that we're in at the moment. I apologize if it
> > gives the impression to be rather philosophical (is that the right
> > word?), but it's important nevertheless. I try to give some examples
> > to clarify the motivation for all this.
>
> Well it's probably what you meant to say but I wouldn't say it is.

It's not philosophical? Or not important? What you you mean?

> I probably come from a different angle then.  I've recently rewritten a
> library I was writing, for about the fifth time, and yes, other than a
> few framework methods, from scratch.  I had to to get more flexibility.
> Each time it's become better, because I understood the process better.

Similar thing happened to me, too. More than once.

> Maybe I should have designed it totally first but I'm not very good at
> that sort of thing.  But I think that's irrelevant, since if you do a
> thorough design coding is trivial.  You often need to do several designs
> and throw them out in any model.
>

"Make it right the first time." That's what they teach us in all those books
about quality management. It's important for commercial processes.

> I think you are also operating under a finite resource assumption.  In a
> normal software project you have a finite set of resources, this is not
> so in an open source project.

I see that now. In fact, I did most of my projects on my own or with one or
two colleagues, and there was some economic pressure.

> You attract programmers by your code.

How about a vision? Reinforced with an architecture that shows it to be
feasable?

> I decided we needed code after reading this:
>
> http://slashdot.org/features/98/10/13/1423253.shtml

That a most fascinating document. The conclusions sound sensible. Alas, it
doesn't say anything about the technical aspects (there has to be at least
some form of coordination - how is that done).

> I think it's a powerful argument, and the many comments support it.
>
> > If you already got everything laid out, then you should communicate that
> > knowledge to us before starting to implement. This would require to
> > write it down, and I bet that you'll find some more or less serious
> > design flaws during that process.
>
> I don't know how much this is compatible with open source.  Sure, design
> is important, but someone will always come along with a patch to improve
> it.

A patch can always be patched in afterwards. That's no problem. I rather meant
the central assumptions (or lack of) that form the basis of the system. IMHO
memory layout is such a thing: No objects, non-nested objects or nested
objects - that may have severe implications on what will be possible later and
how easy that will be; crucial changes in memory layout might force a complete
rewrite.

> Also, I know where I want us to go, I've personally currently got enough
> ideas to sustain us for ten years or so, but I don't know what I want to
> do first.

How about a table-driven (to be extendable) parser without any frills attached
and an assembler-like syntax to directly produce objects and crude code for a
most simplistic stack machine? So that it can output "Hello world" to stdout?
There might even exist some code somewhere that can serve as a starting point.
You're more involved in open source development than I am, but if you tell me
some URLs I will see what I can find. Otherwise I'll sketch a class layout for
such a thing, but I definitely want a discussion before putting too much
effort in it - I've got no spare time to spend on code just for the trashbin;
it should at least be good for a temporary module.

> I think high-level and module interface design is definitely necessary,
> but low-level design should be left up to the writer.

Agreed.

> Remember, I don't want a backward compatible language if it legacy
> shackles us.

I never meant to do any binding specifications in the foreseeable future.

> ...  but on the
> other hand I believe in the ideal of a general purpose language.

So do I. You'll notice that I picked my examples from rather less general
areas. But I certainly wouldn't mind if the system would be suitable for them
as well.

> I've thought of the idea of defining your own heap over the top of the
> main heap - you could compress or compact using this.  You would have to
> implement your own GC though.

Yes. Maybe not right from the start, but some time soon.

> > 2. I want to do every task at the highest possible abstraction level.
> > For example, not hardcoding the operator list, but rather keeping it in
> > some list object, together with binding powers and the like.
>
> I'm not sure what you're referring to here.

Examples: Have a syntax specified by tables (which are one level higher than
compiled code) rather than hard-coded. Maybe at some later time have those
tables filled by processing some (BNF-like ?) syntax description rather than
by initialisation of the tables by hand. Generally speaking: pile architecture
on architecture and use the highest one as far as possible.

> > Objects should be describable in terms of theirselves (recursively) as
> > much as possible.
>
> Not really here either.

There are objects that describe the behaviour of other objects to the editor,
the compiler and the debugger, rather than by some hard-coded special
treatment (only where possible, of course). So that the language can
eventually be extended by adding those objects rather than changing the code
of the editor & compiler. Is another example of piling architectures (Ultra
objects on top of Ultra code).

> > I really like the idea to store source code in an already structured
> > from, as precompiled as possible without reducing the freedom of the
> > programmer more tham necessary.
> > This will help to keep the kernel small and clearly laid out and reduce
> > the overall amount of code.
>
> I haven't really thought about it in these terms before.  How will it
> keep the kernel small?  The VM kernel or the compiler kernel?

More likely the compiler kernel (I don't think the VM kernel has much to do
with source code). Parsing will be a great deal simpler; sensible error
treatment as well because many errors will be caught at edit time or won't
happen at all. I'm really fed up with the sort of error messages some C++
compilers generate (but to be fair, that's also due to the syntax of C++).
Anyway, it's not for now - there has to be a suitable editor framework first.

> > 3. Be as independent of other software systems as possible, especially
> > at places as crucial as the kernel.
>
> This sounds like portability through modularisation.  Is that a fair
> assessment?  Long-term yes, but we might have to concessions to this in
> order to speed up development.  Hopefully not.
>
> This also seems to say we shouldn't use things like compiler
> generators.  Maybe I'm reading more into it than there is.

Depends on what they generate. If they transform a syntax into functions calls
directly, I'd rather not have them - too inflexible. We want to be able to
supply different syntaxes at runtime, and they should be defineable in Ultra.
If comp.gen's produce tables, to be processed by some (syntax independent)
kernel, that would be better.

But I actually thought of being dependent on the Java VM, for example -
something that is beyond our control, but can cripple a design because it
simply may not support things we deem necessary. Java wasn't designed to be a
platform for things like Ultra, after all. It's somehow like programming
everything in, say, Cobol and then have to switch languages in mid-project
because we'd realize that Cobol doesn't support the things we want. (Of
course, it's not nearly like that, but maybe you get the point).


--------------15A2639B9ED8B30D4137B0AE
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Visitenkarte für Hans-Dieter Dreier
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Hans-Dieter Dreier
n:              Dreier;Hans-Dieter
email;internet: Ursula.Dreier@ruhr-uni-bochum.de
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------15A2639B9ED8B30D4137B0AE--