Hacker News Reader

Comment by bachmeier | Hacker News Reader

There are so many stories from people that used Perl long ago but have since moved on to better languages. My story is the opposite. I tried Perl ages ago and couldn't understand why anyone would use it for anything. A couple years ago I decided to give it a try (it was the best fit for unimportant reasons). What I found was a solid language that was great for working with text, highly performant, a good replacement for Bash, and everything just worked so easily, including CPAN packages.

A few days ago, I returned to modify something I wrote last year. I was surprised at how easy it was to read and understand the code. The $ and @ that folks complain about are pretty handy tools to convey what the variable holds. Though I won't be moving most of my code to Perl, I think it's great for what it was originally intended to do.

View on HN

I have the opposite experience to you; I was required to use Perl ages ago and built enough software in it to actually like it. I understand why some people are big Perl lovers.

But of all the programming languages that I know (and it's a long list) Perl is the only one that I can't just jump back into. I've forgotten all the esoteric things about it. Unlike most languages, you can't get far in Perl without knowing those esoteric things.

> people that used Perl long ago but have since moved on to better languages

For tasks where Perl is a good fit I moved to Python, but cannot say that it is better (or worse). It is much more fashionable, which is an advantage on its own though - more people will be able to read code written in Python, there are more libraries which are actively maintained.

Many years ago I used Pascal and now work with software written in C. In my opinion Pascal is much better language than C, but Pascal is mostly the thing of the past and C is still very much alive. Sometimes we have to move to languages which are worse or at best - not much better.

Python has safer defaults. If you want lexical scoping, or errors when you make mistakes, you have to ask for it in Perl.

If perl had use strict; and -w (warnings enabled) by default so that you had to switch them off if you didn't want them I doubt python would have gained such traction as being "easier" and "more readable." The power of perl would have been better tempered by some responsibility.

I liked perl and kinda miss it sometimes but I guess I'm not too unhappy about moving to python. Python is fine. I am pleased to find out how wrong I was about significant whitespace. Having the shape of the code reflecting its content and meaning is actually a great thing. You can think, this shape looks (un)pleasant before understanding the code in detail. Better yet is never, ever having yet another goddamn argument in a team meeting about python bracing style. Python's success makes it impossible to argue that people won't accept a mandatory indenting policy as part of the semantics of the language anymore. It's an open choice for all future languages to adopt if they deem it worthwhile, not refuse to entertain because "the users will revolt."

With Perl's demise we still wait for the lisp of mass appeal for all perl as a lisp lacked uniform syntax.

Do you use 2 spaces or 4 or 8 to indent?

Leading tabs or spaces?

Yeah I get it, we'll do that about anything. And so I draw myself up my full height, hold up a hand, pause, then say "are you seriously trying to start an argument about python formatting? Seriously? Have you considered accounting as a career move?" And if you do it right it's not taken as malicious, gets a laugh and e move on to something else.

> If you want lexical scoping […], you have to ask for it in Perl.

That's false. Lexical scoping was added in 1994. One cannot ask for it, it's always "on".

> Python has safer defaults.

The parable of the mote and the beam is very opportune here. The Python defaults do not amount to much.

Python has neither strict variables (demo: https://stackoverflow.com/a/34071474) nor lexical scope (demo below). That makes it quite unsafe to program, similar to shell: a simple typo silently causes wrong results instead of being shown as error. The safe features cannot be simply enabled, the usual work-around is to use a programming language that implements these features and compiles down to Python.

----

Demo of lack of lexical scope:

    $ python3.8 -c 'for i in range(1,4):
        print(i)
    print(i)'
    1
    2
    3
    3

The variable leaks out.

Compare JS (run-time error):

    $ node15 -e '[1,2,3].forEach(i => console.log(i)); console.log(i)'
    1
    2
    3
    ReferenceError: i is not defined

Compare Perl (compile-time error):

    $ perl -Mv5.32 -E 'for my $i (1..3) { say $i; } say $i;'
    Global symbol "$i" requires explicit package name (did you forget to declare "my $i"?) at -e line 1.
    Execution of -e aborted due to compilation errors.

You’re right that Python only has function scope, not quite lexical scope. But

  perl -e '
    sub foo { $x = 42 }
    foo;
    print "\$x is $x\n";
  '

quietly creates a global variable. You have to ask for lexical scope, and you have to ask for strict mode to get that error (requiring 5.11 or better does that, but merely having 5.11 does not). Backward compatibility justifies this but devs need to beware this is how the language used to be.

I'm curious if you're trying to highlight the wisdom or dramatic aspect of the Perl initiative that's the subject of the OP.

----

If you're not intending to highlight either of these things, then I suspect you perhaps haven't understood the OP.

Perl has long had features that Perl folk consider better than Python's equivalents -- the issue you raise ('strict' lexical scoping) is an exemplar -- but Perl as it currently is has these features switched off (in the name of backwards compatibility).

The proposal in the OP is that Perl folk will consensually agree on which of 30 years worth of accumulated advances in Perl to switch on by default, and then newbies will automatically get that improved Perl by default.

Perl is great because it makes text processing and CLI tool development really stupid simple. The language was built for that sort of thing.

Perl suffers for the same reason. It's early prioritization of text manipulation makes it not great at general purpose programming.

> It's early prioritization of text manipulation makes it not great at general purpose programming.

Exactly, and that's where I went wrong the first time I looked at Perl. You can tell the language was designed by someone that knew a lot about text manipulation. That means it's really good at solving those problems. Unfortunately I wasn't using it for text manipulation at that time.

The sigils are very useful in a language which doesn't play well with IDEs. They're redundant for something like C# but Perl has always struggled with IDEs and is notoriously resistant to static analysis so even good ones will have gaps. I personally have never enjoyed using one with Perl.

It does get a bit messy with coercion like (%{$hash->{$key}}) but I believe recent versions have made that a little nicer. I'm stuck on a decade old one though.

Yep, in a newer perl you can say:

    $hash->{$key}->%*

to do the same thing. And you can replace the * with stuff to do slicing or whatever if you like.

> The $ and @ that folks complain about are pretty handy tools to convey what the variable holds.

It doesn't convey much. $scalar or @array, that's all. An array is always an array of scalars. Scalar can be almost anything: any kind of number, a string, a reference (often a reference to... an array or a hash, since you can't have arrays of arrays or array of hashes, only arrays of scalars).

> It doesn't convey much. $scalar or @array, that's all.

It's useful when you have a healthy mix of arrays and scalars scattered throughout your code. Static typing would be better, but $ and @ are better than tracking the information manually.

> It doesn't convey much. $scalar or @array, that's all.

You're vastly underinformed. It conveys the mode of access. It shows at one glance if the expression is singular or list or pairs.

                      … of an array   … of a hash
    the whole         @a              %h
    one particular    $a[0]           $h{foo}
    values slice      @a[5,3,7]       @h{qw(bar foo quux)}
    key/value pairs   %a[5,3,7]       %h{qw(bar foo quux)}

Reply on news.ycombinator.com