Still happens about every five years, although I am reaching for Python more and more in those situations.

What always kills me is the weirdness of the basic data structures, array/stack function calls, and the truly impressively weird ways Objects are done.

Well, Perl 5 has scalars, arrays and dictionaries -- just like Python. Unlike Python, however, Perl function arguments are always implicit/variadic by default (and stored inside the implicit "@_" variable). This can be a benefit or a curse depending on the context. Furthermore, Perl 5 does support both "call by value" and "call by reference". This distinction can confuse programmers coming from more modern languages where usually everything is a scalar reference. But you have to keep in mind Perl was invented in the 80s and put great emphasis on compatibility. Changing calling conventions would have broken many modules.

edit:

Regarding objects: The object system is rather simple, it's just many Perl hackers invented their own object systems on top of that. Basically, a Perl class is just a module. An object is just a reference to a dictionary that got the class name attached by applying the "bless" operator:

  package Foo;

  sub new {
    my ($class) = @_;
    my $object = {};

    bless $object, $class;
  }

  sub do_stuff {
    my ($self) = @_;

    # do stuff

    return $self;
  }

  my $obj = Foo->new();
  $obj->do_stuff()->do_stuff();

    package Foo {
        use MooseX::Extended;

        sub do_stuff ($self) {
            # do stuff

            return $self;
        }
    }

    my $obj = Foo->new;
    $obj->do_stuff->do_stuff;

It all just ends up feeling deeply weirds and unique compared to other languages. Hence the need to relearn it every time I touch it.

As it turns out, they used Perl, one of the few sanctioned languages at Yahoo.

The coding style handed over from the client forbade every other thing that Perl fans tell you that make the language warm and endearing to them; you were allowed to use about a few of the sigil variables, all the data structures were to be used in their "object reference" form, because it sidestepped the "contexts" functionality of Perl, which was to be avoided at all costs.

I remember the tedium of having to maintain your own stacktrace, because all you got was a the `$@`, `$!` and `$?` variables, which contained precisely the last of various types of error encountered during execution within the process. If you encountered errors while performing error handling, the original error would be lost, so you had to keep a backup.

Edit: man, the contexts, the fans sweared by them, making analogies to natural language; I'm sorry to sound elitist, but they often came across as enthusiastic amateurs rather than people with a formal background in Computer Science. They claimed that things like passing an array to a place where an integer is expected to get the length was richness, not insanity.

With Carp::confess you get the stack trace easily when throwing an exception. It's been a core module for ages.

Of course, Perl lacks a flexible condition system like Common Lisp. So all you got is an exception object you can try to handle but no restart handlers you can use to go back down the stack trace. But that's a common limitation of almost all languages supporting exceptions natively.

Their were some talented folks but I'd like them more to cowboys - git'r done instead disciplined engineers.

Lots of production applications that had the code quality of your typical hacky side project.

I once had a debate with my manager about classes/OOP in PHP5. He didn't like it because it usually meant having separate files and includes per class, and he likes to have all code for a PHP page in a single pane in Vim. "But Kenny it's all in one file, everything I need to work on is right here!"

I still laugh about that.

We laugh about it now, but that's why we end up with things like this:

https://www.nytimes.com/2017/10/03/technology/yahoo-hack-3-b...

https://perlmaven.com/wantarray

That always appeared as madness to me. Why would you make things that cryptic to understand?

You can do that in Java, if I understand that feature correctly.

For example, it's possible to write a method that returns a generic type over whatever type you're trying to assign to, e.g.:

    static <T> List<T> listOfAnything() { return (List<T>) new ArrayList(); }

    List<String> stringList = listOfAnything();

    List<Integer> listOfInts() { return listOfAnything(); }

    static List listOfAnything() { return (List) new ArrayList(); }

    List stringList = listOfAnything();

    List listOfInts() { return listOfAnything(); }

    static <T> T deserialize(String input, Class<T> cls) { ... }

    MyStruct result = deserialize(input, MyStruct.class);

    static Object deserialize(String input, Class cls) { ... }

    MyStruct result = (MyStruct) deserialize(input, MyStruct.class);

Wantarray is not a generic implementation. It's closer to reflection. You can detect the type of variable the caller is putting your functions result in. Then you can branch your program based on the variable type that the caller wants. I guess this is similar to type inference but not exactly as it's not part of the type system. For example, if they want an array return the amounts of each transaction in an array if not return the sum of the transaction amounts.

