>>A programming language is made by humans and subject to the same evolutions
>>and bugs and in the end is alive and will die.
>>A programming language should evoluate, try to respond quickly to the
>>actual environment in order to survive or expand.
>>    
>>
>
>Have you *seen* how much time p5p spends on keeping little-used modules that 
>someone successfully argued were absoutely vital to the future of Perl now 
>and forever up to date?
>
>If you want to talk about responding quickly to the environment, look at the 
>CPAN.
>  
>

Yeah, I know that cpan is responsive, I spend my time installing modules
from cpan
and it helps me a lot.
even if perl goals and php goals aren't the same,
php is very responsive too and don't hesitate to incorporate quickly
PEAR modules
if they are goods.
Relying on modules has several drawbacks:
- too much namespace, kills the namespace:
use HiRes::Time::And::I:Cannot::remember::the::damn::namespace
- C based modules cannot always be installed according to your environment
- use the perl version of the module when you can and therefore slow
down the app.
- need this one module that has dependencies all over the place
all dependencies are not necessary so you rewrite some of the modules to
get rid off the dependencies
where you can.
in the end, I need to reinvente the wheel.

- No coherence, that is for me the biggest drawback. (php is absolutely
not coherent helas, but the doc!)
I guess that this is the main problem.

You need something that is not in the core, which in my case is about
95% of the time.
So you look for modules in CPAN.
After searching for the right namespace (sometime you think you have THE
module but a better one is
just hide in a place you couldn't think of...)
you dive into the documentation and therefore in the API, UI of the module.
Here comes the troubles...
5 modules, 5 API, 5 UI,5 docs, 5 universes...
I am very grateful for all the people that contributes to CPAN and there
is absolutely no need
for them to follow any conventions but in the end?

my $img = new AssetMediaFactory($path);
my $asset=$img->loadAsset();

In that case we are lucky, the module use the same convention
but you can have:

my $img = new AMF($path);
my $asset=$img->load_asset();
//or
my $asset=$img->ldass();

And I am not talking about the implementation in the background
using hahes, inside-out, modules that stimulate oop behaviors...
The way they handle errors,etc...
Some of them, rewriting functions that exist in other modules
but don't want to get a dependency...

And if you need to use the module in your framework and if you want
to stay coherent with your framework, you wrap everything.

Obviously, you have choosen the 100% perl module because you want
to be sure you will be able to use the same module almost everywhere.

all modules have their own particular universe, even if it is a well
thought one,
you have to immerse yourself into it and learning a mini-language everytime.

The doc is obviously free of real conventions so you have to search for
the info
thru all the paragraphs to be sure not to loose something even if you
don't need it.

SO?

Well, implementing modules in perl, getting rid off weird namespaces
(not all but with just 26 letters, you can handle a human language so I
guess a little thousand functions
shouldn't be that a problem), making it fast, available, coherent with
perl itself, perl documentation
will save many troubles.
Perl 6 could do without implementing the XML at a core level.
But why not create an interface, directions but not implementation.
Unfortunately, I deal with xml too (very helas!), json, raw data,images,
sessions, server connections,
Databases, pdfs, spreadsheets, url encoding...

is implementing all of this in the core a good idea ?
think not...

But I guess you got the picture.

I still think that a poll on the net could be a good idea.
Because when somebody comes here and say : I would like to know if this
is going to be implemented, what is the answer ?
'You need it. I don't'
and then :
'I need it but you don't but I need it'
...

A long time has passed since the apocalypses and exegeses.


-- 
シリル・デュモン(Cyrille Dumont)
[EMAIL PROTECTED]
our work is the portrait of ourselves
tel: 03-5690-0230 fax: 03-5690-7366
http://www.comquest.co.j


Reply via email to