|
Re: Modules in core perl5 and perl6
by Corion (Patriarch) on Apr 26, 2005 at 08:01 UTC
|
To get a module into the Perl5 core, you need to successfully lobby p5p. The two most interesting candidates to watch this process are currently CPANPLUS and Module::Build. Both of which are caught up in a twisted maze of unfulfilled prerequisites, all different.
The Perl6 core is still thought to be minimal - most likely, it will contain the Perl6 version of Test.pm, and I like to entertain the idea that a minimal version of LWP::Simple will be in it, together with a minimal CPAN / 6PAN module, to make module installation uniform and less painful than it currently can be. The lib module already is in the core, and likely some instance of File::Spec or URI::File will be in the core as well.
The concept of "new modules in the core" is likely to be wrong, because there will be less modules in the Perl6 core (if any more than 20 or 30 non-platform specific modules) hopefully. This will obviously require that module installation Just Works, but on the other hand, it will result in a much smaller Perl6 core.
| [reply] |
|
|
Any chance we rename LWP::Simple to something more descriptive? Perhaps something along the lines of Network:: or Protocols:: or something?
Also, the more modules are in the core, the easier it is for people to use Perl. Look at PHP, most stuff you (don't) want to do is already in the core, you almost never have to use PEAR to install additional modules.
| [reply] |
|
|
Renaming LWP::Simple is an interesting idea, but I'm notoriously bad at naming things, so I won't do anything in that direction.
If I look at how big the Perl5 core got and the amount of problems that there are with unmaintained-yet-core modules and the size of a "minimal" Perl5 installation, I'm all for a small core, together with a painless, working, transparent way of installing new modules. Modules are what differentiates the Perl model from the PHP model - with the PHP model, you have to rely on the people in the cathedral to provide for your needs, while with Perl modules, anybody can write, distribute and install them. By moving stuff into the Perl core, you take that possibility away from people and force them into the version release lockstep.
| [reply] |
|
|
Also, the more modules are in the core, the easier it is for people to use Perl.
The more modules in the core means that maintainance is harder, as part of the resources will need to go to maintaining the modules. Which means that bugs will take longer to fix - resources are limited. Which will make Perl actually harder to sell, and less easy to use. ;-)
But there is NOTHING at all that prevents YOU (or anyone else) to create a Perl6 distribution that include fifty thousand modules. In fact, there's nothing that prevents YOU from creating a Perl5 distribution that includes fifty thousand modules. (Except perhaps finding fifty thousand modules). If you think it's important to have a distribution that includes many modules, then go ahead and MAKE ONE.
I'm amazed how many people say we need larger distributions, but no one things it's important enough to make such a distribution him/herself. The "we should make" always means "someone else should make".
| [reply] |
|
|
Hear, hear! In some corporate environments, it's a pain in the butt to get new modules installed globally (since I need them on about 200 machines, 175 of which I don't own, and 150 of which I don't know about). If all the buzzwords were covered (HTML, XML, SOAP, SMTP, etc.), it'd be so convenient.
That's not to say it's not worth fighting the corporate environment to get those modules. It's just that it takes months to get there. (Perl 5.6->5.8 upgrade taking over a year, ... and counting. We were originally going to use 5.8.1 as the brand-new perl at the time.)
| [reply] |
Re: Modules in core perl5 and perl6
by dragonchild (Archbishop) on Apr 26, 2005 at 13:03 UTC
|
Given that P6 will be written on top of Parrot, it's likely that many of the modules you use won't be written in Perl. Instead, they will be written in other languages, like Ruby or Python or Java. So, they won't be in the Perl core. This is a "Good Thing"™.
I'm already looking forward to writing in Haskell, using Perl's proven ability to read/write a bazillion file formats, while riding Ruby-on-Rails on top of a Java GUI.
Seamlessly.
The Perfect is the Enemy of the Good.
| [reply] |
|
|
I'm already looking forward to writing in Haskell, using Perl's proven ability to read/write a bazillion file formats, while riding Ruby-on-Rails on top of a Java GUI.
What no python?
| [reply] |