The article "addresses Perl's perceived problems" more then it tries to find what the real problems of Perl are.
So here's my take on it:
1. Syntax. And how it's almost impossible to change it after a certain level of language-adoption. Perl coders knew it needed to be radically changed, understood how that was impossible, and moved on.
2. As a result of 1: the shrinking community. It is a clear red flag, no-one wants to start a project in based on (soon to be) legacy technology.
3. The existence of very suitable languages for Perl-refugees. When Perl ruled the web it was pretty much the only open source, web-focussed, runtime-typed language with a package manager fully of goodies. But with Ruby, Python (, etc.) and their very active communities around, it became very easy to switch.
4. It missed academic backing. Having programmers "schooled" in a particular language seems to be important in this world. The winners in this area seem to be Java, C-Sharp, C++, C, Python and to some extend Haskell; Perl never managed to enter this league (and does not seem very fit).
For a while at least, Perl did find a home in Linguistics. While it was because of the excellent text parsing tools, it makes a strange kind of sense as well, since Perl was designed to be a bit more like a human language and I think Linguists appreciated that. But that's such a small field that the impact was negligible. Most of the modern Computational Linguistic work is done in Java and Python these days, but for a while, many people working in Linguistics came out of their undergrad with at least a passing familiarity with Perl.
For a briefer spell, I seem to remember Perl finding a home in bioinformatics for much of the same reasons. I have no idea what or if that field has moved on to.
For me personally, Perl was the ultimate hacker language when people needed to get shit done and that shit involved munging lots and lots of files in text. But I think these days the world has moved onto other things that Perl isn't any better suited for than some other language (which is then conversely better suited for a bunch of other stuff than Perl).
I learned Perl in college. It was also my first introduction to Linux. Having many Linux oriented commands baked in as first class citizens really helped cement a lot of complex concepts in my mind.
That being said, teaching a language, vs using a language to teach can be two entirely different animals.
What little I've seen were using pygr these days. I still love Perl, though. Maybe if $_ and co had 'friendlier' names people wouldn't be so put off? I don't know, I think it simply allows for too complex a syntax and that can allow people to make 'write only' code.
> Is the difference between arrays and array references really necessary?
This is certainly a annoyance compared to e.g. Ruby. It's getting easier to just always use references [0], but I haven't been using Perl much for a few years and am not sure if this is still considered experimental.
I agree with most of what is here save for the Perl 5/6 issue. Perl 5 needs a name change of some kind or another (Since Perl 6 isn't going anywhere or changing its name). You can't really write it off as people not "understanding how version numbering works" when the common way it works is by incrementing the major number when a new version is out.
But that's my point. People do understand how version numbering works. But Perl is trying to change that by saying that Perl 6 isn't the next major version of Perl - it's just another language in the Perl family. I think that just confuses people.
Personally, my guess is that once the performance issues with Perl6 have been solved and there's proper Perl5 and CPAN integration, the whole sister-language-instead-of-next-version thing will go away.
You're right about Unicode and Moose. But I've never heard a Ruby programmer complain that there is no central repository for Ruby gems. Like, I don't know, rubygems.org .
Every language has one, but it doesn't come close to the breadth of CPAN. Much of it has to do with the culture set for maintainership. You have to achieve a certain kind of test coverage to get included, and if you are absent as a maintainer you package goes up for adoption.
I'm convinced that talking about CPAN as a unique thing just makes Perl programmers appear out of touch with regard to other languages. I am impressed with CPANTS, but saying "we have CPAN" isn't enough anymore.
Perl5 don't just needs a name change. It needs management and capable developers. Maybe the CPAN authors should take over. They keep continuing to produce quality software and updates. The number is the smallest problem they have.
That's a horrible idea. The branding of Perl 6 has already been established. Trying to hijack it won't be beneficial to either project.
The next release in the perl5 series could be Perl 7, similar to what PHP [0] has done to avoid confusing their next major release with a previous, failed effort to create a new major version.
That still forces perl6 to rebrand but won't induce massive confusion.
Are people still complaining about the version number? If only there were a simple way to get people talking about Perl again. Personally, I think the best approach would be to (1) recognize that every language has a CPAN equivakent so stop using it as a unique selling proposition (or, at least make it better than everyone else's), and (2) keep implementing cool things in Perl. Prove that Perl programs that do a lot of things (1) are maintainable, and (2) don't have to be as large as the equivalent in other languages. Arguing about the version number just isn't enough.
Npm. It's meant for Node-js code, but you can use it to make sure modules are installed in your source directory for a website. Aside from npm, there are public CDNs available ( http://www.jsdelivr.com/ and https://cdnjs.com/ ).
I'm surprised that this wasn't cited in this article as a problem.
Larry is a brilliant guy, but (like everyone, really), he's not brilliant in everything and (like most people seen as absolute geniuses, so relatively few people), what he's not good at, he finds so frustrating as to condemn it, and cry foul at the very concept. This helps no one.
I've always found it funny how many of the people who decry Perl as being "line noise" will then go on to praise such languages as APL, J and K. I think it might be because of their more esoteric paradigms and the fact that they do not follow the formulaic Von Neumann architecture, making them good targets for people to assert how atypical they are, unlike those other Blub programmers.
> I've always found it funny how many of the people who decry Perl as being "line noise" will then go on to praise such languages as APL, J and K
This is not a reality with which I am familiar. I like the idea of APL; I even did some, years ago, but this feels strawman-y to me. Even in the J/K/APL crowd, the running joke is readability.
From a distance I'd say APL* having one datastructure and many (cryptically represented) operations. Think Alan Perlis (NPI) epigram (http://www.cs.yale.edu/homes/perlis-alan/quotes.html). Perl context sensitivity with many builtin types is like combinatorial explosion of cases and is harder to parse mentally.
APL has really well thought out notation for manipulating n dimensional tensors and even arbitraritly nested n-dimensional tensors, its more concise than what mathematicians would ordinarily use when they talk about them and certainly nicer and more expressive than explicit einstein index summation conventions. So there are good reasons to praise it. The use of symbols in perl to introduce separate name spaces for the basic types etc. is sort of orthorgonal to the use of symbols in APL, although personally I don't find anything wrong with it.
It's kind of sad that functional programming lanuages have regressed and treat higher dimensional tensors so poorly. Libraries like repa for haskell are nice, but they don't approach the flexibility of APL.
Representing "this language has operators" as the complaint about haskell is a bit disingenuous. It is that haskell has way too many operators. Operators are fundamentally unreadable, even if they are nicely writable.
Haskell doesn't really have that many operators built-in (that is, in the standard Prelude). Haskell is completely open to user-defined operators (whose names can either be alphanumeric or symbolic), which, combined with the fact that symbolic operators often are attempt to approximate symbols from the application domain in ASCII while avoiding duplication of symbols used in the prelude even if those in the application domain are the same as those used in the prelude often results in less-than-intuitive choices.
Whether this is more or less readable than alternatives, though, is pretty subjective -- operators are generally used to reduce visual complexity in a way which is (given the constraints discussed above) as familiar as practical given the notation used in the domain, so even with the problems introduced by those constraints I think it often results in code that is at least as readable, and often more, than the cumbersome structures that are the alternative in languages that don't support user-defined operators.
I don't think I've ever seen code (in any language) that restricted itself to the Prelude (or its equivalent). What matters is what typical code looks like, and while I like haskell, I believe it's a major weakness of the language that, whether by design or idiom, typical code appears to prefer terseness over good names, and operators over descriptive function names are the most noticeable aspect of the problem. I think mathematicians could use to learn the lesson that descriptive names are nice, rather than programmers learn the lesson that terse domain-specific operators are better.
>typical code appears to prefer terseness over good names
Or to phrase it another way, typical code prefers good names over lengthy names. See, having a preference is fine. But acting like your preference is objectively correct is not.
I don't think I'm objectively correct, and I struggle with the balance between peppering around a bunch of "I think"s and "in my opinion"s and just writing what I think directly and hoping people can tell that it's just my opinion.
Since that didn't work, I'll be more explicit: in my opinion, an unfamiliar operator is usually both a terse and a bad name.
But then it is reduced to simply saying "I don't like it", which is not useful or meaningful. A discussion is not useful if it is just people going "I don't like X", "well I do like X". Yes, haskell programmers tend to prefer short names. If you want to argue that this causes it to be unreadable then feel free, but you are just saying it rather than making an argument for it.
Recognizing that an opinion is not objective fact does not preclude making an argument for it. (If it did, there would be very little discussion in general.)
My argument is that I believe using descriptive words, even if they are longer, usually makes concepts easier to understand while reading than using either terser words that are less descriptive or symbols that are not in common use. That's not fact, but it's different than just saying "I don't like X".
Ok, but that isn't what you said. You said haskell has way too many operators, and operators are fundamentally unreadable. Neither are true.
The problem with your new argument is that it is just rephrasing "if I don't learn X, I don't understand X". The operators commonly used in haskell are in common use, by definition. Haskell is not unreadable just because you didn't learn how to read it. No, basic_arithmetic_addition_function is not clearer than +. So why would needlessly_long_name_that_conveys_no_extra_information be clearer than >>=?
You know what, you're right. Operators aren't at all "fundamentally unreadable", that was a dumb thing to say.
Operators in common usage, like ">>=", are not at all a problem, because as you suggest, they only need to be learned once and aren't easily forgotten. Operators that are never used are also not a problem, because they are never used.
But I do see a problem in the middle, where I see an operator, figure out what it does, and then don't see it again for some time. Re-learning less frequently used operators constantly is not very efficient.
Your fake names are a false choice. The trick is to find good descriptive names, and using a name that is annoyingly long is probably worse than using one that is frustratingly terse. The trick is to pick a good one.
> Re-learning less frequently used operators constantly is not very efficient.
You could also say:
> Re-learning less frequently used command line programs constantly is not very efficient.
However in my experience re-learning is much easier than learning the first time. For instance if I've used a command line program before I can glance at the manual and figure out what I need very quickly.
Sure. But my point is that good names make it even easier because they act like a refresher. Unix command line programs could also use to be better-named. "cat" and "ls" are example of fairly poor names (but again, common enough to not be a big problem!), whereas "head", "tail", and "echo" are much better because even if you forget what they do, the names themselves refresh your memory! Naming things well is definitely hard, but it's worthwhile.
I generally hold that it's simply a matter of whether the language is optimizing for beginners, intermediate level users, or experts.
Terse code is useful for domain experts, it allows them to quickly assess what's happening without having to read a lot, and have more of the program logic in the field of view at a time. Unfortunately it's hard for beginners to understand because a lot is implied through idiomatic usage.
Verbose code is easier for beginners, but domain experts may find it cumbersome and a chore to both read and write.
Perl has found an interesting spot on this spectrum, as through TIMTOWTDI it has the capacity for verbose code, as well as terse, idiomatic code. I'm not sure if that means it's optimized for intermediate level users, or if it's just schizophrenic.
Yes, they are certainly hyperbolic. But the idea was to make the point that longer is not better. If a variable has a short scope, you do not need to constantly be reminded what it is. If a variable is very general, a very general name is fine. Generally haskellers consider names like 's' and 'x' and 'i' to be very good names. Code is generally optimized for being read by people who know the language, not by people who are unfamiliar with it.
Your single-letter-name examples reminded me of some of the articles awhile back about church numerals, which of course used "s" for "successor" and "z" for "zero". One of the comments on one of those articles was somebody who clearly read the whole article without having a good guess at what "s" or "z" were supposed to mean.
I found myself wondering what the point of using "s" and "z" instead of "succ" and "zero" could possibly be, besides some sort of mathematical bravado.
Because they are easier to read, and make the program clearer. Your anecdote is precisely what I was talking about. It doesn't matter if people who have not yet learned the subject don't understand it. It matters that people who have learned it understand it. People who have learned haskell find short variable names make the easiest to read code.
I would suggest that is obviously false. Most languages have operators. Is 4+5 really less readable than plus(4,5)? Haskell does not have very many operators. The fact that people see 3 operators they are not familiar with and decide "this is unreadable because of so many operators" speaks rather poorly of people's desire to learn.
I think "4+5" is readable because I read it as "four plus five", and that operators become un-readable when you can no longer insert a common descriptive word in their place. The problem in haskell is not the few operators in the prelude that are unfamiliar, but the multitude defined in libraries.
In fairness, there are good ways to search the documentation for those operators so at least you aren't stuck googling for line noise.
Bind a function which gets the contents of my system tmp directory to a function which takes anything and returns a monad, then return the evaluated monadic result.
But you can insert a common descriptive word in their place. Choosing not to learn what >>= means doesn't make it unreadable or line noise. That is like saying C++ is unreadable line noise because it has all these -> all over the place.
> The current version of Perl (5.20.1 as I write this) is a lot different to the version that was current when Perl 6 was first announced (which was 5.6.0, I think)
Wasn't "Perl 6" just a tentative spinoff from "Perl 5.6", and didn't Perl programmers start unofficially refering to subsequent versions of Perl 5.x as "Perl x", i.e. Perl 5.7 as "Perl 7" and the latest version as "Perl 20" ? Better make official how Perl programmers are speaking anyway and call the next version Perl 21.0
Wasn't "Perl 6" just a tentative spinoff from "Perl 5.6
No. Perl6 is a complete redesign of the language, unencumbered by backwards-compatibility. One of the design goals was to make it extensible on as many levels as possible (proper specification, multiple backends, meta-object protocol, pluggable syntax, macros, FFI, ...) so that another rewrite won't be necessary in the foreseeable future.
didn't Perl programmers start unofficially refering to subsequent versions of Perl 5.x as "Perl x", i.e. Perl 5.7 as "Perl 7" and the latest version as "Perl 20"
Not that I'm aware of, but I'm on the edge of that community.
So here's my take on it:
1. Syntax. And how it's almost impossible to change it after a certain level of language-adoption. Perl coders knew it needed to be radically changed, understood how that was impossible, and moved on.
2. As a result of 1: the shrinking community. It is a clear red flag, no-one wants to start a project in based on (soon to be) legacy technology.
3. The existence of very suitable languages for Perl-refugees. When Perl ruled the web it was pretty much the only open source, web-focussed, runtime-typed language with a package manager fully of goodies. But with Ruby, Python (, etc.) and their very active communities around, it became very easy to switch.
4. It missed academic backing. Having programmers "schooled" in a particular language seems to be important in this world. The winners in this area seem to be Java, C-Sharp, C++, C, Python and to some extend Haskell; Perl never managed to enter this league (and does not seem very fit).