Python's ordered arguments mixed with out of order labeled arguments is worse IMO: Tell me arguments in this order. Or not... I mean, you could just tell me which they are. Wait, I got two of these... F*ck this, I quit

(1) Un-named arguments come before any named arguments and should be passed in order (this is familiar to programmers in almost any mainstream language).

(2) Named arguments can then follow, in whatever order.

The interface is awkward however in that in other languages you would overload the function or pass a data structure, or reference of one, to manage additional optional parameters when you didn't want the extra arguments explicitly listed.

Python is a popular language and there are a ton of contributors who have developed third party packages. Unfortunately, these are not always well written or maintained and it can be easy to stumble across a bad one when looking for useful things. It's never fun to debug code in an unfamiliar language.

Perl is well known for it's multitude of idiosyncrasies, this is one of the reasons why it can be frustrating to programmers who have better experience in more modern or rigidly structured languages.

I adopted the contextual thinking fairly easily so it was not an issue for me but having worked with so many languages since perl I can see why this would be annoying to others. It's not the most unfortunate aspect though.

https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

Like here:

    sub some_function($) {
        my $some_var = @_;
        print("$some_var\n");
    }

    my @arr = (1, 2, 4, 7);
    some_function(@arr);

IMO it is still mostly unmatched in that area. Most other languages, while just as capable, require far more line noise to interact with streams and use regexes. I admit though I have studiously avoided learning awk and sed over the years.

I'd love some day to have the power-shelly dream of an object oriented platform. But I don't want to renounce all the cli tools I know & love & switch to a strange new platform to get it.

    c:\temp\program.exe

  & "C:\Program Files\Vendor\AwesomeVendorProgram.exe"

???

tab completion generally works on space-filled path/names too, at least in the last 10 years or so, when working in windows worlds.

  PS C:\Users\me> "C:\Program Files\PuTTY\plink.exe"
  C:\Program Files\PuTTY\plink.exe

My actual experience is pretty much identical to bash and zsh. There's not really any additional cognitive load. Maybe the commenters in this thread aren't used to normal *NIX shells? I don't have any experience with fish or oh-my-zsh.

PSVersion 7.3.3

I even went as far as to spawn the ancient version of powershell included with Windows and pwsh 7.3.4 without a profile and tab completion adds the ampersand. I do import the PSReadLine module though in my profiles so maybe that is providing the functionality and I was wrong about loading an empty profile.

I learned enough awk to get by, but if you actually want to do advanced processing it can be even more inscrutable than perl, which can do everything awk can and a lot more.

Means as a language it's not suitable for "have it installed on every system and then just throw code at it that will work, and keep working" like Perl. Even if you could convince all the distro maintainers to include it, you'd never have the version you want/need. Which would be different for different scripts, and you'd have to be constantly updating all your routine maintenance scripts you just wanted to put there and have them keep working -- which with Perl you could.

I wish ruby were more about backwards and forwards compat, but it isn't.

As it stands, unfortunately CPAN is full of rotting modules. While it may be a maintained and usable language still, that puts a huge damper on any non-trivial development, because at any time something important might turn out to be broken or unmaintained, or without an API at all.

I agree hard times. Hubris is at fault.

Perl did too much and reached for the stars. Its happy place was a sane job control language. A niche Python is filling.

I have used both, Perl extensively, Python when I must. Perl is much better, but being better is not enough.

Perl did "everything". Python was "object orientated". People wanted the shiny "object orientated" and, sadly wisely, did not want a language that could do anything and everything.

I blame Larry Wall, the genius, both for Perl's success, and Perl's failure. If only I could fail so brilliantly!

Write a Python function that writes an object's string representation to a file:

  def write(obj): open('/tmp/foo', 'w').write(str(obj))

  write(123)

  write(["spam", "eggs"])

  write({(1,2):{3,4,5},('spam','eggs'):{6,7,8}})

At first, I thought I had to be missing something, like maybe it was impossible to do trickier things because they made the simple things so easy, but no. It just turned out that some of Perl's design decisions increased my cognitive load way more than strictly necessary. That's clearly not true for everyone, but it sure was for me. The first day I wrote Python was the last day I wrote Perl.

