Ancient languages: Perl (2004)
sites.google.com
sites.google.com
As I've done for a great many other programming languages, I've bashed on Perl's technical weaknesses at length in the past. To my continued amazement, the Perl folks are the only ones who never get upset. They just say "Haha, yeah, boy, you're right, it sure is ugly. Heh. Yeah, so, um, anyway, I'm going to get back to work now..." It's awesome. I've gained so much respect for them. It's almost enough to make me go back to programming in Perl. Well, almost.
http://steve-yegge.blogspot.com/2006/10/egomania-itself.html
The Comprehensive Perl Archive Network (CPAN) currently has 123,757 Perl modules in 28,037 distributions, written by 10,829 authors, mirrored on 270 servers.
Back in 2004 (almost 10 years; there's been some developments since then) someone ran SLOCCount on all of CPAN, and it estimated the development cost at about $677 million dollars. http://web.archive.org/web/20041010230806/http://www.etla.or...
Before you choose another language for your project, ask yourself if it's not going to cost more to write everything you'll need, or if using pre-existing, time-tested code might do the trick for cheaper.
The one downside about Perl that I think is the most unfortunate is the ninja aspect. You have to be a Perl ninja to write good Perl code. There's no two ways about it. If you come from a different language, you have to ignore all the rules and guidelines you used to develop in, and learn the Perl way, or be ye damned. Which is why most Perl code you've been forced to maintain sucks.
I believe 99.9% of the people will find any libraries they need in pretty much any mainstream language. There is a point where quantity stops being a factor.
Some of us just want to get shit done and not rewrite the wheel (and debug it).
So there is a 'stability' aspect (which is not changing fundamental things). Perl 6 is having those issues, too much change and its threatening to hemorrhage a bunch of CPAN.
Having been present at the 'birth' of Java and watching the forces at work on it as a language and on it as an environment. I find the forces that change languages interesting. And the question about when to change the language versus when to fork it and make a new language much more complex than I expected.
It's a framework for writing reactive programs so you don't have to write all the glue normally associated with event-driven apps. It's got 1,044 framework-specific modules to take advantage of (in addition to making it easy to write them yourself).
There's a point where the wheel's already been made and trying to find a better one stops being a factor.
A lot of CPAN's libs are likely cruft from the language being so old, the size of it says nothing. What's more interesting is how often libraries are updated with new code, and how often people use them.
Want to see how old code stacks up in testing? Let's pick a module and see all its dependencies and their test results. XML::Feed as a random example: http://deps.cpantesters.org/?module=XML%3A%3AFeed&perl=lates...
Hmm, says no results for some of them. Let's drill down and select HTTP::Negotiate to see its test results. http://www.cpantesters.org/distro/H/HTTP-Negotiate.html
Looks like the latest version has been tested on lots of platforms, and it's good! Let's pick a different piece of code, something older, say from 2005? https://metacpan.org/release/DOMIZIO/CGI-Builder-CgiAppAPI-1... http://www.cpantesters.org/distro/C/CGI-Builder-CgiAppAPI.ht...
Ah! So we see the last version it worked with and on which platforms, but on the latest perl it's failed its tests. We can drill down and see why the tests failed: http://www.cpantesters.org/cpan/report/c91a8b7c-4983-11e1-94...
Hmm, unprefixed autoloaded parameter. That's probably not too difficult to fix. I guess even though there's old crufty code that isn't always maintained across versions, we have pretty good visibility into when something failed, and with good tests we know why and how to fix it.
There's a lot more resources to take advantage of through CPAN, like bug trackers, review sites, development wikis, etc. http://en.wikipedia.org/wiki/CPAN
A bad sign. This is usually the result of a single test hanging indefinitely, leading to the necessity of killing the entire automated testing process. As a consequence the test results don't get sent to cpantesters.org, putting the onus on the user to file a bug report.
Yes you're right that CPAN has older stuff in it compared to say rubygems.org. It also has, as a gross generalization, older programmers with IMHO more mature and thorough approach to how they package reusable code. This is a language adopted first by graybeard Unix sysadmins in the late 80s and early 90s, then by the first generation of "CGI" web programmers, then by what we'd call today "web developers."
So the fact that CPAN contains old code has tons of upsides because the CULTURE of CPAN was set by more seasoned programmers. The documentation, for example, is of generally much higher quality than in Ruby gems, typically involving a nice Synopsis with lots of pertinent examples, documentation of methods/functions that thoroughly lists params and expected output (imagine that!), and that actually discusses edge cases from time to time. There are usually tests that actually run; by default a CPAN install runs a test suite which must pass before proceeding.
Rubygems are great but unlike CPAN which began as a manual system where adding a module involved dealing with judgmental humans it's all automated, making an account takes a few seconds and there are no real standards. The culture is just different. This has benefits, like lower barrier to entry, but downsides too. I am continually appalled at the level of documentation in common gems. I guess people expect you to just look at the code, as "view source" options abound in online docs, but then you end up chasing a code path through many methods and classes just to figure out the basics. And there are often real issues with the code, too; while Ruby has plenty of users, they are disproportionately Rails devs who stay in that little ecosystem, so a general purpose Ruby module tends to have fewer eyes on it. Don't get me wrong there is lots of high quality amazing stuff in Rubygems and I'm grateful for it, but you can't spend much time on Rubygems and NOT end up seeing a general difference in standards vs CPAN.
Anyway my point is older != cruft and older != bad. Older often means "used by many people for many years, with many bugs removed and many useful features added." Here's one small example. Let's say you want to pull a query param out of an HTTP request. You don't know in advance if it is a GET or POST. In Perl the (c 1994) CGI module solves this trivially without you having to drill down into how the requ was made. In ruby there is no method-neutral way to do this, you have to reinvent the wheel, inspecting the req, sniffing method, and (if you're using any of the code suggestions on Stackoverflow) MANUALLY splitting out the params by decoding the query string and splitting on ampersand. No one has solved this problem with a Ruby module (probably because if you're using Rails, as everyone is, there's a helper for this task).
People call Perl a "read only language" but CPAN's "old" culture makes code re-use more easy than even in a more elegant language like Ruby.
For a long time, it seemed like everyone was using his form mail and web forum scripts.
It cured me of any inclination I might have had to actually learn and use Perl.
I wish I could recommend perl - CPAN modules generally really are amazingly high quality. But the mental cost of the perl programming model: no named params! arrayref vs array vs list! Contextual::Return! blessing scalars into objects! - that cost is just so friggin high that I can't imagine asking anyone to follow me there anymore.
But you get named parameters (and type checking of them!) for functions/methods through CPAN. And lots of other language extensions.
High flexibility in programming languages -- Perl isn't close to e.g. Lisp macros -- do have costs, of course. You need to use automatic tools, code reviews and coding standards. But you should do that anyway.
I really doubt the extra time/cognitive costs make for a noticeable extra burden, considering that you'll have to learn lots and lots of other stuff anyway.
Frankly, the notion that I need to download an external module in order to do something as basic as finding the largest element of a list seems just bizarre. The real problem here is that instead of having a small orthogonal core that everyone can learn and use, you have an incredibly complicated core that no one really understands that devolves lots of basic functionality to a giant network of modules.
I think the perl community works incredibly hard at writing lots of CPAN modules to try and correct for perl's defects. But 100,000 bandaids isn't something to be proud of.
Second: You don't have to use a module to find the largest element in a list. But you can if you want, and you may find the module does it better than you do. Also, List::Util has been shipped with core perl since 5.8.0, so you don't have to download it.
Third: Perl does have a small core that everyone can learn and use. The fact that you don't understand it or what modules are for does not discredit it.
Have you actually ever looked at Python? The core language is pretty small; much smaller than perl certainly. My point is that if you design the core well enough with orthogonal components and capabilities, you can give people the equivalent of many thousands of purpose-built modules.
I have no idea what you're trying to say with your fruit analogy.
Perl does have a small core that everyone can learn and use.
That hasn't been my experience; the core language seems to have a staggering number of rarely used quite odd features that accumulated early on. It seems extremely hard to write a new implementation of perl that supports all that cruft; one can't even parse perl correctly except by using the existing implementation.
Thus my fruit analogy: Python and Perl are different kinds of fruit. They are designed differently and you use them differently. This is not a flaw. It is a feature. Arguing about how it should have been done X way is pointless.
As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet).
I don't think either of these statements is true.
This is not a flaw. It is a feature. Arguing about how it should have been done X way is pointless.
I disagree. This is not about subjective aesthetics. There are some fruits that are poisonous and are thus objectively bad, totally apart from the question of what fruit you think tastes best. Some of perl's language design features are objectively bad. For example, the way references are implemented makes it absurdly difficult to reason about simple things like nested sequences. If that complexity was needed to get some positive benefit like outstanding performance, then maybe it would be justified. But there are no significant benefits. They are the way they are because Larry Wall didn't understand anything about programming languages when he made perl.
As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet).
With respect, every language I'm familiar with can be easily parsed except for perl. This has nothing to do with Turing Completeness or the Halting Problem. This has to do with having a sufficiently well designed syntax that tools can easily parse files written in the language without having to implement the whole damn language. That's an important property to have every language besides perl nails it because it is easy to do, but perl doesn't because Larry Wall didn't know anything about programming language design when he started.
Yet you have lots and lots of really flaming opinions about something you obviously haven't used enough to understand the tradeoffs -- everything has good and bad sides.
So, a counter question at your level:
Why do we get so many stinking language war trolls out of your Python environment? Something must be seriously sick when an open source environment generates that type of sick behavior in its members?
Now, I don't care about your personal problems -- but you trolls lower the HN quality. You all write the same flames about things you don't want to know. Just don't use it.
(Afaik, Perl is executable directly when loading in a pre-phase -- which might change the execution environment for other code when it is compiled. this is another tradeoff, where Perl is squarely on the side of expressibility. A feature with plus and minus effects (like making syntax extensions easier) -- except for stinking language war trolls, where everything except their model is bad...)
Edit: As I noted in another place -- yeah references suck. Now, can you discuss list comprehension as an extra kludge people have to learn just because Python lacks multi-instruction lambdas?
I've written production perl code; no doubt with less skill than many posting here, but my comments are based on experience with the language.
Moreover, I've avoided making personal attacks on anyone. That's something you might like to try. If you can.
Perl is executable directly when loading in a pre-phase
So, perl's design makes it impossible to process perl code from other languages or even with perl sans execution. OK, that's a problem...and what benefits do we get from that decision? Do we get lightning fast performance specifically from that design decision? No. Do we get more expressivity? I don't see any extra expressivity that stems from that decision; I mean, Common Lisp's load-time/compile-time eval-when constructs seem more powerful than perl's counterparts but it doesn't have this problem. I have no problem with language designers making decision decisions that I don't really care for. But some decisions that involve extra complexity for no benefit are just...wrong.
I don't like C++'s template system, but I can see what problems it is intended to solve and I can see some benefits from it. What benefits accrue from making perl impossible to parse without execution?
yeah references suck
But that's not the problem! Lots of language features suck...the question is why does perl have references that are so hard to understand? Is there any reason besides 'Larry Wall didn't know anything about programming language design when he wrote perl and eternal backwards compatability mean we can never change this'?
can you discuss list comprehension as an extra kludge people have to learn just because Python lacks multi-instruction lambdas?
Err, I don't think you understand the issue here. The problem with python lambdas is that they can only contain expressions and not statements, so you can say lambda x: x+1 but you can't incorporate a try/finally statement into a lambda. That's a language wart, no question. But that has nothing to do with list comprehensions. Comprehensions limit you to expressions and not statements just like lambdas.
With respect, I don't think you know what you're talking about here. I'm happy to discuss language design warts, including Python's, but I'd prefer to do so with people who, you know, know something about the subject.
>>Moreover, I've avoided making personal attacks on anyone.
I argued you wrote extreme flames about subjects you showed you didn't understand -- then claim to understand them. I call yet-another-Python-troll.
>>I don't think you understand the issue here.
You missed(?) my point: With real inline lambdas and map, you don't need to create/teach list comprehensions Python style. It is there from inflexibility ("no braces!")
So, everything has warts(/tradeoffs), you flame about some that you obviously don't understand:
>> what benefits do we get from that decision?
You really see no possible benefit -- except in Common Lisp? -- from being able to modify the execution environment in code before running a program?
2. I gave the example -- to help with language extensions. No need for that in any environment...?
Ah, I see you're still struggling with the 'no personal attacks' suggestion. It is OK; I understand that this may be beyond your capabilities.
With real inline lambdas and map, you don't need to create/teach list comprehensions Python style.
map allows you to iterate over nested loops? I don't think so. I don't think list/set/dict comprehensions impose a major cognitive load on programmers, but perhaps you find them difficult?
Well, you really see no possible benefit -- except for in Common Lisp? -- from being able to modify the execution environment in code before running a program?
You misunderstand. Common Lisp offers more expressivity when it comes to changing the load-time/compile-time environment than perl does. But CL is easily parseable by external tools. This isn't a hard problem to solve. CL did it over 3 decades ago.
like making syntax extensions easier
But that doesn't make any sense: you can have syntax extensions in your language without impeding external parsing; that's...really easy. So that can't be the answer.
Then again, I'm not sure I've ever seen a real need to arbitrary syntax redefinition...does anyone actually use that feature?
>>Ah, I see you're still struggling with the 'no personal attacks' suggestion. It is OK; I understand that this may be beyond your capabilities.
>>I don't think [...] impose a major cognitive load on programmers, but perhaps you find them difficult?
Thanks for a good laugh, troll.
>>Common Lisp offers more expressivity
You are arguing that the specific Common Lisp way is a better implementation of different execution phases.
Not relevant, as you know.
I argued that the Perl way had advantages, not that it was better than everything else (see chromatic in gp level too). This contradicts your original position that the compilation phases were just crazy and uniquely bad.
So this is another point where you are shown to be trolling.
Since you made two personal attacks, let me note that... ah, no. I should just pity you irritating trolls.
I think I'll stop feeding you now. Please stop trolling on HN.
No, it doesn't. Anyone who told you so was fibbing. Perl's design allows you to add your own keywords to the language in such a way that the parser knows their arity and any contextual coercions--in other words, as if they were operators defined in the parser itself. This is rare (it doesn't happen often) and it's almost never ambiguous, but because the language used to define these custom keywords is Turing complete, it's possible to create pathological cases which depend on random factors to define a keyword in one of multiple ways...
... but no one ever does that except to prove that it's possible.
Most Turing-complete languages can be parsed (even Ruby, which is, among currently-popular languages that aren't Perl, noted for being parsing-unfriendly.) Perl can't be parsed not just because it is Turing-complete, but because (unlike most other languages), parsing Perl requires simulating its execution and it is Turing-complete, which combined require solving the halting problem to parse perl.
Insofar as it is valuable to be able to parse code written in a programming language, perl's unique barrier to parsing is a drawback.
We could remove the ability for Perl to compile, interpret and execute code at run-time, which would mainly involve removing eval, use, require, import, do, etc. But would that be better or worse than not being able to "parse" Perl code?
(As an aside: Ruby is also subject to the halting problem, and thus cannot be parsed; you just can't get away from the pesky thing!)
Except that "program" is usually used instead of function, that's the usual statement of the halting problem, not something it "comes down to".
> A simple while ( time ) { 1 } will stop us from finding that out very nicely, so the fact that it's not parseable is actually a separate issue.
The problem with parsing Perl is that Perl cannot be parsed independently of simulating its execution. That fact, combined with the halting problem, means that it cannot be parsed (or, more accurately, that any program that correctly parses Perl cannot be guaranteed to terminate on all valid inputs.)
> As an aside: Ruby is also subject to the halting problem, and thus cannot be parsed
All Turing-complete programming languages are subject to the halting problem. But that's not a problem for parsing most of them (including Ruby) the way it is for Perl because parsing most languages does not require simulating the execution of the code being parsed.
Ruby can be parsed, though its parser is notoriously ugly. [1]
[1] see, e.g., http://programmingisterrible.com/post/42432568185/how-to-par...
It should seem bizarre, because no one ever argues that.
I think the perl community works incredibly hard at writing lots of CPAN modules to try and correct for perl's defects.
The module of greatest use to me today allows me to iterate through cells in a spreadsheet. Is it really a defect in a language that something like Spreadsheet::Parse Excel or Apache POI exists?
First: Larry is insane. This means more to me than anything in the language itself. I prefer my heroes to have a firm grasp on sanity. I was never a fan of Don Quixote. Larry says God talks to him, and tells him that He hates non-Perl programmers. Larry is a fruit cake, a nut job, crazy as a loon, batty as a belfry.
Also, this is an old, old rant. It must have been posted multiple times with other URLs.
OK, so he says stuff about his religious views. Not my cup of tea either but he doesn't come off as a jerk about it. And it's fair, IMO, for someone to say their religious views influence their work. That is up to them, their personal opinion. Just because I am not religious myself doesn't mean I have to trash him about it. (Hint: When he says he hears from God, I don't think that's literal.)
I'm wondering if both you and Yegge are misrecognizing some of his sarcasm? (I guess Yegge is probably also exaggerating the personal aspect for comedic effect.)
As cdoxsey says, this as uncharitable, however it's not without a grain of truth. He's a bit of a loon, but a lovable loon.
That being said, what he helped add to the technology ecosystem is as important as GNU/Linux. Perl is remarkably expressive, and I've found in my 18 year IT career that no other single tool has paid me back as much for investing my energy into learning it, both in better "kung fu" (than you Ringo Langly), and also in plain old cash-money.
It's worth adding to your bag of tricks, even if you feel, as the article's author does, that the docs are unwieldy, the community is filled with zealots and cults of personality (to Larry himself, as well as to Merlyn and his ilk), and the syntax is irritating. It's still worth your time. If you invest enough in it to grok the language, you __WILL__ be a better overall developer.
... and unfortunately context sensitivity of operators became much more prevalent in Perl 6 than Perl 5. It was hard to imagine the core Perl maintainers thought that context sensitivity was a feature that needed further enhancement, but that's just what they did in Perl 6.
Programming language design comes down to one word: teamwork. Software is collaborative writing. The better languages allow teams of developers with mixed levels of skill to work together and be productive, to build on each other's code.
Perl 5 had enough quirks and cute context idioms to be clever and interesting, yet it was still possible to decipher what other coders had intended and learn a few new tricks along the way. Perl 6 is a toolkit for outright hostile obfuscation making it damn near impossible for a team of developers to wrap their heads around each others' code. Not surprisingly Perl is fading into the past.
I don't know enough about Perl 6 to comment on your opinions of it. I do find it really funny when you condemn a language (Perl) based on a very different language (Perl 6).
I guess you dislike C because C++ is overly complex, too...?
Edit: saraid216, I don't know if you troll or have no clue? Google. Most every source you'll find emphasize that Perl/Perl 6 should be seen as different languages.
Since when does a version increment make it a "very different language"?
How is it comparable between C and C++?
If anything, it's disliking C89 because of C90.
What makes you think so? So far I was convinced of the exact opposite.
Examples:
* Perl 5 has the same operator for bitwise string AND and for bitwise integer AND. Perl 6 has separate operators, reducing context sensitivity.
* Perl 5's reverse() operator reverses lists in list context, and strings in scalar context. Perl 6 has separate verbs for these operations (reverse and flip), thus reducing context sensitivity
* In Perl 5, context flows inwards, so operator can actually be context sensitive in the classical sense. In Perl 6, operators know nothing about their caller, thus they cannot be context sensitive in the same crazy way that some Perl 5 operators are.
As to its decrease in popularity, I'll point to two factors: (1) the rise of PHP, which took over most of the daily web-based tasks that Perl uses and (2) the rise of frameworks, which meant that people writing web sites were using newer languages so they didn't have to re-roll the basic stuff with each project. Perl didn't compete in that area until much later.
As far as its daily use, I still see it all the time and like many programmers, I implement new Perl code frequently. The flexibility across operating systems is a nice bonus.
For anyone who wants to see Perl written with grace and foresight, try these resources:
I also rather enjoy the excellent career in the bay area that Perl has facilitated.
As I was preparing to leave my last job, I learned Python and Ruby. (I even uploaded a gem for the latter.) I like both of those languages, and I've been toying with them for many years, but my day job has always been Perl.
It didn't seem likely that my next day job would be Perl, at least based on what I keep 'hearing'.
Strangely enough, the perfect position for me turned out to be a bike ride from home. And in Perl.
And I am quite fine with that.
Kevin Kelleher suggested an interesting way to compare programming languages: to describe each in terms of the problem it fixes. The surprising thing is how many, and how well, languages can be described this way.
[...]
Perl: Shell scripts/awk/sed are not enough like programming languages.
Python: Perl is a kludge.
Ruby: Perl is a kludge, and Lisp syntax is scary.
Awk is a lovely little programming language... (rather lovelier than Perl if you ask me, though obviously less industrial-strength)
I don't know that anyone necessarily believes you couldn't program with awk in an absolute sense, but it doesn't read like a glorified shell script in the way that perl is explicitly designed to.
Remember, this was 1987—25 years ago, before bash and other modern shells, and with much more primitive versions of awk and sed. Nor was the web available to look things up.
Writing shell/awk/sed scripts back then was awful, no matter how much the Bell Labs folks touted its superiority.
When perl showed up on comp.sources.unix it was an incredible breath of fresh air. I downloaded and built perl based on its claim to replace shell script/awk/sed programming and Larry Wall's reputation as the author of rn [1], my preferred newsreader for usenet. Perl lived up to its billing and was an enormous improvement for writing scripts.
Perl certainly offered new functionality, but it felt palpably kludgier than awk. The idea that it was some sort of giant advance over awk was rather overplayed, especially within awk's domain, where awk's cleaner language design and more focused features were real advantages over perl. [When perl first showed up, I remember thinking how churlish its "a2p" script was... who'd want to switch to perl, given a working awk program?!]
Wait, when did this happen?
Yes, meanwhile people using Perl succesfully should care, because?
1) He hates Larry, therefore we should all hate Larry's language.
2) He looked in the official detailed technical docs when he was looking for a "learning..." book or a "... for dummies" book. By analogy he was looking for dietel and dietel but when he picked up stroustrop his eyes started burning.
3) He hates the idea that references exist and some people like them and use them. Although you don't have to use them, at all. Also if you insist on implementing your own object oriented design the slow hard way by hand using references instead of "use Moose;" like a normal person, its hard and slow just the way you asked for it, instead of being made impossible.
4) He doesn't like the large number of features. He especially dislikes the single/double character magic variables. Some of them take as much as 30 seconds with google to learn and use!
5) Strange rant about lego as a programming language analogy, which boils down to much like lego, languages should have just a handful of fully understood small pieces that hurt your feet when stepped on barefooted; You must fully understand all (few) language features before programming. I think he's calling for the return of Basic Assembly Language on a S/360 mainframe, or perhaps a more RISC alternative like enterprise grade 6502 machine code.
Its a weird essay. I think its a parody of the recent spat of perl-hate.
If you are a perl programmer, you have to know and use references(pass hash, pass array with other params, nested data structures...). "you don't have to use them" is true in the sense that you don't have to use anything - you don't have to use lists, hashes, OOP, what have you. The same goes for OOP. Moose is an option for new code, not for code which has been written with blessed references.
I don't have anything against references; I do have something against using references and de-references for nested data structures and passing data structures to functions. Yes, I do understand references, but I will take the way Python and Ruby make do without references over Perl's references any day.
Thanks for pointing that out, it is an unfair article because the whole premise of the parody was if the author was running a blue sky startup... so legacy code sucks is not much of an argument.
Some time ago I reflexively converted everything perl OO that I touched to "modern" Moose and it seems to have been worth it. Detection of non-Moose OO should be a Perl::Critic complaint. You can always add something to the exclude= line in a perlcritic.rc file. We've already got Perl::Critic::Tics and ::Lax and a bunch others, so ::FanOfMoose to complain about non-Moose OO is within the realm of possibility.
Rather, he's arguing for a modern Lisp.
I've never stepped on parens while barefoot, though, so I can't speak to whether it'd hurt as much as lego.
Not a particularly enlightening - or for that matter, accurate or representative - opinion piece.
Here he talks a bit about the perl community