Dan Sugalski wrote:
> At 8:53 PM +0200 9/1/03, Christian Renz wrote:
> >Clemens,
> >
> >>"classpath"
> >
> >I guess the proper term would be class library. The path is only where
> >you look for the libraries :).
> >
> >It doesn't seem to be the Perl way to limit yourself to one option
> >only ("There's more than one way to do it").
>
> I'd worry less about the Perl way to do it, since we're more
> concerned with the Parrot way to do it, and that's when we have one
> way that's good enough we ship it, so people don't have to re-invent
> the bikeshed, or choose from a half-dozen identically shaped but
> different colored sheds. Which means that we ship a core that's as
> small as feasable, and an add-on pack (which we'll likely also ship
> with the core for an all-in-one install) with the best things we can
> find that are cross-platform enough to be useful.
>
> That means we'll shoot for a good set of networking modules for the
> various RFC protocols, a generic SQL database front-end, an (ick :)
> XML parser, a variety of cross-platform tools (filename conversions
> and whatnot), a set of xDBM interface modules, and some other stuff.
Do you imagine that the stock XML parser or xDBM will be written in a parrot language
or will it be a c lib used through NCI?
>
> Don't forget there is an issue of us wanting to be a good core for
> more than just perl. The Python parrot package would have Python's
> standard module set, the Ruby package would have ruby's modules, and
> the Perl package would have the perl modules. There's a fair amount
> of overlap and I expect people both want their modules and *don't*
> want two or three alternate versions of the same modules installed. I
> could be wrong, of course.
Is one of the advantages of a multi-language interp not to combine the
libraries of each language, to capitalize on the strength found in one
language for the benefit of the other? And would a unification of those libraries
be outside the scope of parrot or would it fit right in?
>
> GUI stuff's a massive pain, as you either get cross-platform which is
> ugly and awkward everywhere, or platform-specfic and useless anywhere
> but on the platform in question. And I'm pretty sure that, no matter
> *how* Insanely Great the OS X Cocoa interface modules are, they're
> not going to do MSWin folks much good. :)
>
> As for sound... Yeesh. There's a swamp I don't have enough castles for.
>
> However, since we have a good native interface it should mean that
> many modules that now require a compiler for can be done entirely in
> parrot bytecode, which should mean that it's far easier for people to
> install and reduce a lot of the pain. Also we've a fair amount of
> experience in the perl world with network module installation
> systems--we know some things that do work, and some things that
> don't, and I expect we should be able to leverage that to make a
> system better than what we have now. (Which, honestly, is pretty
> darned good, especially given the limited information it has
> available to work with)
I want to ask for clarification here. You mean that the design of NCI
will allow c libs to be wrapped using just parrot code instead of additional
c code as in XS?
I agree that the perl system is pretty darned good. But I don't know if our
admins (who make there lives very difficult with lack of user policy vision)
would agree. I believe they would says it's the best of the other languages they
work with except for c/c++. I also would agree that the libtool/autoconf system
is more reliable then some of the XS code available from CPAN. And although this
does not bother me because I enjoy working with perl. They really don't care what
the boxes do as long as the boxes are doing it.
Also building a mysql/apache/mod_perl/libxml/ environment is very challenging WRT
customers
and clients. In very few instances would I expect a low level admin to accomplish such
a task
in a reasonable amount of time.
Knowing very little about this stuff I have always wondered why I need to rely so
heavily on
certain features of the installed system. I would like to compile byte code that
includes the
byte code for modules I am using. I realize that creates a certain undesired coupling.
But in
some instances especially WRT to client/customer apps it would prevent upgrading
modules
outside of your control.
> --
> Dan
>
> --------------------------------------"it's like this"-------------------
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
--
Be nice I'm new
Damien Hogan