Well, Data::Dumper is included in core Perl ...

    use v5.12.0;
    use warnings;
    use autodie;
    use Data::Dumper;
    
    sub logit {
        open state $log, ">>", 'c:/tmp/foo';
        print $log Dumper(@_)
    }
      
    logit(123);
    
    logit(["spam", "eggs"]);

    logit({"(1,2)"=> [3,4,5],"('spam','eggs')"=> [6,7,8]});


    # even logging multiple objects at once ...
    logit(
          123,
          ["spam", "eggs"],
          {"(1,2)"=> [3,4,5],"('spam','eggs')"=> [6,7,8]},
         );

And I opened the filehandle only once. And for append not overwrite like you did.

I don't think it was so much hubris as bad communication.

Perl 6 was understood to be that: Perl 6, a definite successor to Perl 5. But besides being very, very late it turned out not to truly be Perl 6, but a new, incompatible, Perl-ish language.

I think the decision to rename it to Raku was a good one, but came too late. By then the world had already moved on.

Done early enough I think it'd have fixed things. It'd have created the clarity needed to understand that Perl 5 wasn't going away, and that it was pointless to wait for a successor.

Bad communication isn't one of those (although, given the prevalence of bad communication in the industry, one might assume it is ...).

maybe that was your happy place for Perl, but it certainly wasn't mine or that of lot of Perl users I've known over the years.

  #!/bin/perlish
  while (<>) {
    /* regex match */
    /* do some stuff, with variables or the file system or whatever */
  }

I mispoke. "A happy place" I shold have said

I never learnt awk or sed bedcause I knew Perl.

That loop, often in a command line invocation `perl -e 'while(<>){chomp;......}'`

My point is its happy place was not application programming, gui systems. AS I commented elsewhere here processing every Apache hook.

Pythin suffers the same problem. It too is brilliant at the little jobs, yet there are many GUI junk piles written in it, just as happened with Perl back in the day

> I have used both, Perl extensively, Python when I must. Perl is much better, but being better is not enough.

> Perl did "everything". Python was "object orientated". People wanted the shiny "object orientated" and, sadly wisely, did not want a language that could do anything and everything.

I don't know what kind of Python you've tried using, but it seems you got some defective ancient 2.x version. Python is exactly the kind of language that should be replacing Perl, simply because it's the best glue language out there right now, with modules that are actively being maintained and developed.

And, as a cherry on top, actually has human-readable syntax.

When tabs and spaces have different syntactic meaning, I am suffering quite a bit of revulsion.

I have to do it, but I want to control my own white space for my own purposes.

It comes down to taste, I guess. I am not wrong, but neither am I correct

I don't think it has anything to do with it. Perl 5 is an old language. Period. And Javascript came to inherit Perl's position as a "web glue language". These days JavaScript is an okayish language to use in this case.

Raku fka "Perl 6" is out and alive: https://www.raku.org/

It turned out to be a very powerful programming language but lacks the large niches Perl 5 (the web) or Python (machine learning) catered to.

That's an odd way of looking at it. C is an old language. C++ is an old language. Java is an old language. Nobody is arguing against them because they're "old".

Moreover, just because something is old doesn't mean you throw it away. How many newer languages have come, and gone, just in the time since Perl hit its peak?

C lives off its niche as being the lingua franca for programming low level interfaces. Java lives in its corporate niche and C++ mostly in game programming and large desktop applications.

Perl 5 has become an orphan. It’s a programming language nobody needs any more and, hence, shares the fate of many other obsolete languages that may be cool but are unpopular.

When you know it & it's various implicit various implicit variables, you feel enormously powerful, are able to make really beautiful use of the bountiful context Perl leaves out for you. It's heady & compelling in a way almost nothing else ever has been for me.

Pass by sigil is weird but everything being named symbols is a powerfully simple concept, that opens interesting roads.

But gee it sure is nearly impossible to read after. Rebuilding the context of how everything fits together, remembering each little rule you've taken advantage of is a trying puzzle indeed.

Sidenote, it's a long far off hope (lots of the base deb tools are Perl), but I hope someday we can run a Debian system without Perl, that we end up with more mature replacements eventually. It being everywhere is the authors #1. In general they try to present practical sensible reasons. But so few are language specific concerns, are context but not really talking "Why Perl" itself, why Perl the language. The seductive heady weird ambiance of Perl is so unique, is a much less structured & clear "why".

I am not a competent $language programmer. You will not understand my poorly written code.

In this case, language="perl".

perl is not special in this regard.

Which is a bad decision, in every language you're going by intuition 95% of the time, it's when a piece of code works in an unfamiliar way that you reason from first principles, and then having clear and rigid rules to fall back on gets you out of the rut more quickly. Perl's design makes this harder for purportedly giving you more tools to write code that looks about right.

