Comment by kragen | Hacker News Reader

Comment by kragen | Hacker News Reader

Parent Full thread

You may be interested in an article I wrote in ;login: 23 years ago: https://www.usenix.org/publications/login/june-2002-volume-2...

At the time Perl was the thing I used in the way I use Python now. I spent a couple of years after that working on a mod_perl codebase using an in-house ORM. I still occasionally reach for Perl for shell one-liners. So, it's not that I haven't considered it.

Lua is in a sense absolutely stable unless your C compiler changes under it, because projects just bundle whatever version of Lua they use. That's because new versions of Lua don't attempt backwards compatibility at all. But there isn't the kind of public shaming problem that the Python community has where people criticize you for using an old version.

JS is mostly very good at backwards compatibility, retaining compatibility with even very bad ideas like dynamically-typed `with` statements. I don't know if that will continue; browser vendors also seem to think that backwards compatibility with boring technology like FTP is harmful.

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.

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.

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.

That article is a pretty good overview at the time.

Only one benchmark on one system, but over in day before yesterday's HN thread on this (https://news.ycombinator.com/item?id=44464272), I report a rather significant slowdown in Perl start up overhead: https://news.ycombinator.com/item?id=44467268 . Of course, at least for me, Python3 is worse than Python2 by an even larger factor and Python2 worse than Perl today by an even larger factor.

FWIW, in Nim, you can get a CGI that probably runs faster than the Go of this article with simply:

    import std/cgi                  # By default both ..
    for (key, val) in decodeData(): #.. $QUERY_STRING & POST
      if key == "something":
         do_something(val)

I don't know of a `cgitb` equivalent even in the Nimbleverse. Some of the many web frameworks in Nim like jester seem to have that kind of thing built into them, though I realize a framework is not the same as CGI (and that's one of the charms of CGI).

Hey, thanks!

I should have also said, I suppose, that cgitb is less needed by Nim because the static typing catches more errors at compile-time. Indeed, for CGI programs, it might be wise to use the `{.raises: [].}` pragma to forbid successfully compiling if you even could raise at all, formally obsoleting any utility cgitb would have had. All just informational if anyone is tempted to write CGI programs in Nim. :-)

I never use cgitb in Web programs in Python though. I use it in console programs so I can just read what the error is instead of having to debug it. cgitb.enable(format='text').

Well, then you might like Nim for writing small CLI utilities. It just defaults to a console-friendly traceback on uncaught exceptions. cligen makes pretty nice CLIs pretty easy. (If you set up a $HOME/.cligen then you can get a shared colorized help / customization for any such utility, for example. So, set & forget kinda thing, maybe even making useful programs in as few as 3..7 lines of code, really.) It's not an experience without rough edges (though I'm not sure what is such an experience). So, probably depends on your priorities.

Reply on news.ycombinator.com