5 ms·

Perl has a huge amount of terrible design decisions and low hanging fruit, yet it has barely improved over 20 years. While python got dataclasses and type chec

by rjh29 2y ago

Perl has a huge amount of terrible design decisions and low hanging fruit, yet it has barely improved over 20 years. While python got dataclasses and type checking perl got... a few syntax upgrades many of which never left experimental and ended up being deprecated. The smartmatch implementation was beyond terrible, and implicit arrayref arguments should have never made it past the design phase. And still no native object/class system. Still no working exception handling! I don't know if the perl runners are incompetent, badly organised or just hamstrung trying to guarantee backwards compat for all the legacy code. But as a Perl user it has been very frustrating to watch.

mgarfias 2y ago
They spent 15 years working on perl6 and the world moved on
- petre 2y ago
  More like 20. And pel6 is now a different language, raku, as they abandoned all hope to unify them. Even the community has splintered between perl and raku.
rabbits77 2y ago
I'd say you're being a bit overly cynical. There's plenty of good news in Perl too. specifically, since you mentioned smartmatch, that's been pretty well fixed as of a couple of weeks ago with Switch::Right https://metacpan.org/dist/Switch-Right https://metacpan.org/dist/Switch-Right. As is tradition this was the subject of a very engaging talk at the most recent TPRC: https://www.youtube.com/watch?v=0x9LD8oOmv0 https://www.youtube.com/watch?v=0x9LD8oOmv0
- petre 2y ago
  As usual, it's a module when it should be a language feature. Too much useless talk and not enough stuff getting done.
  - wwweston 2y ago
    If it’s available via a module, it’s done. And it smoothes over some versioning/compat issues. Useful talk deals in benefits and tradeoffs (as the linked article demonstrates in spades). Useless talk deals unsupported “should”s.
    - redundantly 2y ago
      The Perl module system is awful.
      - recrof 2y ago
        how so?
        rjh29 2y ago
        Serious answer: * the module system literally just runs a script, so it can do -anything-. As a result there are 3 or 4 competing install systems all with their own cruft, some defined entirely using Perl as config, some using YAML. You need to have all of them installed. * Of these, Module::Build is a common one written by someone who completely overengineered it, and it installs hundreds of dependencies, even though all it really does is just copy some files. * Install scripts can do stuff like ask you interactive questions that prevent automated installation, which is a constant hindrance when packaging Perl modules e.g. to RPM * Perl leaves literally everything up to external modules, including exporting functions or even defining module dependencies (e.g. 'use base', 'use autoclean', 'use Exporter' ...) and often the module config is written entirely in Perl rather than YAML or JSON file, so trying to do anything clever (like add IDE/language server support) is an absolute nightmare. * The client to install new modules initially asks about 20 questions and does a slow mirror test, making it difficult to use in automated settings. Luckily someone wrote cpanminus which literally does exactly what you want - installs the damn package.
      - petre 2y ago
        It's a lot better than Node's NPM.
- rjh29 2y ago
  Switch modules have been around for years. There's Moo and Try::Tiny too. Some of this stuff should really be part of the language by now. Same with exporting functions.
superkuh 2y ago
I am feeling a different end of the Perl elephant. To me Perl becoming unpopular and not "improving" has meant that code I wrote in 2003 still runs today in 2024. And nearly all the code I write now will run on that perl interpreter from 2003. That kind of multi-decade stability is exactly what a system management (or personal codebase) language needs. It's an amazing boon for people who want things to just work and keep working. It isn't hamstrung; it's a language that has stayed itself. If you want to run a perl script you just use your system perl (and it doesn't matter how old or new the OS is). If you want to run a python script you have to set up a container then use a package manager to setup an entire dedicated python and libs just for that script. Python may have acquired many nice features and refactorings but it stopped being a dependable shell language. It traded run time complexity for write time ease; it's that way with all popular languages eventually. Not being popular after the Perl 6/Raku debacle is the best thing that could've happened.
- kukkamario 2y ago
  It is quite easy to write Python code that works just with all Python versions since 3.6. Easier than writing any Perl code...
  - ajsnigrutin 2y ago
    Years ago, someone would say "It is quite easy to write Python code that works just with all Python versions since 2.6. Easier than writing any Perl code..." Then 2.7 came out.. and 3.0...
  - rjh29 2y ago
    Perl requires a 'use version' statement otherwise your code can't use anything added since ~15 years ago. Python has no such system, so it's hard to know if the code is going to work on any given version of python. The core modules also seem to change much more often than Perl's.
- userbinator 2y ago
  I am feeling a different end of the Perl elephant You mean camel? PHP is the elephant. ;-)
