Hacker News Reader

At one point, I didn't know Perl and had to work on a project with it.

For a while I was cursing the arcane syntax such as $_, $\ and even $ on a variable to the left of the equal sign...

and then something weird happened. Those things became idioms in my mind and I started achieving a sort of fluency.

And when I started to think in perl, I found it to be the highest-level language I had EVER worked in. I could express myself because there were multiple ways to do something and one always matched what I was thinking.

For example, instead of having to think IF NOT SOMETHING I could UNLESS SOMETHING and then express it as

  unless(something) { do_something(); }

or even:

  do_something() unless something;

Now I like the idea of regular expressions, but I find the implementation leaves a lot to be desired. or should I say implementations plural.

To me, the main usability problem with regular expressions boils down this: it is hard to distinguish between a literal and a regex control character.

This is exacerbated because regex control characters are usually the same characters other languages treat specially as well.

So you have regular expressions - which are somewhat straightforward, but you have to escape them for the place you are USING the regular expression - perl, shell script, sed, awk, grep or egrep, etc.

So I've used regular expression for decades, and even now it's always subject to a little trial and error and requires testing.

100% agree. Perl is highly underrated in today's software development climate.

note: I did switch to python. Even though it's less expressive I found the regularity works out better for me in the long run.

I didn't. I don't write Perl anymore either, though.

When Python started gaining traction, I was so incredibly turned off by the fans of the language that I swore I would never write code in it. That was 1998. If Python was 10% as good as those people were claiming, it would be humankind's greatest achievement for the next 1000 years, and it isn't.

Please note that I'm not saying anything bad about Python here, only its advocates in the late 1990s. I still have a bad taste in my mouth because of those conversations, over 20 years later.

I can understand that, even just a few toxic personalities can poison a community, or even perception of it. To be fair though, there were a lot of Python haters flipping the table over significant white space back then as well.

I suspect it's not just you - look at Guido! :)

I can't recall when I started using python, but it was probably 2010 or so, when it was more mature.

That said the 2.x -> 3.x migration was anything but mature.

There was a perl vs python religious war back then that generated a lot of online vitriol. Which made some sense since they were competing for mindshare in the same space. Obviously Python won that war, but it's interesting to think how things would have worked out differentlywithout the self-destructive tragedy that was Perl 6.

That tragedy meanwhile has been renamed to Raku (https://raku.org using the #rakulang tag on social media) and is doing very well. Meanwhile, it appears at least some form of tragedy is continuing with the Perl 7 efforts. :-(

Yep, this. I find it sad even after all these years... I put it down to 2 things - 1) the Perl 6 promise, and 2) Google, who were the new hot startup in Silicon Valley, chose Python...

Anyway... if you’re interested in Perl, especially how to write nice Perl, I encourage you to get yourself a copy of Perl Best Practice by Damian Conway for Christmas

FWIW, the Perl 6 promise was delivered in 2015. Because too many people did not want Perl 6 to be the future or Perl, it was renamed to Raku (https://raku.org using the #rakulang tag on social media). Meanwhile, Perl 7 appears to be the next promise.

Sure, but I’m talking the era around 2005, when CPAN was way ahead of everyone

Interesting side note here the Tiobe Index, which I know isn't the most accurate measurement of language use and popularity, currently has Perl ranked at 14 up from 20th place last year and is now ranked higher than Ruby and Go.

https://www.tiobe.com/tiobe-index/

I made an interesting transition a few years ago, and started using Unicode in my programs.

(1) I have an i18n mapping which provides native support for a lot of helpful characters. Both Mac and Linux use all the keys, so in addition to the half-dozen characters with accents, I have access to a lot more directly. Mac and Linux do remap the remaining keys differently, though.

(2) My code got a lot more readable. Δx is easier to read and more concise than delta_x.

(3) I have a lot more characters to pick from.

A lot of the issues you raise with regexp are due to limits of ASCII.

For more esoteric characters, I do Google and either enter alt codes or cut-and-paste, which might sound like , but remember that you write code once, and read it many times. And editors are increasingly good.

Beyond Unicode, one does have text formats with support for colors, bold, and whatnot, either embedded (escape codes in text) or as syntax highlighting (editor parses).

The CS-level reg exps seem like a good idea. The implementation -- where they're encoded as bizarre ASCII escape sequences -- could use a good revamp.

Oddly enough, I think this is my first HN post where I went beyond ASCII....

Edit: And HN filtered out a bunch of Unicode. It kept only the delta.

> What? You're going to hand code a lexer each time you need to parse a phone number or a zip code? If there was a better alternative we would be using it.

STOP PARSING WEB FORM INPUT. Please. For the love of God just stop.

This is why emails of the form "foo+bar@fakeaddress.myemail" rarely work. Somebody's regex didn't allow "+" and everybody copied it. If you really need to check an email address, send a verification email to it. It's the only method that actually works.

Why are you parsing a phone number. The user typed in a phone number, obey it. Are you sure that you know every combination of valid phone number?

Zip code ... maybe ... if you are US only. Otherwise a postcode can't be parsed either.

And this is before we talk about the Cardinal Sin of using regexes as parsers.

> Zip code ... maybe ... if you are US only. Otherwise a postcode can't be parsed either.

Also, don't store zip code as an integer. There are valid zip codes that start with zero that will likely get truncated if you store a zip code as an integer.

Excel being helpful that way has been the Bain of my existence

Set the type of the cell to text:

1 Highlight cell, or range/column

2 ctrl+1 or right click + format cells

3 select text from the type combo box

> The worst aspect of C would be pointers and unsafe memory access, which Perl doesn't have.

In a practical sense, it doesn't. But it's there if you specifically go digging for it:

    $ perl -le 'print unpack("p", pack("p", "Hello, world."));'
    Hello, world.
    $ perl -le 'print unpack("p", reverse(pack("p", "Hello, world.")));'
    Segmentation fault (core dumped)
    $

IMHO, grammars in Raku are much better than regexps in many situations, except oneliners.

https://docs.raku.org/language/grammars

There is! I do! It's Parsing Expression Grammars!

There's a reason Rakudo adopted them in its quest to out-Perl Perl (5).

Regex is fine as an adequately-powerful shorthand for command-line munging and text editors, where the terseness is useful. It turns on you as soon as you want to use it in a programming language... which is where Perl comes in.

> What? You're going to hand code a lexer each time you need to parse a phone number or a zip code? If there was a better alternative we would be using it.

Use a parser combinator library. I've yet to find a case where they weren't a better replacement for regexes.

The case where one can drop in a battle-tested, documented regex in 15 seconds and get on with your life.

In my experience even the "battle-tested, documented" regexes often have surprising edge cases.

> And the worst parts of Common Lisp would be the massive, inconsistent, designed-by-committee language, CLOS, and macros.

I've always wondered what would happen if there was a CL standardization where everything was CLOS'ified in the :common-lisp package, so the #'+, #'map(can), etc. were generic functions along with a nice set of collections (dictionary, etc.). And the more specialized/efficient functions were squirreled away in a non-default package. Well that, and a bunch of other things like a different module system. SBCL seems like such a nice compiler that doesn't get the respect it deserves for being able to compile fast binaries for such a dynamic language.

There are lots of good ideas floating around for a second CL standard. The problem is, either such a language has a CL compatibility environment, in which case it is probably implemented in CL using the features already in the language, meaning that it's really just another Quicklisp package; or it doesn't, in which case it has to fill some need that couldn't be filled the first way in order to attract a critical mass of interest. Julia is the closest thing I'm aware of to the latter.

It's hard to get people to switch from something they find good enough for their needs, if the new thing is incompatible. See: Perl 6.

In the case of Perl 6 this has resulted in a rename of the language to Raku (https://raku.org using the #rakulang tag on social media). An experience I would not recommend.

Never use LOOP. I don't! (Except in the trivial keywordless form in which it means "loop forever".)