for the GNOME hater in all of us...

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Shimpei" == Shimpei Yamashita <shimpei@example.com> writes:

    Shimpei> I'm starting to get disillusioned with GNOME

I'm not disillusioned, I never had any illusions about GNOME.  I've
read GTK code, and I've attempted to read the docs.[1]  The 'N' has
always been silent; pronounce it ごみ.

    Shimpei> See the lead story on
    Shimpei>   http://www.sun.com/

Well, there's some hope of commercial discipline then.  Although the
saga of Li18nux is not encouraging so far.

>>>>> "cs" == Christopher Sekiya <wileyc@example.com> writes:

    cs> GNOME (and KDE) have too many moving parts.

Yeah, I've still got one of those damn floating toolbars left over
from before my last kernel upgrade.

>>>>> "Simon" == Simon Cozens <simon@example.com> writes:

    Simon> One man's bloat is another man's necessity. :) Yes, there
    Simon> are a lot of libraries involved, and maybe you'd get a
    Simon> slight speedup from having it all thrown into one library,

Not the issue.

    Simon> (although only slight because they things should remain
    Simon> paged anyway) but that doesn't really encourage
    Simon> maintainability, code reuse or any of the other accepted
    Simon> Good Things.

Evidently you do _not_ build GNOME from scratch.  (I don't either, but
I've never heard a good word for it from those who have done so.)

Seriously, I see _no_ evidence whatsoever that the OSS community as a
whole[2] has yet embraced any of those Accepted GoodThang[tm]s.
"Embrace" means first, document your code, second, improve the
documentation, and third, revise the documentation.  The code itself
is, of course, entirely optional.  :-)  Maintenance, reuse, etc, all
flow from documentation, although there are subsidiary means that help
achieve those goals, given good documentation.

Dividing things into multiple libraries just makes it worse; you can
change your APIs _without_ breaking your own builds.  Unless the APIs
are documented.  Sorry, Luke, the source is _not_ acceptable
documentation for an API[3][4].  It will change tomorrow---"that's
called development", eh, Simon?

Taken completely out of context from a different message:

    Simon> isolating and compartmentalising code is extremely useful
    Simon> to avoid requiring a holistic understanding of [...]

... anything at all.  Especially not the users' requirements!

Simon, I'm really surprised to see you advocating the MDPPDM (Modular
Debian Project Perl Debasement Methodology).  That's precisely how
they do it, as you very well know.

    Simon> Given an infinite amount of monkeys an infinite amount of
    Simon> time, an infinite amount of drafting supplies, and an
    Simon> infinite amount of crack, they'd come up with [GNOME].
    Simon> -- David Jacoby, in the monastery

Once again, Simon, your AI random quote generator is too apropos to be
believed.  Even with a little editorial assistance....

No GNOME threads at the sobetsukai that Simon doesn't start, OK?  Get
yer ya-yas out here.[5]


Footnotes: 
[1]  I'm  pretty fast reader, but not so fast I can read stuff that
ain't written yet.

[2]  GNOME is big enough that its development nearly does involve the
community as a whole.

[3]  Neither is a listing from strings(1) or nm(1) (even with -g).

[4]  It is for a monolithic program, if reasonably small.

[5]  If you want to know what's got me pissed off, take a look at
http://wipo2.wipo.int/process2/rfc/rfc1/ and weep.  (Where have I seen
that phrase before?)

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."