mfontani 2y ago
> And still no native object/class system. There's https://metacpan.org/dist/perl/view/pod/perlclass.pod https://metacpan.org/dist/perl/view/pod/perlclass.pod, which (granted) is experimental, but it's actively being worked on. > Still no working exception handling! There's https://metacpan.org/dist/perl/view/pod/perlsyn.pod#Try-Catch-Exception-Handling https://metacpan.org/dist/perl/view/pod/perlsyn.pod#Try-Catc... which is now (5.40) no longer an experiment, _aside from_ the use of `finally`, which warns. > trying to guarantee backwards compat for all the legacy code Not "all", as there are indeed deprecations added over time, but _most_. I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly.
- gwervc 2y ago
  > I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly. "Cool kids" languages like Python and Rust really put in the mind of people that a program written two weeks ago must be upgraded to run on the new version of the compiler or interpretor. Meanwhile there always have been languages like C# or C where a codebase from 15 years ago will compile and run just fine.
  - ajsnigrutin 2y ago
    Not just that, but cook kids change their languages weekly! HN is full of threads named: "<existing software> written in <language of the week>", and we all know how many people use that emacs fork written in ruby today, and how many will use the one written in Go in 10 years.
  - croes 2y ago
    For C# only if the necessary framework version is installed.
  - zelphirkalt 2y ago
    I think what you describe fits JS better. Already migrated your router library for your react project, this month? What, still not migrated!? No one is building things for X any longer! You need to switch to Y asap! I am not aware of anything in current Python 3, that has broken backward compatibility to an earlier Python 3. Some dependencies are implemented in ways, that will require you to use newer Python versions. Often those are packages, which are glue for lower level libraries. Like tensorflow. Perhaps I am describing the same thing as in JS ecosystem. But for some reason neither have I migrated to another way of defining my API routes in Django lately, nor have I had any need to in the last couple of years. I guess in the JS world there is just so much more half-backed stuff that gets hyped to no end, and this job guarantee is celebrated as "quick evolution".
jph00 2y ago
Perl literally copied Python's object system. It's weird to describe it as less "native" than Python. Python's dataclasses are just a simplified copy of the existing attrs pypi library. The implementation of them is a mess. I use Python every day and have plenty of nice things to say about it, but dataclasses and python types would be close to the top of the list of things I think are done most poorly in Python.
- supriyo-biswas 2y ago
  What features do you desire out of dataclasses? It’s been fine for the things that I’ve needed out of it.
  - deleted 2y ago
    [deleted]
- deleted 2y ago
  [deleted]
- tannhaeuser 2y ago
  > things I think are done most poorly in Python For ML stuff there’s no way around using Python (pytorch, TensorFlow, etc. etc.). While I appreciate that ML researchers make their models available to run locally, if you’ve ever run LLMs or SD, it’s very clear the focus is on getting models out of the door before others. But man is it a hot mess: every model needs its own Python version/installation from various sources (OS provided, github, package repos, python.org downloads, etc.), the code bases being rife with dozens of module and environment managers and other meta crap that obviously doesn’t cut it, Python devs using a dynamic language but then want types/annotations badly, etc etc. Sorry but from a SW engineering PoV, Python is pure and utter trash (it started life as a better BASIC for learning after all). I’m particularly puzzled by developers choosing/advocating Python for system administration and as shell replacement who now have to ship a locked–down Python version and package repo such as RedHat and Apple. Perl 5 code, by virtue of being frozen for over ten years in anticipation of what’s now called Raku, has a slightly better chance to run OOTB. But there’s no guarantee: recently came accross 2000ish Perl code using jcode (lib for Shift-JIS and other CJK two byte encoding) that I couldn’t run because jcode uses hashing sigills that were removed from Perl since or something.
ahartmetz 2y ago
Perl has been called "the first post-modern programming language" by its creator and the motto is "There's more than one way to do it". Both of these describe a write-only language, and Perl doesn't disappoint. Yes, I have seen well readable Perl code, it exists. But the language doesn't nudge you that way.
- rjh29 2y ago
  You need 3 months of training, code reviews and heavy linting!
deleted 2y ago
[deleted]
omoikane 2y ago
> barely improved over 20 years I read that as "Perl has remain stable for over 20 years". The perception that it has stagnated appears to be poor marketing for the new features. For example, this article from 2022-09-08: https://stackoverflow.blog/2022/09/08/this-is-not-your-grandfathers-perl/ https://stackoverflow.blog/2022/09/08/this-is-not-your-grand... https://news.ycombinator.com/item?id=32767218 https://news.ycombinator.com/item?id=32767218 Which starts off with "If you were to search the internet for recent articles about Perl, you might well be led to believe that the language hasn't changed in the last twenty years." My guess is that since older versions of Perl are mostly adequate and code targetting them continued to work year after year, there was little motivation to check out new features of Perl.
- rjh29 2y ago
  I use Perl full time and I know what they've added, but it's not a lot if you compare to other languages such as Python. Lexical filehandles were added in 2002. 'say' is just print except it adds a newline. Function signatures are a good addition, but that also took them about 15 years to implement due to bikeshedding. Luckily Perl is so powerful that third party modules can do pretty much anything. There have been modules out for 10+ years that hack the parser and added function signatures (with types!) to the language before Perl did. Unfornaturely they're buggy and if you make a syntax error the output makes no sense :P

