Perl considered harmful.

| | Comments (15) | TrackBacks (1)

I've recently been handed an assignment that requires me to write some Perl code. I'm not a fan of Perl anymore. I haven't used it routinely in almost seven years. It certainly filled a very useful niche in the '80s and early '90s, but by 2008, I think it's been superceeded by Python or Ruby. Frankly, I think it's an anachronism. But this isn't a blog about programming.

I've griped about the shoddy IPv6 support in Perl before. This post is in the same vein.

This code needs to use Perl-LDAP. Natually, I checked if that library supports IPv6 (remember, kids, in Perl, you have to check if every single library supports it!). Fortunately, it got support a few months ago, in version 0.35. All's well, right? Not so fast, kiddo. The changelog says it "add option to support IPv6". What does "option" mean?

Looking at the docs, I found this gem:

inet6 => N

Try to connect to the server using IPv6 if HOST resolves to an IPv6 target address. If it resolves to an IPv4 address, the connection is tried using IPv4, the same way as if this option was not given.

Please note that IPv6 support is considered experimental in IO::Socket::SSL, which is used of SSL/TLS support, and there are a few issues to take care of. See "IPv6" in IO::Socket::SSL for details.

So let me get this straightish. To get IPv6 support in my LDAP apps, I have to pass a special "no, really, use IPv6" flag to every LDAP object I create? What happens if the hostname resolves to both an IPv6 and an IPv4 address? And I better just hope that I'm not using SSL. This is just charming. But it gets better. If you follow the link to IO::Socket::SSL, you find this:

Currently, there is no support for using IPv4 and IPv6 simultaneously in a single program, but it is planned for a future release.

Gah! You can't possibly be serious. Java has supported SSL-over-IPv6 and mixed v6-v4 apps for 5 years! Hell, it's supported it for so long that the first version to get support is now EOL. Python has had support for the same amount of time.

Folks, this is not the way to design a maintainable, supportable, enterprise language. How people continue to use Perl in production totally escapes me. And this does not bode well for IPv6-enabling the large mountain of legacy Perl scripts that hold this University's IT systems together.

1 TrackBacks

Listed below are links to blogs that reference this entry: Perl considered harmful..

TrackBack URL for this entry: https://blogs.psu.edu/mt4/mt-tb.cgi/12423

» Improved IPv6 support in Perl from Living with IPv6

I've blogged before about the shoddy support for IPv6 in Perl. Last week, Perl 5.14 was released with improved IPv6 support in the core distribution: Improved IPv6 support The Socket module provides new affordances for IPv6, including implementations o... Read More

15 Comments

Ann E. Mouse said:

Wow, you actually got java to work with SSL?

Michal said:

Heh, I second that! About a year ago I had to write something in perl because the client has all their scripts in perl. I had to choose whether to support SSL or IPv6. But not both because the perl networking libs totally suck.

Truman Boyes said:

Interesting post. This made me think about the JUNOScript/XML PERL libraries that I use to connect to various routers and push their configurations. They include dependencies on SSL libraries which will likely cause a problem if connecting to IPv6-only routers. I think the while OSS industry is going to have a lot of trouble supporting IPv6 in their existing software.

Truman
www.truman.net

Truman Boyes said:

Interesting post. This made me think about the JUNOScript/XML PERL libraries that I use to connect to various routers and push their configurations. They include dependencies on SSL libraries which will likely cause a problem if connecting to IPv6-only routers. I think the while OSS industry is going to have a lot of trouble supporting IPv6 in their existing software.

Truman
www.truman.net

Stevan Little said:


Hmm, why not fix this yourself and send a patch to the author of IO::Socket::SSL?



I suspect that if you employer is insisting that you use Perl and you require this feature, they wouldn't have a problem with you spending time to implement it and send in the patch. At which point not only you benefit, but all the other users of IO::Socket::SSL do.



Note this in the IO::Socket::SSL docs:


Support for IPv6 with IO::Socket::SSL is expected to work, but is experimental, as none of the author's machines use IPv6 and hence he cannot test IO::Socket::SSL with them.

Seems that that author of the module doesn't have a need for IPv6, so to expect him to spend his free time adding support for it is kinda of asking a lot. Remember, Perl doesn't have a big corporation like Sun or Google (where Guido works now) behind it, it relys entierly on volunteer labor for things like this.



- Stevan

Derek Morr Author Profile Page said:

I might end up fixing it myself.

As for the author testing IPv6, he could if he chose to. He could configure two machines with link-local addresses and test connectivity.

I agree that Perl doesn't have a big corporation backing it. To me, that's all the more reason not to use it in an enterprise :)

Kyy said:

