# from Gabor Szabo
# on Wednesday 01 December 2010 13:46:
>Many modules on CPAN also need improvements.
>But even what we have today we could achieve much better results if
>the perception of people was better.
>
>With my original question I wanted to know what technological and
>perception related issues people see. We already got some material but
>I'd be happy to see more comments. Especially from those who work with
>people who are not involved in the Perl community. How do your peers
>and your bosses see Perl?
We have all heard the "conventional wisdom" that "perl is dead". But,
anything related to perception which cannot be solved by writing
modules is probably off-topic for this list.
Technological issues with the CPAN and its modules abound. We have 20+
years worth of code and archives to maintain and we're running short on
maintainers.
Maybe this was mentioned in the rest of this thread and I just missed
it, but I would say the one thing module-authors could do to improve
Perl is to write better APIs. Replacing some of the old modules with
cleaner APIs would be a huge improvement. How many core modules are
dripping with C-style error handling, numeric constants as switches,
etc?
Of course, if better versions existed, would anyone use them? Maybe
there will be some progress in removing core modules soon.
If CPAN is Perl's greatest strength, core modules are its greatest
weakness. While the documentation usually refuses to take a
prescriptive approach, the inclusion of some modules makes them
seem "recommended", and it always makes me sad to hear people jumping
through hoops and reinventing code just to get something to run with
only core modules.
But if you only let me pick one thing to fix, I would stop this tendency
to use one hashref as a single method argument instead of a taking a
named parameter list. It means typing two extra braces, which is more
noise on a line, and "the interpreter checks my hash for pairs" is
silly.
--Eric
--
"It is impossible to make anything foolproof because fools are so
ingenious."
--Murphy's Second Corollary
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
