Thought I might touch a chord with the Adobe font rant.
graydon: Yes, unifont is cool
stuff. It's not at all fair for me to say that there's
nothing going on in the world of free software fonts.
Reaching into history a bit, you'd also have to give the
Metafont project major props both for incredible technical
innovation and a library of highly distinctive, useful
But my point still stands; if you try to point to any free
font work that directly compares with Adobe's latest
OpenType efforts, you will come up empty.
Regarding compilers and other bits of infrastructure: yeah,
that stuff either needs to be free software or something
very much like it. The idea of putting bits of this
infrastructure into brightly colored shrinkwrap boxes
distorts the whole endeavor incredibly destructively.
Proprietary operating systems and tools tend to suck really
hard because of this. However, the new Adobe fonts most
emphatically do not suck.
Mulad: I'm not complaining that
there's no money for free software development. In fact, I
manage to get paid pretty well for the work I do. What I'm
complaining about is the indirect nature of this funding.
OctobrX, Raster, and others are in the position of being
sponsored by a patron (in their case, a public corporation
losing money at a dizzying pace). Further, I support my free
software habit through consulting and other "day job"-like
activities. It's a very different thing than simply
being paid for the work I do, an option provided by the
proprietary model, but denied me by free software.
Let me try to present my argument again. All software sucks,
most of it pretty badly. When you try to analyze the causes
of this suckage, two winning strategies to make software
suck become immediately apparent.
First, you can fail to bring adequate resources and talent
to the project, dooming it to being hopelessly amateur. For
some projects, free software does manage to make these
resources available, mostly for bits of widely-needed
infrastructure. For many others, it simply doesn't.
Another good way to make software suck is the familiar story
of decommoditization: basing it on complex, ambiguous, and
ever-changing "standards" as a way to create lock-in and
drive the upgrade treadmill. Microsoft Office is basically a
canonical example of this, but certainly not the only one.
Note that neither proprietary nor free software have a lock
on either kind of suckage. For example, I consider sendmail
a really good example of a piece of software which has
managed to lock in its market segment by being bad. And for
demonstrations of lack of resources, just look at any
segment of the market without an ultra-compelling economic
argument, for example Be applications.
All I'm saying is that whenever somebody comes up with
software that doesn't suck (or sucks less, anyway), we
should sit up and take notice, and ask how it came into
existence in spite of the powerful forces which always seem
to subvert it.
Over the past few days, I've had the pleasure of speaking
with the creators of both Inti and Gtk-- about
techniques for wrapping C libraries with C++ API's (this is
in the context of Libart). It's not hard to see how the
split came about. These two projects have radically
different approaches. Karl Nelson seems to be in love with
every trick in the C++ book. He encouraged me to consider
multiple inheritance, using streams for operations on
images, String-like objects for paths with copy-on-write
semantics, and more. Havoc, on the other hand, encouraged me
to use refcounted pointers, with a link back from the C
object to the C++ counterpart. Inti is basically
very C-like (ie, pointers are still pointers), but with
type-safety and some other nice features that C++ provides.
Even though the relative simplicity of Inti appeals to me, I
don't think it's what I want. A user of Libart will often
create many short-lived objects. It makes a lot of
sense to use stack (auto) allocation for those - you get
static enforcement of constructor/destructor pairing, almost
for free, and code is a lot cleaner if it doesn't have a lot
of explicit memory management stuff hanging around.
Taking a step back from the Inti/Gtk-- split for a minute,
though, I'm convinced that the real problem is simply C++'s
overweening complexity. Providing a nice, high-level wrapper
for Libart should be a relatively simple task.
However, C++ makes my design space really, really big,
especially when it comes to options for memory management.
I'm becoming more attracted to C++ now that it's (sorta)
becoming a standard, and that decent implementations are
becoming available, but I also feel that constant vigilance
is needed to fight back the complexity that the language
introduces, to keep it from infecting the rest of the