Hacker News Reader

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/null`;
  if ($x eq "foo") {
      system("BAR");
  }

I have absolutely no patience for this kind of crap, but I don't have time to replace the whole thing right now so I just suck it up and move on. I can understand how Perl may never die completely but I'm never going to use it for anything new.

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)

Ahd in Common Lisp, EQ, EQL, EQUAL, and EQUALP. See http://www.nhplace.com/kent/PS/EQUAL.html for an explanation of why.

Mistakes from other languages are still mistakes.

One could try to call them tradeoffs rather than mistakes, but then you'd have to explain why the programmer benefits from such circuitous thinking.

I don't think that one is a mistake. At least, if it's a mistake, it's not a mistake in the equals operator. PHP attempted to use one set of comparison operators and the fallout has been far worse: there have been security problems due to the semantics of PHP's == operator attempting to guess whether to perform string or numeric comparison when doing password comparisons.

The mistake, if any, is that numbers and strings are unified into one scalar type in Perl. This allows some tricks, such as being able to use sprintf to perform rounding, but it has fallout in other places in the language, such as here. Given that numbers and strings are unified, having two operators for comparison is the correct decision: it makes the semantics much simpler by having the language not guess which kind of comparison to perform.

They're not mistakes; read the article. "Equality" is not the singular, unambiguous concept that many programmers think it is.

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?

But what is $x? Integer? String? Character? Some_Object?

How do you evaluate this, depends on the context. Wasn't that the whole point of a dynamic language anyway?

After learning Haskell, I'm not sure what the benefits of dynamic typing are anymore.

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.

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 get the short script/one liner style behaviour where, just like sed, awk or bash, it assumes you know what you're doing. If you don't, then you should be asking the VM to help tell you when those problems exist, same as 'set -x' in bash is incredibly useful if you don't plan to add '|| exit 255;' onto the end of every command.

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.

Those languages are far more maintainable and their communities have far more respect for practices which prevent programming errors.

I don't particularly care how many forms of equality or comparison a language has as long as the compiler or runtime is capable of telling me the particular one I'm using is probably wrong. If == can't be used with strings the damn interpreter should tell me so instead of silently and improperly coercing the arguments.

You should have used strict and warnings. RTFM, I know.

Btw, Java will silently compare references instead of value. Learning a language != increasing vocabulary.

Tell me about it. At least Python can make the difference between equality and identity, while a non-overriden equals() in Java actually means "is X Y?" instead of "is X equal to Y?".

The interpreter does tell you.

    $ perl -e 'use warnings; use strict; print "content" == "foo", "\n"'
    Argument "foo" isn't numeric in numeric eq (==) at -e line 1.
    Argument "content" isn't numeric in numeric eq (==) at -e line 1.
    1

Thanks - I'll try to remember that if I ever have to touch perl again.

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

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. Welcome to programming.

Edited to add: I got downvoted within five minutes. If you disagree that my bash analogy is inaccurate, I'd love to hear why.

I did not downvote you, but comparing a language to Bash is certainly in no way flattering, and I would definitely not put it in the "good defense analogy" category.

Comparing a final conditional in a systems-style script that is then calling another program, shell-style, to bash, which is the most common language where you'd execute a conditional then call another program, seems reasonable.

Maybe not flattering, maybe not a good defense, but I think under the circumstances an acceptable comparison.

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

as you imply, bash won't be silent. It will say

  bash-3.2$ ./example.sh 
  ./example.sh: line 3: [: bar: integer expression expected

Equally, bash requires 'set -x' to not ignore errors.

In both cases, the reasoning is significantly to do with backcompat, I believe.

So, yeah, things that have been around a long time often require a setting to be safe in cases that we, ten or twenty or whatever years on, consider common.

Also: I did keep that in mind. That's why I started off suggesting using warnings, rather than (as I normally do for new code) making them fatal :)

Sane defaults are a cornerstone of good language and framework design because for better or worse people don't read the manual before they start using something. If a compiler doesn't do the right thing by default (throwing errors on problems a new user is likely to cause), it's a bad compiler.

What sane defaults are will change over the years.

Perl kept amazing backwards compatibility by adding extra statements to modify how it worked. So "use strict;", "use warnings;" and "use <other_newer_perl_features>;".

Both new code -- using the best OO system of the scripting languages, extendable syntax, etc, etc -- will run at the same time as most of the old and crufty stuff from before testing took over after the Millennium.

Lines that can affect the global behavior of the program are a mixed blessing.

It would have been bad, if the design had been stupid enough to not make declarations file/package based... :-)

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 that looks superficially comprehensible but turns out to be so horribly illogical structurally that it's impossible to maintain - I quite like python but I've been there and I was kinda scared because at least wrong perl looks wrong to start with, whereas wrong python looks fine until you realise just how much of a crawling horror it is)

> 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.

I was thinking the same thing. Didn't say anything because I didn't want to be rude to the "lets cut and paste code from google searches" coders...

If someone really wants to use a language, there is no excuse for not reading a book for that language first.

And when it comes to a "book for that language", Programming Perl really does take the cake.

With python is not the same. Even if the developers is truly bad and do a mess, is a decipherable mess. Requiere truly talent to do a hard-to-understand mess in python, and in that case, is very likely the code was made by a good developer ;)

> Requiere truly talent to do a hard-to-understand mess in python, and in that case, is very likely the code was made by a good developer ;)

Last I checked, the whole "if it was hard for me to write, it should be hard for others to understand" was still a mockery, not a seriously-interpreted excuse. It ignores the fact that the programmer's future self will eventually need to maintain that code. The developer might have skill, but one who writes unmaintainable messes as anything other than a Perl-golf-style mental exercise probably lacks wisdom. :)

Could provide a example on python of non-intentional bad code, like the kind that could be write by a perl coder, that make them not understand it a week later?

Because that is the issue I was talking about is rare in python. Is true that is possible to write bad in any language, but certainly is harder in some of them

> 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.

If you don't enjoy Perl code that looks like a cartoonish string of censored profanities, you could always try including 'use English' in your program, which aliases more descriptive names to all those punctuation-mark special variables. See here: http://perldoc.perl.org/English.html

""non-standard" bits of the language start leaking into your code"

I work on a small team (C++), so this has never been an issue. If you break coding guidelines someone will notice and let you know.

But this really should be integrated into work-flows. (ie/ into Gitlab, Jira, etc.) There should be some kind of step - before you are allowed to merge code - that checks that you are withing coding guidelines.

Yes, those are called linters: http://en.wikipedia.org/wiki/Lint_%28software%29

Thank you very much for showing me this. I'll definitely look into it.

Learning something new every day =)