Hacker News new | ask | show | jobs
by petesergeant 1316 days ago
Comments are hilarious, especially knowing some of those people commenting most critically had recently been working at FM&T.

At the short stint I did at the Beeb I spent a lot of time doing code for date maths using SSI and Perl before they decided to completely rewrite what we were doing in Flash.

Perl is a great language, and Catalyst and Mojolicious are rock solid, as is DBIx::Class. I work all day with TypeScript now, but I miss working with Perl.

6 comments

> Perl is a great language

I don't write Perl often, which probably explains why every time I go back to it (we have a legacy Perl app), I get tripped up, over and over again, by the sigils, and the rest of the visual noise — and I can't help wondering, why?. Why can other scripting languages deal perfectly fine with the ambiguity that Perl resolves with a dollar sign as opposed to a percent sign, or an at-sign, or a backslash. Why do I, as a programmer need to remember that when I assign a hash as a value to another hash, I want to write it with curly braces; whereas in other contexts I want to write the hash using parentheses and assign it to a variable prefixed by the percent sign? Why do I then need to prefix the variable with "my" or "our" at the time of declaration? Why don't I have to do this in other scripting languages, not even in php, which has preserved the dollar sign? It's utterly bizarre.

Don't forget there's also "state $var" and "local $var", which declare other types of variables. They're there because they.. are useful.

Same as why there's "var", "let" or "const" in JS. Different scoping / types of variable slots for the interpreter.

A "my" variable declares a variable valid in the current scope; an "our" variable will be available at the package level; a "state" variable is initialised only once, but has the same scope as a "my" variable; a "local" variable "locally overrides" for the current block (and any code called by the current block) the value of said variable.

They all have their uses, and that's why they exist.

`let` and `const` expand and replace `var`; and make variable declarations more intuitive by removing var's hoisting and adding block-level scoping (which the programmer doesn't need to care about if he doesn't wish to). What this means is that one can just use var if they are happy with it, or use let and const without the var. Not so with Perl. There is no "legacy mode", with all the awkward punctuation of decades ago, as opposed to a much saner "convenient modern mode" in Perl.

(Although I agree that a javascript programmer might get confused by declaring an object or an array as a const and then being allowed to mutate it.)

I'm not defending the sigils because they are terrible, but the reason you can't just get rid of them is that they are actually used.

For instance:

my @arr = ("Larry", "Moe", "Curly");

my $len = @arr;

will store 3 in $len. Application codebases and libraries make use of this kind of thing everywhere.

You can find some of the reasoning why in interesting essays like this: http://www.wall.org/~larry/natural.html

Larry Wall was trying to incorporate some natural language features in Perl, unsuccessfully in this case but I would say it went very well in others.

> ..every time I go back to it I get tripped up, over and over again, by the sigils, and the rest of the visual noise

From what I remember of writing Perl - it is a lovely language to write, but not to read. I remember going back to my own code and thinking what the hell am I doing here.

The sigil is there because Perl is made for text templating, like bash and PHP. Similar to f-strings in Python 3. Having several sigils is because Perl has language context as first order feature. It is a form of operator overloading.

I have the opposite reaction than the one you describe. Why haven't other languages picked up on contexts?

It's an elegant to solution to the fact that casts can be ambiguous in late-bound dynamically typed languages. PHP specifically can suffer from this where the automatic casting gives you a different type than you expected and no one notices because it isn't an error with dynamic types. It eliminates a class of errors.

The other things I miss most from Perl are taint mode, and Moose. Metadata for objects is such a good idea, where you can see all the traits and other properties in one place.

What I don't miss about Perl is that complex data structures are overly verbose. Multidimensional arrays and hashes are much too hard to read. Ruby did that much better.

> Why [does Perl use a lot of weird punctuation]

Because that’s how it started, and it maintains absolutely fantastic backwards compatibility. All languages have foibles…

> Why do I need to [declare variables prior to use]

Because this isn’t Python

