I think the article is a little bit harsh on Perl. Ruby (1995) and Python (1993) wouldn't probably exist without Perl (1987). Hence IMHO it's just a sort of evolution, nothing more. The other two languages learned from Perl's mistakes and were better designed.
Why Perl Didn't Win
101–110 of 157 posts
Re: Why Perl Didn't Win
#102In one of the WWDC sessions an Apple engineer was adamant one should never choose terseness over clarity, because every line of code is written once by one person, but read many times by many people. And funny enough Objective-C is taking this quite seriously, being a very verbose language (the new Swift language also keep the verbose method names, enums and properties). While Perl is exactly the opposite. There's a…
Most of the modern perl ecosystem is libraries built by substantial teams - it's a lot different now than a decade or so ago. The Modern Perl dialect is basically what came out of the new wave of CPAN (Enlightened Perl) movement which is all about using perl's flexibility in a way that scales to larger teams. Sadly, every attempt to explain this to people not already writing it results in a deluge of 'write-only' jok…
Perl's brand is damaged. No amount of explaining fixes a broken brand.
The best that can probably be done is to create a new language which is, say, a clean subset of Perl 6 and call it something new, focusing the message on how readable and intuitive it is.
Re: Why Perl Didn't Win
#103As a Perl and Modern/PBP fan, I have to suggest that CPAN has become a poorer resource over time: > In the olden days, you could expect to find a Perl module for most anything you wanted to do but also: Having 57 modules all called Sort will not make life easy for anyone (though having 23 called Sort::Quick is only marginally better and it seems that every time I look for a useful module on CPAN I find myself in a tw…
There are a few things to consider when trying to pick a good/the best module for a problem. - ask in irc.perl.org. it is very likely to get pointers from very experienced people. - use metacpan.org and pay attention to the votes/likes it got. and read the reviews. - each and every CPAN module is automatically tested. look at the stats to weed out problematic modules. - check out the release frequency and when the la…
I agree, but naive new Perl users might benefit from some prominent showcasing of well-known good modules or maybe comparison charts between modules in the same functional niche... Maybe that is a subject better left to Perl bloggers rather than to the neutral CPAN, but first contact with Perl is sometimes an embarrassment of riches.
Anyway, I love the CPAN - whatever I imagine myself wanting to do, five people have done it already !
Re: Why Perl Didn't Win
#104No language syntax causes me higher cognitive dissonance than perl. I just find it fugly.
Re: Why Perl Didn't Win
#105Earlier quoted context omitted.
I was recently asked to add some trivial code to the end of an existing unmaintained Perl script written long ago. Something along the lines of $x = `cat FOO 2>/dev/null`; if ($x == "foo") { system("BAR"); } When I tested it I found BAR was executed no matter what FOO contained without any errors or warnings. WTF? After a little more searching I found the problem was that I should have written $x = `cat FOO 2>/dev/nu…
I guess you've never written any bash either, wherein the exact same problem exists except that == and eq are the other way around, for reasons I can't quite remember. Plus, of course, if you'd enabled perl's warnings system, via 'use warnings;', it would have complained at the use of == on a non-numeric value. If you don't enable the compiler features that catch problems, then, yes, you can run into problems. Welcom…
Thanks for the 'use warnings;' suggestion.
Keep in mind the subject here is maintainence - where small changes with minimal impact to production is the rule and the work is often done by programmers with incomplete knowledge and no patience for explanations. For maintenance you want KISS, not TMTOWTDI.
I'm no big fan of bash but at least bash gets the common case right here without any special settings. For example, if I use -eq instead of == and write
#!/bin/bash
x=`cat FOO 2>/dev/null`
if [ $x -eq 'bar' ]; then
echo baz
fi
bash-3.2$ ./example.sh
./example.sh: line 3: [: bar: integer expression expectedRe: Why Perl Didn't Win
#106Maintenance. I say this as somebody who loves Perl, quirks and all (actually because of the quirks). It's actually a beautiful language to work in in the same way English is a beautiful language -- it's a beauty because it's a goddamn mess. But it's a rotten language to maintain. Sure, it's perfectly possible to write highly maintainable code (I have a few 30-40k line Perl projects that I can open up and get right to…
I don't want the popularity we once had. The same people who wrote unreadable, unmaintainable perl went on to do the same sort of damage in PHP, then python, then ruby/rails, and now node.js/go. They were never a net positive to the community, and I'm not sorry to see them causing problems for somebody else. (and before somebody says "but that doesn't happen in X" ... yes, it does, even python lets you write code tha…
> before somebody says "but that doesn't happen in X" ... yes, it does, even python lets you write code that looks superficially comprehensible but turns out to be so horribly illogical structurally that it's impossible to maintain
It does happen, but due to the design of Python / Ruby / Javascript, it's a lot harder to make happen especially when you use a framework.
As a former Perl dev, unless someone maintains god-like discipline over a Perl code-base; it's a lot easier to come up with unmaintainable spaghetti, that no one save for the original developer fully understands how it works, than it is in other competing languages.
Re: Why Perl Didn't Win
#107Earlier quoted context omitted.
No, not at all. Type coercion is orthogonal to type safety.
Amen, brother! I call this "weak typing". But some others use weak typing to mean different things (like "unsafe typing") [1]. Javascript, PHP and Perl are weakly typed. Smalltalk, Lisp, Python, Ruby... are strong typed. But all of them are dynamic. [1] http://en.wikipedia.org/wiki/Strong_and_weak_typing#Predicta...
I love dynamic languages with strong typing. You get most of the dev time developments, but without the inherent subtle bugs that creep in via automatic type coercion.
Re: Why Perl Didn't Win
#108Earlier quoted context omitted.
I was recently asked to add some trivial code to the end of an existing unmaintained Perl script written long ago. Something along the lines of $x = `cat FOO 2>/dev/null`; if ($x == "foo") { system("BAR"); } When I tested it I found BAR was executed no matter what FOO contained without any errors or warnings. WTF? After a little more searching I found the problem was that I should have written $x = `cat FOO 2>/dev/nu…
This sort of distinction exists in other languages though: Java has == and equals. OCaml has = and == etc. (Not that Perl doesn't have its issues; but this is very low in that list imho)
That is not what perl and bash do. They distinguish between "comparing as strings" and "comparing as numbers". For example, the strings "03" and "3" are different, but as numbers, they are equal (and, I guess "010" is equal to "8", numerically. I didn't try, because I don't want to know)
For bash, read http://unix.stackexchange.com/questions/16109/bash-double-eq... (especially http://unix.stackexchange.com/a/120235) and weep.
For perl, see for example http://www.perlmonks.org/?node_id=276023
Re: Why Perl Didn't Win
#109Earlier quoted context omitted.
But in those languages, the equivalent to ($x == "foo") will return false (almost) all of the time. The poster here says that this expression is true (almost) all of the time in Perl. Why?
Because if you disable warnings, it silently coerces 'foo' to 0. This is why disciplined (i.e. non-tiny-script-y) perl code starts off with use strict; use warnings; just like disciplined javascript starts off with /* use strict */ and disciplined C code enables compiler warnings, and truly disciplined C code makes those fatal, just like in perl you can do use warnings FATAL => 'all'; If you don't do that, then you g…
I've been writing perl for over ten years. I think I learned to stick "use strict; use warnings;" at the top of my scripts on day number 1. God only knows why so many other Perl programmers never learnt this.
Re: Why Perl Didn't Win
#110Earlier quoted context omitted.
> But it's a rotten language to maintain. I've been diving into some of our legacy Perl and man, the learning curve of the various sigils and implicit variables. Even working with collections was challenging. I'm working to make it better Perl (I have a copy of Modern Perl on my desk), but that's solely to make it understandable so that we can rewrite it / replace it with something like Salt.
If it's seriously legacy code ... then I'd completely support you rewriting it, and I'd rather see it rewritten as not-perl than left as bad perl, no matter how much I personally do like perl. This is why I'm glad we're not the 'most popular thing' anymore, these days the same quality of people are producing similarly awful code in node.js and go, and I feel sorry for those languages' communities because of it.
> If it's seriously legacy code ...
Well, I'm removing globally scoped maps shared across several modules and about 6000 lines of code. To be fair to the original author though, he was learning Perl as he went along, and when he learned about references he started using them in new code.