Comment by einhverfr | Hacker News Reader

Comment by einhverfr | Hacker News Reader

Hmmm... This article strikes me as relatively missing a few things.

Perl 5 is a mature language. There is a lot of effort at building Perl 6, but at this point it doesn't really look like Perl 6 will be a successor to Perl 5 (the metaphor now is "little sister"). It's so different, it is like learning a new language.

Now, I do a lot of programming in Perl. I have done some scripting in Ruby, Python, PHP, and more, but I always come back to Perl because the language is remarkably flexible. (Rebol is probably the second I frequently come back to, and Red looks promising.)

Predicting the demise of Perl is relatively premature. I don't think we will ever see Perl 6 supplant Perl 5. Rather these will become different languages (with a relationship similar to that of C vs C++).

Now you can write crap code in any language, and I just love how Python gives invisible characters semantic meaning (not), a problem that is likely to get worse as the number of whitespace characters continues to proliferate (not just plain spaces and tabs, but non-breaking spaces vs regular spaces....).

What perl has lost is the "let's quickly throw together an app" crowd. That crowd has gone sometimes to Python, sometimes to Ruby, and sometimes to Lua. From where I stand, good riddance. This is what gave Perl a bad reputation in the past.

To plug my own projects, right now I am working on a framework for delegating Perl object methods to PostgreSQL stored procedures.[1] At some point I may port the work to PHP and Python, but currently Perl is where this is really going for me. The thing is that such work is not applicable to the "throw together an app using an ORM or NoSQL fast" crowd, but it allows for some very sophisticated, powerful, and robust business tool development.

Additionally I have to plug http://cpantesters.org. This is a really really useful piece of the Perl community. I got a test failure report today for PGObject::Util::DBMethod failing to load in Perl 5.6.4. My first thought was "who the heck uses Perl 5.6 anymore" and my next thought was "I guess I had better start adding minimum Perl versions to my Makefile.PL."

[1] The two most important pieces are https://github.com/ledgersmb/PGObject-Simple-Role and https://github.com/ledgersmb/PGObject-Util-DBMethod

> a problem that is likely to get worse as the number of whitespace characters continues to proliferate (not just plain spaces and tabs, but non-breaking spaces vs regular spaces....).

I know that people love to hate on Python's semantic whitespace, but this is the first time that I've seen someone argue that Python's lifespan is limited because we are about to enter a period of exponential growth in the number of whitespace characters.

Where do you feel that this growth in the number of whitespace characters is going to come from? Do we not already have a plethora of whitespace characters in the current Unicode standard, in addition to things like the vertical tab of yesteryear that languishes in the ASCII standard? How come we don't see any of these issues now, even with the number of whitespace characters that we already have at our disposal?

> The thing is that such work is not applicable to the "throw together an app using an ORM or NoSQL fast" crowd

Are you trying to imply that using an ORM is the sign of someone trying to "whip something together fast?" What are your feelings on DBIx::Class? Should those people who use it jump ship to some other language so that you can bid then "good riddance?"

> I know that people love to hate on Python's semantic whitespace, but this is the first time that I've seen someone argue that Python's lifespan is limited because we are about to enter a period of exponential growth in the number of whitespace characters.

I think the various Unicode whitespace characters are likely to gain more use generally. The big problem though is that whitespace characters all look alike and so you can't read and parse the way a computer does.

> Are you trying to imply that using an ORM is the sign of someone trying to "whip something together fast?" What are your feelings on DBIx::Class? Should those people who use it jump ship to some other language so that you can bid then "good riddance?"

Not really. ORMs can be used in significant applications and in fact a lot of people use DBIx::Class that way in Catalyst etc. I am referring specifically to the quick and dirty app crowd. You have PHP, Python, Javascript (via Node.js) and Ruby largely taking that role over. And that's fine. Perl is a wonderful language, but to write good quality, maintainable, robust code in it takes some work. But that work is well rewarded.

> I think the various Unicode whitespace characters are likely to gain more use generally.

I'm curious what you expect these increased usage to stem from, and how you feel that it will inevitably find its way into source files.

> The big problem though is that whitespace characters all look alike and so you can't read and parse the way a computer does.

In general, the editor takes care of indentation for the programmer. What developer is going to add (e.g.) non-breaking spaces as an option for indententation in the development tool that they maintain?

If you're worried about copy-pasting, then that's already an issue in some places. I've had SQL break because the whitespace contained invisible characters due to an encoding issue during copy-paste, and PostgreSQL (IIRC, could have been Oracle) wasn't very helpful in diagnosing the issue.

Unexpected invisible characters cropping up anywhere are going to give you issues, Python or not.

> I think the various Unicode whitespace characters are likely to gain more use generally. The big problem though is that whitespace characters all look alike and so you can't read and parse the way a computer does.

I think the big problem is, that there are people out there, that think Python programmers have a huge urge to use non-standard whitespace characters in their source code.

> Perl is a wonderful language, but to write good quality, maintainable, robust code in it takes some work. But that work is well rewarded.

The reward for that kind of code is the same in all languages, but your statement implies, it's maybe better to choose a language, where it's not as hard as with Perl to write good quality, maintainable, robust code. Point taken.

Writing good perl code is easy once you sign the social contract.

Writing good code in any language is remarkably time-intensive to learn. There are any number of ways to mess up code and the coding patterns and antipatterns are different in any language.

It takes struggling with the ways of doing things in the language and seeing what works and what does not. Perl is no exception, except that there is no One True Perl way. Every Perl programmer finds his or her won way.

Reply on news.ycombinator.com