If you pay "market rate", you'll have some good engineers and some desperate engineers, with the ratio slowly trending in the negative direction over time.

Point is, that's definitely a solvable problem, but only if you watch out for hard-to-quantify externalities.

Anyway, if the salaries have to keep going up to keep high quality engineers, the economics of rewriting and/or deleting legacy code start being a lot more straightforward.

like most things, it's a money problem.

It hasn't.

In python, regex's are an effing library.

In perl they're built into the language and can be summoned in a much more concise and efficient (metric:code clarity) way than python will ever manage as long as the bloody 'import re' will be required.

Python's popularity hurts it for use when you want compatibility. Containerizations can only mitigate this so much.

I couldn't remember the title of this memorable talk, but ChatGPT could:

Q: In which talk by David Beazley does he recommend writing new Python code that takes full advantage of the language's new feature, without worrying about making it backwards compatible?

A:

David Beazley is a well-known Python expert who has given several talks on various aspects of the language. However, one of his talks that emphasizes the importance of taking advantage of new features in Python, without worrying about backwards compatibility, is "Python 3 Metaprogramming".

In this talk, which was delivered at PyCon 2016, Beazley highlights the benefits of using Python 3's new metaprogramming features, such as type annotations, function annotations, and asynchronous programming. He argues that these features can make code more concise, readable, and maintainable, and that developers should not be afraid to use them, even if it means breaking backwards compatibility with older versions of Python.

Beazley's message is clear: by taking advantage of new language features, developers can write more efficient, expressive, and scalable code, without worrying about the limitations of older versions of Python.

Q: Give me a link to that video.

A:

Sure! Here's the link to David Beazley's talk "Python 3 Metaprogramming" at PyCon 2016:

https://www.youtube.com/watch?v=sPiWg5jSoZI

I hope you find it informative and helpful!

Q: What are his arguments for not worrying about backwards compatibility?

A:

David Beazley's main arguments for not worrying about backwards compatibility in his talk "Python 3 Metaprogramming" are:

1. New language features can make code more expressive and efficient: Python 3 introduced several new language features, such as function annotations, type annotations, and asyncio, that can make code more concise, expressive, and efficient. By using these features, developers can write cleaner, more readable code that is easier to maintain and debug.

2. Older versions of Python can be managed through virtual environments and package managers: Developers can use tools such as virtual environments and package managers to manage different versions of Python and dependencies. By isolating different versions of Python and packages, developers can ensure that their code works correctly on different platforms and environments.

3. The community will eventually move to newer versions of Python: As more developers adopt newer versions of Python and start using the latest language features, the community will gradually move away from older versions of Python. This means that eventually, the majority of users will be using newer versions of Python, making backwards compatibility less of an issue.

4. Code refactoring tools can help with compatibility issues: There are several tools available that can help with code refactoring and modernization, such as 2to3, which can automatically convert code from Python 2 to Python 3. By using these tools, developers can make their code compatible with multiple versions of Python without having to sacrifice the benefits of newer language features.

Overall, Beazley's argument is that developers should not be afraid to use the latest language features in Python 3, even if it means sacrificing backwards compatibility with older versions of Python. By doing so, developers can write cleaner, more efficient code that is better suited to modern software development practices.

You lost a bunch of people right there. There's a significant difference between "open a terminal" and "install Docker, create a container, configure the latest version of Python."

is the usual way to fix this. Far more common is running into UTF-8 problems, but using the usual -CSDL and the UTF-8 open default handles the issues.