by rjh29 2y ago

mgarfias 2y ago

They spent 15 years working on perl6 and the world moved on

petre 2y ago
More like 20. And pel6 is now a different language, raku, as they abandoned all hope to unify them. Even the community has splintered between perl and raku.

rabbits77 2y ago

I'd say you're being a bit overly cynical. There's plenty of good news in Perl too. specifically, since you mentioned smartmatch, that's been pretty well fixed as of a couple of weeks ago with Switch::Right https://metacpan.org/dist/Switch-Right https://metacpan.org/dist/Switch-Right. As is tradition this was the subject of a very engaging talk at the most recent TPRC: https://www.youtube.com/watch?v=0x9LD8oOmv0 https://www.youtube.com/watch?v=0x9LD8oOmv0

petre 2y ago
As usual, it's a module when it should be a language feature. Too much useless talk and not enough stuff getting done.
- wwweston 2y ago
  If it’s available via a module, it’s done. And it smoothes over some versioning/compat issues. Useful talk deals in benefits and tradeoffs (as the linked article demonstrates in spades). Useless talk deals unsupported “should”s.
  - redundantly 2y ago
    The Perl module system is awful.
    - recrof 2y ago
      how so?
      - rjh29 2y ago
        Serious answer: * the module system literally just runs a script, so it can do -anything-. As a result there are 3 or 4 competing install systems all with their own cruft, some defined entirely using Perl as config, some using YAML. You need to have all of them installed. * Of these, Module::Build is a common one written by someone who completely overengineered it, and it installs hundreds of dependencies, even though all it really does is just copy some files. * Install scripts can do stuff like ask you interactive questions that prevent automated installation, which is a constant hindrance when packaging Perl modules e.g. to RPM * Perl leaves literally everything up to external modules, including exporting functions or even defining module dependencies (e.g. 'use base', 'use autoclean', 'use Exporter' ...) and often the module config is written entirely in Perl rather than YAML or JSON file, so trying to do anything clever (like add IDE/language server support) is an absolute nightmare. * The client to install new modules initially asks about 20 questions and does a slow mirror test, making it difficult to use in automated settings. Luckily someone wrote cpanminus which literally does exactly what you want - installs the damn package.
    - petre 2y ago
      It's a lot better than Node's NPM.
rjh29 2y ago
Switch modules have been around for years. There's Moo and Try::Tiny too. Some of this stuff should really be part of the language by now. Same with exporting functions.

superkuh 2y ago

I am feeling a different end of the Perl elephant. To me Perl becoming unpopular and not "improving" has meant that code I wrote in 2003 still runs today in 2024. And nearly all the code I write now will run on that perl interpreter from 2003. That kind of multi-decade stability is exactly what a system management (or personal codebase) language needs. It's an amazing boon for people who want things to just work and keep working. It isn't hamstrung; it's a language that has stayed itself. If you want to run a perl script you just use your system perl (and it doesn't matter how old or new the OS is). If you want to run a python script you have to set up a container then use a package manager to setup an entire dedicated python and libs just for that script. Python may have acquired many nice features and refactorings but it stopped being a dependable shell language. It traded run time complexity for write time ease; it's that way with all popular languages eventually. Not being popular after the Perl 6/Raku debacle is the best thing that could've happened.

kukkamario 2y ago
It is quite easy to write Python code that works just with all Python versions since 3.6. Easier than writing any Perl code...
- ajsnigrutin 2y ago
  Years ago, someone would say "It is quite easy to write Python code that works just with all Python versions since 2.6. Easier than writing any Perl code..." Then 2.7 came out.. and 3.0...
- rjh29 2y ago
  Perl requires a 'use version' statement otherwise your code can't use anything added since ~15 years ago. Python has no such system, so it's hard to know if the code is going to work on any given version of python. The core modules also seem to change much more often than Perl's.
userbinator 2y ago
I am feeling a different end of the Perl elephant You mean camel? PHP is the elephant. ;-)

mfontani 2y ago

> And still no native object/class system. There's https://metacpan.org/dist/perl/view/pod/perlclass.pod https://metacpan.org/dist/perl/view/pod/perlclass.pod, which (granted) is experimental, but it's actively being worked on. > Still no working exception handling! There's https://metacpan.org/dist/perl/view/pod/perlsyn.pod#Try-Catch-Exception-Handling https://metacpan.org/dist/perl/view/pod/perlsyn.pod#Try-Catc... which is now (5.40) no longer an experiment, _aside from_ the use of `finally`, which warns. > trying to guarantee backwards compat for all the legacy code Not "all", as there are indeed deprecations added over time, but _most_. I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly.

