Live data from Hacker News

Perl's decline was cultural

beatworm.co.uk

251–260 of 472 posts

Re: Perl's decline was cultural

#251

Earlier quoted context omitted.

> Python 3 almost killed Python. People were being crybabies; the critics were extremely vocal and few. Python 3 improved the language in every way and the tooling to upgrade remains unmatched.

Python 3 was a disaster and enterprises were still undertaking pointless 2->3 upgrade projects 10 years later

Except that Python took the other path when migrating from Python 1 to Python 2 and ... guess what? That was a "disaster" too.

The only difference was that by the time of Python 3, Python programs were orders of magnitude bigger so the pain was that much worse.

Re: Perl's decline was cultural

#252
post #4

In fairness, Perl died because it was just not a good language compared to others that popped up after its peak. Sometimes people just move to the better option.

Exactly. Perl did regexes very well. It did basic hash tables okay. It did everything else poorly.

Once languages came along that did okay regexes and good hash tables along with getting other stuff decent, Perl just got pushed aside.

Re: Perl's decline was cultural

#253
post #8

I always found the Perl "community" to be really off-putting with all the monk and wizard nonsense. Then there was the whole one-liner thing that was all about being clever and obscure. Everything about Python came off as being much more serious and normal for a young nerd who wasn't a theater kid.

oh yeah you're right and this is coming from someone who still likes/uses perl once in a while for text manipulation stuff that awk/sed won't cut it for. try going into your terminal and typing in

  man 3pm Errno
And you get this code snippet:

           my $fh;
           unless (open($fh, "
man is that ever from a different time... but let me tell you if you can pull off some of those awk/sed or perl one liners you can do some pretty useful things with less resource allocation than you would be spending if you had written that in python, which becomes important if you're running it over and over on terabytes of data or on limited hardware

Re: Perl's decline was cultural

#254
post #34

Earlier quoted context omitted.

What incompatible versions of pythons do you mean? I'm entirely unaware of any forks, and the youngest version I have to supply at the moment is 3.9, which is over 5 years old and available in all supported platforms.

Try to run any random python program of moderate dep use on your python 3.9 system interpreter without using containers. Most likely you'll have to use a venv or the like and setup a special version of python just for that application. It's the standard now because system Python can't do it. In practice, pragmatically, there is no Python. Only pythons. And that's not even getting in to the major breakages in point ve…

> And that's not even getting in to the major breakages in point version upgrades or the whole python 2 to 3 language switch.

Python doesn't use semver and never claimed to do so, but it's probably worth treating "x.y" releases as major versions in their own right (so like 2.7 -> 3.0 is a major version and so 3.10 -> 3.11). If you do that, the versioning makes a bit more sense

Re: Perl's decline was cultural

#255

Earlier quoted context omitted.

It isn't bad language design that you need to study the language before you can use it. I look at haskell programs and it looks mysterious to me because I haven't spent any time studying it, but I'd not thing to say it is bad language design. Yes, one can write obscure perl code and some love perl golfing. In the same way there is an IOCCC which delights in unreadable code, it doesn't mean that the C language should…

But I can look at most Python code and be able to understand what it does. With perl, I have to look up so much. - Why is there a `1;` on a single line in the middle of this file? - What is `$_`? - This parallel execution manager doesn't actually seem to define what code needs to run in parallel in any specific way, how does this work? - What is this BEGIN block at the start of this Perl file? Why is that necessary?…

To be able to fully comprehend Perl (even without having to embrace it), one needs a fiddle.

Perl and some of Perl's quirks will make more sense once you realise that it is deeply rooted in UNIX command line utilities, UNIX conventions and some UNIX shell defaults, except when it is not, i.e.

  - What is `$_`?
$_ follows the spirit of shell variables (such as $*, $@, $! etc., heavily used in Korn, Bourne flavours but not the C flavours), but was repurposed or – more likely – picked from a pool of vacant characters with the help of a dice roll. Kind of like how ancient Egyptians built the pyramids with the help of sophisticated cranes and machinery and then vapourised their tools with high-particle beams to leave future generations guessing «how on Earth did they manage to do that». This is one of the main criticisms of Perl.

  - What is this BEGIN block at the start of this Perl file? Why is that necessary?
Perl started out as an improvement over «awk», and BEGIN is an awk construct where it is used frequently, e.g. awk 'BEGIN { IFS=":" } { … do something … }'

  - What does chomp do when it's just on its own line, with no arguments given to it?
It follows the standard convention of UNIX utilities that expect the input to come from the standard input stream (file descriptor 0 or given to chomp, it chomps on the standard input.

Re: Perl's decline was cultural

#256
post #191

Earlier quoted context omitted.

> One of my coworkers gave me some great perspective by saying, "at least it's not written in Bash!" I wish bash was the thing that was dying. As an industry, we need to make better choices.

There’s nothing that can replace bash for what it does. People have been trying for decades. You’ll be happier if you accept that bash can and will happily coexist with anything and everything else, which is exactly why it will never go away.

>it will never go away

Chet Ramey became the primary maintainer of Bash in the early 1990s and is the sole author of every bash update (and Readline) since then. That would be an enormous task for a team of 100, no less a team of one.

I've become quite a fan (after struggling mightily with its seemingly millions of quirks.

Re: Perl's decline was cultural

#257
My problem with PERL was always that there's just too many things to remember, particularly if the code I'm debugging was written by someone who knows the language well. I'd be on a PERL project for awhile, then get pulled off to do Java or Ruby or whatever. By the time I needed to do PERL again, I had to go back and relearn everything. I never had that problem with Java, Ruby, Python, or Javascript.

Also, PERL allows you to write the most unmaintainable code I've ever seen. I ran across a single line of PERL that would read a buffer, do some simple data transformations, add framing information (some of it derived from the data like length, data type, and checksum), and then write out the completed buffer.

It was beautiful. And also completely unmaintainable. Even the guy who wrote it didn't remember how it worked and had to fiddle with it for twenty minutes before he remembered a variable he used was getting set as a side effect of something else later in the line. That's great for a programming contest, but not so much for production code you may be tasking a newly minted software developer with maintaining.

Granted, you can write maintainable PERL code. But over the years the PERL has been hands down the least maintainable in different jobs and projects.

Re: Perl's decline was cultural

#259

Earlier quoted context omitted.

That distinction is indeed critical, and I'm not suggesting removing that distinction. My point is that you could give all those types names, and manage the transition by having Python 3 change the defaults (e.g. that a string is unicode).

I’m a little confused. That’s basically with Python 3 did, right? In py2, “foo” is a string of bytes, and u”foo” is Unicode. In py3, both are Unicode, and bytes() is a string of bytes.

The difference is that the two don't interoperate. You can't import a Python 3 module from Python 2 or vice versa; you have to use completely separate interpreters to run them.

I'm suggesting a model in which one interpreter runs both Python 2 and Python 3, and the underlying types are the same, so you can pass them between the two. You'd have to know that "foo" created in Python 2 is the equivalent of b"foo" created in Python 3, but that's easy enough to deal with.

Re: Perl's decline was cultural

#260

My first and only experience with Perl was like this: in 1997, just for fun, I tried to write a program in Perl to turn my Mozilla bookmarks into a website. After a week of not succeeding, in frustration I decided to try Python. In two days I had what I wanted, and programming it was a joy. That sealed my judgement that Perl (and all of its culture) was not for me, so I'm not surprised at all that others might feel t…

I hope this doesn't come off as argumentative. You said that with Python "In two days I had what I wanted", but another way of looking at it: in a week of not succeeding in Perl plus those two days in Python, you had what you wanted.
Post reply on HN