I'm sorry; I love hating on Perl as much as the next guy, but languages can't be blamed for being caught flat-footed by major changes to their foundational structures that come _after_ the languages are created. [RFC2460](http://www.ietf.org/rfc/rfc2460.txt) that defines IPv6 is dated December 1996. I don't even care to guess at when it was actually taken seriously by, well, anybody. By that time, [the Perl 5.6 development track was running](http://search.cpan.org/dist/perl/pod/perlhist.pod). Look at the number of languages still reeling from Unicode changes... same thing. (Arguably, this goes a long ways towards explaining Lisp's problems with large-scale acceptance.) Oh, you think it's easy to guess ahead? You think that everyone developing in Perl should have seen this coming? (And mind you, not just "the core perl developers" but every library developer writing a library that touches sockets.) OK, wise-guy, tell me the changes you will need to make to your favorite language to adapt to the next OS that will have 50% market share that isn't Unix- or Windows-based. And I don't mean "guess", I mean, _know_ which language changes are necessary. You can't. Ultimately, a language must depend on certain things for it to be able to do anything for it to be even remotely usable and useful, and when those things change out from underneath it, bad things happen. This is inevitable.

Derek Morr Author Profile Page said:

I understand your point, but I have to respectfully disagree.

Socket support isn't a "foundational structure" of Perl. It's supported in an extension module. Why wasn't the socket module extended to support IPv6? I'm not arguing about the core language. I'm arguing about the (poor) design in this part of its standard API (to the extent that Perl can be said to have one, since it largely depends on third-party modules). As I mentioned in a post a few months ago, why can't I use a single API to write IP-version-agnostic code in Perl? I can do that in C, Python and Java.

I don't buy your argument that languages can't be held accountable for lack of support of newer standards. C predates IPv6 (and Perl), and yet it fully supports IPv6. Yes, any "legacy" C code has to be updated to use the new v6-aware APIs. But every modern OS has supported those APIs for years (they're part of POSIX 1003.1g-2000, for example). Likewise, Python's IPv6 suppor was cleanly added to its socket module. Python is almost as old as Perl, and it also predates IPv6.

In neither C nor Perl do you have to resort to hacks like checking for a special IPv6-aware socket module and then branching accordingly every time you need to make a call to the resolver or socket functions. Nor do you have to pass special "use IPv6" flags to other libraries. On any reasonably modern Python installation, the ftplib, httplib, poplib, smtplib, and telnetlib modules (to name a few) will automatically use IPv6, if available. That's a much cleaner design.

anonymous said:

Actually, the perl AnyEvent module supports version-agnostic ipv4 and ipv6
sockets, with a lot more features than those other languages (transparent
TLS, asynchronous dns, os-independency, srv-records, sctp etc. etc.)

Even without that module, sockets *are* a "foundational structure" within
the Perl interpreter and NOT implemented in external modules, and yes,
all of that *has* been extended to support ipv6 many years ago. The
built-in's mirror the C interface almost exactly, too, so if you can do it
in "legacy" C you can do it in perl for over a decade now, too. In fatc,
pelr was one of the first scripting languages to support ipv6 within the
interpreter.

As a proof of that - AnyEvent doesn't require any non-core module to
implement all that.

So a bit less whining and a bit more researching would go along way
towards a better world, or so *g*. But these days even people who don't
even care to read the documentation think they cna just go out and spread
f.u.d.

PS: name and e-mail address required for anonymous comments? what kind of
joke is that?

Derek Morr Author Profile Page said:

In C, the legacy gethostbyname() function does not support IPv6. Its replacement, getaddrinfo(), does. Perl only has gethostbyname() as a built-in function, and in my testing, it does not support AAAA records.

I just took a look at the source for AnyEvent. It implements its own stub resolver.

So, my argument stands: The core Perl language does not support IPv6.

anonymous said:

You should probably look again..

Derek Morr Author Profile Page said:

What were you referring to? The AnyEvent source? Would you care to be more specific with your comment?

Jarrod Johnson said:

I will say the support is named peculiarly, but it inherited it from C. As a result, many developers are confused about using INET v.s INET6. The answer is to just use INET6/Socket6. It can handle IPv4 just fine, it's just named to reflect that it can accomodate IPv6. They couldn't change Socket without breaking copmatibility in some ways (largely because of C considerations) so they produced an extend version of it and called it INET6.

IO::Socket::SSL seems to worry about it and incur undue worry to documentation readers. I'm using IO::Socket::SSL concurrently in the same process with IPv4 and IPv6 without issue.

Toivo Voll said:

We have some network management scripts written in Perl and I just ran into the same issue. Luckily I found your post (and some others) instead of spending fruitless hours trying to figure out why the programs won't work with our new IPv6-only networks.
They rely on modules such as Net::Telnet::Cisco and Net::Telnet which seem to have no convenient way of enabling IPv6 functionality that a relative novice can figure out. Consequently, we're forced to look at other languages to recode the existing apps (since obviously rewriting is required either way.)

Andre said:

Perl needs a relook at how it handles IPv6 and it better be a proper thought out part of Perl 6 (if that ever get released). I tried using libwww, but it does not support IPv6 and the indication is that won't be resolved until IO::Socket::SSL relooks at the way it supports IPv6.

It should be noted that until this is resolved the W3C HTML Validator won't support connecting to IPv6 servers for validation of content.

Leave a comment