But honestly installing anything like that (without WSL probably - haven't used it recently) on Windows is painful, it's not python's fault, it's just a different paradigm. Run with a different environment variable for example.

To the best of my knowledge you must install one of two main distributions of Perl for Windows. https://www.perl.com/article/downloading-and-installing-perl...

You can also use WSL.

Edit: It sounds like, from other comments, that Perl comes with Git Bash as well.

We used Netscape Fasttrack as the server.

Maybe it was considered technically by some of the programmers, but swiftly quieted by PMs.

NOTE: I am (probably mistakenly) assuming that Perl is still bundled in most Linux distros by default.

[1] https://developer.apple.com/documentation/macos-release-note...

After 15 years (much more the 10,000 hours of use) it was hard to forget. And that over 15 years ago. Once you have it in your brain it does not go away easily.

I teach Python but I still think in Perl.

If you are a good programmer, you will write good Perl and Python code. If you are a bad programmer, you will likely write terribly horrendous Perl code and slightly less horrible Python code.

Your vote ratio reflects the relative fewer excellent programmers to weigh in on your point.

Majority: Python is pretty, perl is line noise.

Minority: Simple isn't easy, succinct is expressive.

https://perldoc.perl.org/perl#History

Works out of the box on everyone’s Mac.

Mojo covers a lot of what you’d expect from modern web application development, and it does so with finesse. I hope it gets more attention. It seems many unfairly still associate Perl web development with a hodgepodge of bad CGI scripts.

Perl is only ubiquitous in the Linux/Unix world. Try running it on Windows. You have to install some half working package.

I have a strong dislike for Perl as I worked with it for many years. Much of that is that I knew nicer tools existed and I wanted to use them but some was they syntax. I hate the terse syntax and the gotchas.

Issues like this https://stackoverflow.com/questions/7515029/cant-turn-off-bu....

If you are new to Perl what is $|=1; going to mean to you?

Then there is the fun of "Wide strings" https://stackoverflow.com/questions/9299941/perl-unicode-wid...

You of course have to know the operators in Perl. There is a good reference https://perldoc.perl.org/perlop but I remember before I found that page in the docs I was lost.

Then there is the use of references. Do I need a \% here or just a % no wait I need a \$. It's not that hard but it's a friction I got sick of.

Yes all languages have their warts but I did not like Perl's even after almost a decade of working with it.

I know FastMail does. IMDB was in Perl before Amazon acquisition, and was told was rewritten in java over several years. Any other interesting mentions?

I don't want to name names, but a few prominent Perl contributors work there (yours truly included).

   $ dpkg -l|grep -i proxmox|awk '/perl/ { print $2}'
   libproxmox-acme-perl
   libproxmox-rs-perl
   libpve-apiclient-perl
   libpve-cluster-api-perl
   libpve-cluster-perl
   libpve-common-perl
   libpve-guest-common-perl
   libpve-http-server-perl
   libpve-storage-perl

 [1] https://proxmox.com/

Slashdot

The Register

BBC iPlayer, at least originally

Also I'm sure someone recently wrote a text-based MMO in Perl but I forget the name of it

He addresses the issue of why PHP not Perl became the "winner" on the web. (About ten minutes into the talk)

In his opinion it was due to the Apache modules that build PHP, alternatively a Perl, interpreter into the Apache server

PHP's implementation implemented just enough to make it work (document generation hook), while Perl implemented all bells and whistles, including path translation. This made all the Apache hooks available to the Perl programmer.

On shared servers using a single Apache server and virtual host with several websites running on one Apache server this meant a Perl programmer could hijack the whole server

Hubris

Many stuff in userspace UNIX would still be fast enough for its tasks if done in Perl instead of C.

> ChatGPT> Rewrite the following as concisely as possible in perl, perl 6, J, Haskell, with no explanation and only code:

    history | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head

    `history | perl -ne '/^\s*\d+\s+(\w+)/ && $a{$1}++; END { for $i (sort {$a cmp $b} keys %a) { print $a{$i}." ".$i."\n"; } }' | sort -rn | head`

    `history | perl6 -ne '/^\s*\d+\s+(\w+)/ && $a{$1}++; END { for $i (sort keys %a) { say $a{$i}." ".$i; } }' | sort -rn | head`

    `head sort |. |:+/ ,.~ [: ~. stdin -: i.0"1 <@:". ]

    `reverse . take 10 . sort . map (\x -> (length x, head x)) . group . sort . map (words) $ lines <$> readFile ".history"`

history | perl -ne '/^\s*\d+\s+(\w+)/ && $a{$1}++; END { map { print "$a{$_} $_\n" } splice((sort {$b <=> $a} keys %a),0,10) }'

Oops, just realised it should be sorted by the value and not the key so...

history | perl -ne '/^\s*\d+\s+(\w+)/ && $a{$1}++; END { map { print "$a{$_} $_\n" } splice((sort {$a{$b} <=> $a{$a}} keys %a),0,10) }'

Also noticed that splice() isn't setting wantarray() so you'll need to use direct indexing which is probably easier to write too...

history | perl -ne '/^\s*\d+\s+(\w+)/ && $a{$1}++; END { map { print "$a{$_} $_\n" } (sort {$a{$b} <=> $a{$a}} (keys %a))[0..9] }'

Here are the rewrites in Perl, Perl 6, J and Haskell:

Perl:

> perl -e 'while(<>){$a{$F[1]}++}for(sort{$a{$b}<=>$a{$a}}keys%a){print"$a{$_} $_\n"}' <(history)

Perl 6:

> my %h; for lines() { %h{.[1]}++; }; for %h.sort(-*.value) { .say }' <(history)

J:

> echo 'history' | jconsole -e '10 {. /:~ [: >: [: +/"1 [: =/ [: ;: [: >: [: ;: [: cut ;._2 ] ] ] ] ]'

Haskell:

> import Data.List

> import Data.Ord

> import System.Process

> main = do

    h <- readProcess "history" [] []

    let l = map (head . tail . words) $ lines h

    mapM_ print $ take 10 $ sortBy (flip $ comparing snd) $ map (\x -> (head x, length x)) $ group $ sort l

# Perl perl -e 'print sort { $b <=> $a } map { /^.\s(.)$/; \$1 } <>' <(history | awk '{a[\$2]++}END{for(i in a){print a[i] " " i}}')

# Perl 6 (Raku) perl6 -e 'lines().map({m/^.\s(.)$/; \$0}).sort({-$^a}).say()' <(history | awk '{a[\$2]++}END{for(i in a){print a[i] " " i}}')

# J history | awk '{a[\$2]++}END{for(i in a){print a[i] " " i}}' | jconsole -je 'echo/:~1!:1]fread'''''

# Haskell ghc -e 'interact $ unlines . take 10 . reverse . sort . lines' <(history | awk '{a[\$2]++}END{for(i in a){print a[i] " " i}}')

For some values of "everywhere". Pretty sure this is not true on Windows, for example.

I don't think a basic Arch Linux installation includes perl. Windows as you say would surprise me. 'the major Linux distributions' (plus I think macOS, perhaps inherited from BSD, no idea) might be fair, but certainly not 'everywhere'.

[1] I think it used to be part of the base system, at least.

https://bsd.slashdot.org/story/02/05/14/0015234/freebsd-perl...

And this was the right move. It meant that the version of Perl was decoupled from FreeBSD releases, allowed you to choose which version to install, and allowed you to install multiple versions if needed.

Yes, I’m aware of some rotting modules on CPAN that half-assedly implement them, but given that they exactly bolt it on, they are full of gotchas, like Try::Tiny, with which it’s quite easy to forget that a return statement in the try block will do exactly the wrong thing.

Try::Tiny does its best without manipulating the parser itself; it's been superseded by Syntax::Keyword::Try (which alters the parser to make flow control work as you'd expect), and in the last few years of releases there is a native `try` keyword right in the language (which can be used in older versions via Feature::Compat::Try, which is a shim on top of Syntax::Keyword::Try in old versions and a no-op in new versions).

Perl's regexes (unlike python and a swath of other languages) are first class citizens in the language (and not some effing library you have to import, along with its clunky API).

To wit:

    PERL:

        $x = $1 if(/^Line_start[ \t]*([0-9]+)/);

    PYTHON:

        import re
        m = re.match(r'^Line_start[ \t]*([0-9]+)/, line)
        if m:
           x = m.group(1)

This is the only reason that still makes me sometimes pick Perl over python when I need to slap together a quick and dirty run-once script to chew thru a big pile of data.

Other than that, as much as I've used Perl over the years and found it extremely useful back in the day (coz it was the best there was at the time), it is a horrible language by modern standards ($ to identify variables, having to tell the compiler that an expr is at an end with a ';', ugh), and it is time to let it Rest In Peace.

One you have a name and a design where you can test the boundaries of that regex without, say, downloading large files or rearranging the filesystem, you aren't really buying all that much by avoiding some extra library boilerplate.

But I'll admit that native support for regex comes in handy for throwaway scripts.

It's my still go-to language for quick implementation in a minimal number of lines however.

I found it hard to hire for Perl, so I switched the team over to Python.

Hmm…

Python has some semi-decent type hinting, these days. It's not so bad, it'll keep you out of most of the same trouble that TypeScript does.

[1] https://metacpan.org/pod/Type::Tiny

[0] https://www.mcmillen.dev/sigbovik/

I liked it because it is interesting to read other people's examined opinions on topics that I am ignorant of.

The most interesting part are the HN comments, and without reading the story first, it is rude and less interesting commenting.

So short stories are a plus for me!

I spent too much time trying to guess at the author's reasons. Why are Python and JavaScript not extensible but R is?