> Why do I need to [declare variables prior to use]

Given the zen of python specifically says "explicit is better than implicit" I've always been stunned that python doesn't require that.

I've spent enough years writing perl that, believe me, I can hate its foibles more extensively and more accurately than most of the anti-perl people, and generally when I read criticisms of perl my first thought is "this wasn't wrong but it doesn't go nearly far enough."

But not requiring something like 'my' is python abdicating its own stated principles and while I don't feel I know python well enough to criticise it appropriately in general, this has always struck me as, in fact, a deeply un-pythonic attribute of the language.

>> Why do I need to [declare variables prior to use]

You don't need to if you don't use strict mode, which I think it is ok for small scripts.

>fantastic backwards compatibility

Yeah, Perl 6 was so <s>fantastically compatible</s> it took so many decades to come out they had to rename it something else so as not to confuse people.

>Because this isn’t Python

Perl 6 isn't Perl, either.

It's not called Perl 6 anymore for exactly this reason.
Most of us never considered Raku, even before the rename, to be Perl.

A perl in the sense that, say, Common Lisp, Scheme and Clojure all count as a lisp.

But no further.

Sigils are used for shell scripts and awk, and Perl is descended from both.

They are a useful visual indicator that something is a variable, so they don't bother me.

Newer versions of Perl add post-dereference syntax which reduces the line noise.

just re-read this comment you wrote, where you list out all of the rules that you forget, and you'll be on easy street
Just in case you missed it, Mojolicious is also available for TypeScript now, and the developer experience is pretty close to the Perl original. ;) https://mojojs.org
Ah yes, great work! I've submitted it as its own story: https://news.ycombinator.com/item?id=33656829
Having released SQL::Abstract 2 people are trying to convince me to port things.

Since the SQLA2 expr layer was deliberately designed to be JSONable I have a horrible feeling I can actually do so and I might actually crack and do it, but if I do I'll be writing vanilla ES6. If you love typescript enough more, a commit bit will be yours for the asking.

If you write it in vanilla ES6, I can probably type it for you.
I wrote mostly Perl for nearly ten years of my career and I miss it. It was so easy to transition between writing big codebases and doing little command line stuff. The super power was how easy it was to write little command line stuff that could quickly include all the enterprise libraries.
I feel the same about PHP. It's easy to scale up, and can scale down to small CLI scripts (but can include any utility libraries you need as well).
I really can't stand PHP but as a veteran perl hacker I really do need to say "that's my personal opinion and I am -amazingly- impressed with what people have -done- with PHP even if I don't like it myself."
Mojolicious::lite is amazing; I'm using it on a personal project at the moment.

I love Perl, it's exactly what I need in a programming language. I picked it up this year as I wanted a versatile and fast scripting language in my toolkit.

Every time I try to write Perl, between the sigils, weak support for numbers, and the archaic-feeling way of handling parameters in subroutines, I come away slightly disgusted. The convenience of the text processing routines is not a novelty or productivity improvement compared to other languages nowadays. And Perl seems slower than Python now on the kinds of workloads where I would be tempted to use Perl. What am I missing?
In the latest Perl5 you can define signatures like normal people[1], but it has been available as an experimental feature since 5.20[2].

[1] https://perldoc.perl.org/perlsub#Signatures

[2] https://www.effectiveperlprogramming.com/2015/04/use-v5-20-s...

That's a huge quality of life improvement, and I didn't realize it's been around for so long! I will have to give this a try.
>And Perl seems slower than Python now

Do you have some examples? Outside of some specific python extensions that are written in C, Perl is almost always faster than Python for me.

I don't have good ones offhand, but whenever I write a script that spends a long time looping and doing a mix of numerical calculations and text processing, CPython beats Perl. I think this is partly due to how Perl treats numbers as a kind of second class data type.

However Perl handily beats CPython in startup time, so it's much faster for short-lived programs.

> Is 'Ruby on Rail' the monorail version? :P

Haha