new sysinstall

[Bill Huey (hui)]

On Mon, Sep 01, 2003 at 12:47:31AM -0500, Chris Pressey wrote:
> Bill Huey (hui) <billh at xxxxxxxxxxxxxxxxx> wrote:
> 
> > Tons of things can be done with language environment like that, that
> > are impossible in other more primitive environments.
> 
> I guess one reason I'm having a hard time getting a grasp of this, is
> that I consider (within reason) that everything is possible and that
> nothing is impossible.  After all, all these languages *are*
> Turing-complete -- I've seen things done in pure sh that made my
> eyeballs pop out of my skull.  So we can really only speak in terms of
> making things easier on ourselves, rather than making things possible.

The task needs to be characterized before any choice of development
environment can be decided upon... But...

Take GNOME development for instance. If you look at it and their C language
layer... yeah, it's kind of OOPish and it does OOP things, but the way this
came about lead to effectively implementing two compoundingly complicated
CORBAish systems (CORBA, GObject), probably took 10x+ the effort for them
to make, say, simple changes in the class hierarchy, which is why development
in GNOME many years behind KDE. IMO, not because of how much of a head start
that project has over GNOME, but because of the mismatch of programming
constructs applied to the kinds of problems they were trying to solve.

It's like trying write Java programs using JNI and language runtime internals
in place of the regular programming language. It's simple wrong level of
detail applied to the wrong kind of problem.

> That's almost exactly what I'm asking about in regards to requirements
> and/or a concrete example.  I haven't seen any of note yet, and it makes
> for good fuel for a language war.  I'd prefer to avoid that...

The scope of it needs to be defined first, some kind of top-down methodology
and then efforts towards some kind of implementation. Typically, in projects
like this, it happens because of a single person's technical leadership and
not by group or design by committee. If it does, then you're limiting/screwing
yourself, and the group, to the same overdesign, "Let's please everybody"
least common denominator crap that happens in regular FreeBSD development.

With that, you have to really ask yourself when was the last time you saw
anything really technically cutting edge in that project ? Design by commitee
is the death of any project. There's the opposite to this, but I think folks
understand what I mean here that's ever been involved in any serious
development group.

You need to have clear objectives and then non-stop implementation of these
things. That's all I'm saying. :)

bill