On Thu, Jun 15, 2006 at 10:02:10AM -0700, Linus Torvalds wrote:
> Too many developers shrug off the "it's hard to use" argument. THEY think
> it's fine. THEY think it's "lack of training". THEY think the tools are
> fine, and the problem is the user.
>
> THEY are wrong.
>
> Almost every time when a user says "it's hard to use", the user is right.
> Sometimes it's a lack of documentation, but quite often it's just that the
> tool interfaces are bad.
In tha case of jam, the doc issue can certainly be raised, but the
most prominent problem is probably that everyone and their dog knows
make, and expects a replacement to work in a similar fashion. The
current documentation and tutorial unfortunately does not show
precisely how people used to "make" can easily switch to jam.
For those not knowing about jam, I'd say the 1st thing to anchor in
one's mind is that jam gives complete (programmatic) control on the
dependency tree (eg. you just have to write once that the results of a
compilation have to be removed by "jam clean", and everytime you
declare a file to be built with your rule, you don't have to remember
to add it to the Clean rule - and more importantly, as soon as you
remove that declaration, you don't have to fear the Clean target to
remove it, in case it would be precious).
> Sometimes the problem space makes the interfaces fundamentally hard. But
> sometimes the program itself just makes things ugly and hard, and autoconf
> and automake definitely didn't make it easier for users - they were
> designed for people who knew fifteen different versions of UNIX, and not
> for sane people.
>
> These days, there aren't fifteen different versions of UNIX. There's a
> couple, and it's perfectly ok to actually say "fix your damn system and
> just install GNU make". It's easier to install GNU make than it is to
> install autoconf/automake.
Right, autoconf would be much more sane if it would not insist on
supporting vintage unices. OTOH, people having to work on these
systems (eg. for professional reason - not everyone has the luck to
work with modern systems all the time) are more than happy to be able
to build some recent tools to make there task easier. Except when it
fails in that task (eg. a configure script for the bash package
failing to run on an years-old lynxos version because of a sh bug on
the OS), it still does a wonderful job in the end.
But I agree having to carry all this compat stuff, when one just wants
to benefit from higher-level features (like those mentionned by
Oliver), is annoying. Maybe the support for legacy platforms could be
restricted in some way to the bare minimum. Eg. using a "legacy"
backend where the cruft would go, and stubs for modern things, that
would generate a hopefully-more-portable-but-limited
./configure-simple script, and a "modern" backend generating a sane
full-fledged bash script.
But I'm going off-topic :)
Best regards,
--
Yann Dirson <ydirson@xxxxxxxxxx> |
Debian-related: <dirson@xxxxxxxxxx> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html