[sf-perl] One more reason why I use Perl...

[Shlomi Fish]

Hi all,

On Tuesday 11 May 2010 22:49:08 James Briggs wrote:
> On Tue, 11 May 2010 11:45:30 -0700 (PDT), David Thompson wrote
> 
> > --- On Tue, 5/11/10, David Fetter <david at fetter.org> wrote:
> > > From: David Fetter <david at fetter.org>
> > > 
> > > -0700, David Alban wrote:
> > > > wouldn't the comparison be more fair if they compared
> > > > HTML::Entities::decode_entities() source with the c++
> > > > and java versions?
> > > 
> > > I don't think so.
> > > 
> > > CPAN is Perl's killer application, and no other
> > > language I know of has anything really comparable
> > > to it.
> > 
> > Exactly.  I agree completely.
> > 
> > It is clear that C/C++ and other languages lack
> > The One extremely well known all-encompassing
> > web repository (on the huge scale of CPAN) that
> > is the absolute de facto go-to location for all
> > reusable code for all the world for all
> > programmers.
> > 
> > Only Perl has this scale.  CPAN is a monster
> > compared to the nearest code repositories of
> > other languages.
> 
> Well, CPAN is definitely awesome in many respects.
> 
> But most Python and PHP programmers are pretty happy with their expansive
> included libraries, 

Yes, but you can often find stuff on CPAN that isn't present in the shipped-in 
("batteries included") library of either Python or PHP, while they tend to 
have lesser halo libraries. I still recall having to register at an obscure 
download site, get a confirmation email in order to download some PHP code for 
implementing MIME handling because there wasn't anything better. (Don't know 
why their developer had not used SourceForge.net back then, which does not 
require registration to download the goods, but that was his choice). 

> and C++ programmers have Boost, which basically
> everybody uses these days:
> 
> http://www.boost.org/
> 

Boost is not necessarily synonymous with convenience libraries for C and C++. 
I've collected a list of similar libraries here (some of them written in ANSI 
C:

http://www.shlomifish.org/open-source/portability-libs/

Boost has several major drawbacks including lack of ABI backwards 
compatibility (also possibly API backwards compatibility). I also have a small 
demonstration program that a correspondent wrote that is written in C++ using 
pthreads which works fine when one uses only the C-derived printf()'s and 
hangs after a short while after replacing them all with std::cout (!). When I 
noted that problem, someone referred me to a blog post on an obscure Ubuntu 
forum where it is explained that std::cout has indeed a problem with multi-
threading. It is possible other libraries for C and C++ are more reliable than 
Boost or even the standard C++ libraries.

> CPAN's drawbacks include 10 of everything, and alarmingly poor IPv6
> support.

Well, I'd rather have 10 alternatives than zero as is often the case in other 
languages. CPAN's strength is in being open for every random Joe or Jane to 
upload their code there, so while there's a lot of junk, there's also a lot of 
quality code. Some people recently started the "Rethinking CPAN" effort to 
create better ways to find something of quality on CPAN:

http://groups.google.com/group/rethinking-cpan

There's been relatively little activity on materialising all the ideas (some 
of which are pretty good) but, nevertheless, with some guidance people can 
know how to find quality distributions on CPAN:

http://www.catalyzed.org/2009/07/finding-stuff-on-the-cpan.html

Regarding IPv6 - yes, this is a known problem. As someone who adopted 
http://search.cpan.org/dist/IO-Socket-INET6/ in order to fix SpamAssassin on 
Mandriva, and is otherwise relatively clueless about the details of working 
with the Berkeley Sockets API, it has caused me a lot of pain. Some people 
told me they want it to be IPv6-only, but this is impossible to do now because 
its documentation explicitly says it handles either that or IPv4, and changing 
it to IPv6-only will break backwards compatibility. 

Furthermore, a recent update which aimed to make IO-Socket-INET6 better 
perform on OpenBSD, has broken my Mojolicious app and the Mojolicious test 
suite, and I had to gradually reduce the Mojolicious code into a self-
contained IO-Socket-INET6 reproducing recipe, which I posted and was fixed 
(though the Mojolicious developers implied they had to hack around other IO-
Socket-INET6 introduced bugs, which I would prefer if they filed IO-S-INET6 
bugs for. I'm not sure about that.).

IO-Socket-INET6 also routinely fails tests on many platforms (possibly due to 
lack of good IPv6 support), and I'd prefer to keep it that way so people will 
know if it works them (and meanwhile have to suffer through the many failures 
on CPAN testers).

And finally IO-Socket-INET6 has some open bugs, that with some of them, I may 
lack the skills to properly deal with.

Fun, fun, fun.

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
http://www.shlomifish.org/humour/ways_to_do_it.html

God considered inflicting XSLT as the tenth plague of Egypt, but then
decided against it because he thought it would be too evil.

Please reply to list if it's a mailing list post - http://shlom.in/reply .