gwervc 2y ago
> I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly. "Cool kids" languages like Python and Rust really put in the mind of people that a program written two weeks ago must be upgraded to run on the new version of the compiler or interpretor. Meanwhile there always have been languages like C# or C where a codebase from 15 years ago will compile and run just fine.
- ajsnigrutin 2y ago
  Not just that, but cook kids change their languages weekly! HN is full of threads named: "<existing software> written in <language of the week>", and we all know how many people use that emacs fork written in ruby today, and how many will use the one written in Go in 10 years.
- croes 2y ago
  For C# only if the necessary framework version is installed.
- zelphirkalt 2y ago
  I think what you describe fits JS better. Already migrated your router library for your react project, this month? What, still not migrated!? No one is building things for X any longer! You need to switch to Y asap! I am not aware of anything in current Python 3, that has broken backward compatibility to an earlier Python 3. Some dependencies are implemented in ways, that will require you to use newer Python versions. Often those are packages, which are glue for lower level libraries. Like tensorflow. Perhaps I am describing the same thing as in JS ecosystem. But for some reason neither have I migrated to another way of defining my API routes in Django lately, nor have I had any need to in the last couple of years. I guess in the JS world there is just so much more half-backed stuff that gets hyped to no end, and this job guarantee is celebrated as "quick evolution".

jph00 2y ago

Perl literally copied Python's object system. It's weird to describe it as less "native" than Python. Python's dataclasses are just a simplified copy of the existing attrs pypi library. The implementation of them is a mess. I use Python every day and have plenty of nice things to say about it, but dataclasses and python types would be close to the top of the list of things I think are done most poorly in Python.

supriyo-biswas 2y ago
What features do you desire out of dataclasses? It’s been fine for the things that I’ve needed out of it.
- deleted 2y ago
  [deleted]
deleted 2y ago
[deleted]
tannhaeuser 2y ago
> things I think are done most poorly in Python For ML stuff there’s no way around using Python (pytorch, TensorFlow, etc. etc.). While I appreciate that ML researchers make their models available to run locally, if you’ve ever run LLMs or SD, it’s very clear the focus is on getting models out of the door before others. But man is it a hot mess: every model needs its own Python version/installation from various sources (OS provided, github, package repos, python.org downloads, etc.), the code bases being rife with dozens of module and environment managers and other meta crap that obviously doesn’t cut it, Python devs using a dynamic language but then want types/annotations badly, etc etc. Sorry but from a SW engineering PoV, Python is pure and utter trash (it started life as a better BASIC for learning after all). I’m particularly puzzled by developers choosing/advocating Python for system administration and as shell replacement who now have to ship a locked–down Python version and package repo such as RedHat and Apple. Perl 5 code, by virtue of being frozen for over ten years in anticipation of what’s now called Raku, has a slightly better chance to run OOTB. But there’s no guarantee: recently came accross 2000ish Perl code using jcode (lib for Shift-JIS and other CJK two byte encoding) that I couldn’t run because jcode uses hashing sigills that were removed from Perl since or something.

ahartmetz 2y ago

Perl has been called "the first post-modern programming language" by its creator and the motto is "There's more than one way to do it". Both of these describe a write-only language, and Perl doesn't disappoint. Yes, I have seen well readable Perl code, it exists. But the language doesn't nudge you that way.

rjh29 2y ago
You need 3 months of training, code reviews and heavy linting!

deleted 2y ago

[deleted]

omoikane 2y ago

> barely improved over 20 years I read that as "Perl has remain stable for over 20 years". The perception that it has stagnated appears to be poor marketing for the new features. For example, this article from 2022-09-08: https://stackoverflow.blog/2022/09/08/this-is-not-your-grandfathers-perl/ https://stackoverflow.blog/2022/09/08/this-is-not-your-grand... https://news.ycombinator.com/item?id=32767218 https://news.ycombinator.com/item?id=32767218 Which starts off with "If you were to search the internet for recent articles about Perl, you might well be led to believe that the language hasn't changed in the last twenty years." My guess is that since older versions of Perl are mostly adequate and code targetting them continued to work year after year, there was little motivation to check out new features of Perl.

rjh29 2y ago
I use Perl full time and I know what they've added, but it's not a lot if you compare to other languages such as Python. Lexical filehandles were added in 2002. 'say' is just print except it adds a newline. Function signatures are a good addition, but that also took them about 15 years to implement due to bikeshedding. Luckily Perl is so powerful that third party modules can do pretty much anything. There have been modules out for 10+ years that hack the parser and added function signatures (with types!) to the language before Perl did. Unfornaturely they're buggy and if you make a syntax error the output makes no sense :P