Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Ha, fun bit of history! Many of the listed problems with Perl can be configured away these days. I don't have time for a full list, but as two early examples:

- `perl -de 0` provides a REPL. With a readline wrapper, it gives you history and command editing. (I use comint-mode forn this, but there are other alternatives.)

- syscalls can automatically raise exceptions if you `use autodie`.

Why is this not the default? Because Perl maintainers value backward compatible. Improvements will always sit behind a line of config, preventing your scripts from breaking if you accidentally rely on functionality that later turns out to be a mistake.

https://entropicthoughts.com/you-want-technology-with-warts

https://entropicthoughts.com/why-perl



That's a great read, thanks! And I didn't know about autodie, though I do use perl -de1 from time to time.

Perl feels clumsy and bug-prone to me these days. I do miss things like autovivification from time to time, but it's definitely bug-prone, and there are a lot of DWIM features in Perl that usually do the wrong thing, and then I waste time debugging a bug that would have been automatically detected in Python. If the default Python traceback doesn't make the problem obvious, I use cgitb.enable(format='text') to get a verbose stack dump, which does. cgitb is being removed from the Python standard library, though, because the maintainers don't know it can do that.

Three years ago, a friend told me that a Perl CGI script I wrote last millennium was broken: http://canonical.org/~kragen/sw/rfc-index.cgi. I hadn't looked at the code in, I think, 20 years. I forget what the problem was, but in half an hour I fixed it and updated its parser to be able to use the updated format IETF uses for its source file. I was surprised that it was so easy, because I was worse at writing maintainable code then.

Maybe we could do a better job of designing a prototyping language today than Larry did in 01994, though? We have an additional 31 years of experience with Perl, Python, JS, Lua, Java, C#, R, Excel, Haskell, OCaml, TensorFlow, Tcl, Groovy, and HTML to draw lessons from.


We can definitly do better than Perl. The easy proof is that modern Perl projects are supposed to start with a bunch of config to make Perl more sane, and many of them also include the same third-party libraries that e.g. improve exception handling and tweak the datetime functionality in the standard library.

One benefit Perl had that I think not many of the other languages do was being designed by a linguist. That makes it different -- hard to understand at first glance -- but also unusually suitable for prototyping.


What do you think a better design would look like?


It would be nice if there was one single incantation that you could use to basically get "Perl, but with sensible defaults for the modern age", rather than having to use individual packages to deal with specific idiosyncrasies one by one.

Basically something like "use strict" in JS.


This has been floated before and many people expect such a pragma to arrive at some point in the future.

For now, the relevant committees think some more experimentation and deprecation needs to happen before locking in the set of features to be considered modern.


I know this is probably not what you meant, but it's amusing to think about someone wondering if Perl has an equivalent to JS's 'use strict'!


Yep, I'm well aware that this is where it came from, so I guess I really should be asking for "use very strict" or something like that.

Come to think of it, that's a nice extensibility scheme, too - whenever you want to update it, just add another "very". ~


I wonder how many other language syntax things would be better in unary.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: