Subject: Re: making 'make replace' safer
To: Peter Schuller <firstname.lastname@example.org>
From: Raymond Meyer <email@example.com>
Date: 07/16/2006 22:07:10
On Sun, 16 Jul 2006 22:41:57 +0200
Peter Schuller <firstname.lastname@example.org> wrote:
> > All sofware should be written in one language. This is my pet hate, when
> > you need to use a simple tool, but in order to use it you have to install
> > C++, Perl, Python and a whole load of other useless dpendancies that
> > consume 100s of MB of disk space.
> I would hate to live in a world with only one programing language. :)
> But is this such a huge practical problem other than for embedded systems and
> such where you aren't really likely to be in such a need of package managers
> to begin with?
> I mean perl/python/ruby and such is used all over the place; many
> installations will already have it. Would you consider it a show-stopper for
> using a package manager, that it depended on, for example, ruby?
I don't know, depends on how useful it is
I've never used ruby, so I don't how much extra bloat it carries. Why use
another language when something could be done in C? Unix is written in C so
that's what everybody needs to use. The problem is, there is no coherence when
people start using different languages or frameworks. For example, in order to
have a few simple GUI applications, like my favourite text editor, audio
player, pdf viewer, etc, I end up with gtk, qt, motif and many other libraries,
that do more or less the same thing (display pixels on the screen) but are
written to be incompatible with one another and different from one another.
This madness has to stop, sometimes I hate free software, there is too much
forking and code duplication. And of cause, each different
language/library/framework has its own bugs and problems, some things work
here, other things don't quite work there. I know there isn't one tool for all
the jobs, but I do feel that Unix people have to agree on a set of standards,
instead of reinventing the wheel over and over again.