>>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
