Re: [Gnu-arch-users] Nit

[Colin Walters]

On Sun, 2003-10-19 at 00:22, Tom Lord wrote:

> You said that one reason to use multiple processes was to avoid I/O
> blocking. I pointed out that that isn't a good reason, in and of
> itself, and now you seemingly agree that that isn't a good reason --

No, it *is* a good reason, because all you'd end up doing is
reimplementing multiple processes...poorly.

Anyways, this branch of the discussion is now a complete waste of time,
given that it is predicated on a world where we don't have multiple
processes.  Since we clearly do, can we end this now, please?

So how about you respond to my arguments instead of cutting them out and
continuing to hypothesize about worlds without processes? 

Here's a good one, from Message-Id: <address@hidden>

[...]
But it's not
an argument for embedding a language inside tla.  You could do all of
the above just as easily with a language binding to libarch, and then
use your favorite programming language on top.

Now, if we find later that multiple tools are reimplementing things like
mirror manager libraries, then that means it's a good candidate for
pulling down into a C library, probably distributed with tla too.

Different languages are good at different things.  For example, if you
wanted to implement the above using GTK+, you really want to use an
object-oriented programming style.  Doing anything nontrivial with a GUI
in a procedural manner is just painful.  If we artificially restrict the
tla extension libraries to say Scheme (which lacks OO features), then
we've also restricted the classes of applications that people can easily
build.  

OO is just one example.  Another one might be parsing email messages. 
Python has a great library for doing this (as it does for lots of things
actually).  So if I'm going to be doing a lot of email parsing, that
would make me (personally) strongly inclined to use Python.  But if we
were restricted to using "tlascript" or something, it is unlikely to
have as good an email parser.

In other words, we should aim for maximum flexibility, let various
languages and frameworks compete on their own merits, and then see what
happens.  If say a Perl binding and associated tools come to
predominate, then we "bless" that binding with the status of being
included along with tla (although not required).  As we learn more about
the problem space, we refactor some of the Perl extensions back down
into libarch/tla/liboverarch.

signature.asc
Description: This is a digitally signed message part