Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl's decline was cultural

beatworm.co.uk

Post reply on HN
Print view View original

81–90 of 472 posts

Re: Perl's decline was cultural

#81

Post by eduction »

eduction wrote: post #65
tguvot wrote: post #14

I spent year developing CMS in Perl in 1999 (HTA application with ActivePerl. wonder if anybody else did something like this). It traumatized me, and first thing that I did in my next job is to learn python and develop some core systems in it. Few of my friends moved from perl to python as well. I still remember spending time with my coworkers on bench outside of building trying to figure out #@$%$^&$%@something = []…

Perl heads are downvoting you but I agree as a longtime ex Perl user that the sigils were noisy nonsense. The original intent was you could see var types with them - $scalar, @array, %hash. They immediately broke this by deciding the sigil would apply to the value /extracted/ from the data structure. So you declared array @foo but accessed an element as $foo[1]. What? There’s a logic there but already you’re violatin…

Oops last example should be $hash1->{“hash2”} - this is a whole hash referenced with $ because of the implementation detail that it is in hash1 as a reference, which is considered a scalar.

Technically you are allowed to use % like so: %{$hash1->{“hash2”}}. Which, just - lol.

Re: Perl's decline was cultural

#82

Post by [deleted] »

jordanb wrote: 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.

[deleted]

Re: Perl's decline was cultural

#83

Post by Insanity »

jordanb wrote: 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.

I don’t know about the wider Perl community, but I listened to some interviews from Larry Wall and he just came across as a nerdy guy having fun with what he’s doing. I quite liked listening to him.

Re: Perl's decline was cultural

#84

Post by DonHopkins »

mschuster91 wrote: post #69
cwyers wrote: post #60

Earlier quoted context omitted.

I was surprised by that, too, and assumed it was a decade-old article until I saw the date at the bottom. Both being mentioned before Python is wilder, as is the total exclusion of JavaScript.

JavaScript on the backend is a rare thing to see, even in "resume driven development" scenarios it's usually some sort of static build that gets pushed to S3 or whatever.

Are you time traveling from 1998, when AOL acquired Netscape and sidelined Livewire?

Re: Perl's decline was cultural

#85

Post by creer »

pavel_lishin wrote: post #72
nine_k wrote: post #29

Earlier quoted context omitted.

Perl is a great language, the way Scala and Haskell are great: as openly experimental languages, they tried interesting, unorthodox approaches, with varied success. "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say. Perl is not that good a language though for practical purposes. The same way, a breadboard contraption is not what you want to ship as your hardware pro…

> "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say. Perl lets every developer write Perl in their own idiosyncratic way. And every developer does. It makes for very un-fun times when I'm having to read a file that's been authored by ten developers over ten years, each of whom with varying opinions and skill levels. I guess in 2026, it'll be 11 developers writing it…

> in 2026, it'll be 11 developers writing it over 11 years.

Perhaps too, a tool that's been around and in active maintenance for 11 years has been wildly successful.

Re: Perl's decline was cultural

#86

Post by creer »

atherton94027 wrote: post #17
mmastrac wrote: 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.

There was so much complexity hidden behind "do what I mean". For example, scalar vs array context which was super subtle: my @var = @array # copy the array my $var = @array # return the count of elements in array

What exactly is complex or "super subtle" about this? It's the textbook example from the 1st chapter in the tutorial or something?

Re: Perl's decline was cultural

#87

Post by IshKebab »

DonHopkins wrote: post #78
lysace wrote: post #31

Earlier quoted context omitted.

[flagged]

We don't have to say such things, because the syntactic sirup of ipecac and sputtering line noise of perl code speaks for itself.

Clearly not loudly enough - look at all the people here searching for some mysterious cultural reason it failed.

Re: Perl's decline was cultural

#89

Post by tguvot »

eduction wrote: post #65
tguvot wrote: post #14

I spent year developing CMS in Perl in 1999 (HTA application with ActivePerl. wonder if anybody else did something like this). It traumatized me, and first thing that I did in my next job is to learn python and develop some core systems in it. Few of my friends moved from perl to python as well. I still remember spending time with my coworkers on bench outside of building trying to figure out #@$%$^&$%@something = []…

Perl heads are downvoting you but I agree as a longtime ex Perl user that the sigils were noisy nonsense. The original intent was you could see var types with them - $scalar, @array, %hash. They immediately broke this by deciding the sigil would apply to the value /extracted/ from the data structure. So you declared array @foo but accessed an element as $foo[1]. What? There’s a logic there but already you’re violatin…

Before that job in perl i wrote asm/tcl/delphi/c/php (and bunch of other languages after).

This perl syntax caused some kind of rejection on almost physical level. It was same for many of my friends. "Zen of python" was a breath of fresh air.

Re: Perl's decline was cultural

#90

Post by zahlman »

superkuh wrote: post #40
cedilla wrote: 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…

> Most likely you'll have to use a venv or the like and setup a special version of python just for that application.

Using venvs is trivial (and orders of magnitude more lightweight than a container). And virtually every popular package has a policy of supporting at least all currently supported Python versions with each new release.

You need to set up a venv because of how the language is designed, and how it has always worked since the beginning. Python doesn't accommodate multiple versions of a package in the same runtime environment, full stop. The syntax doesn't provide for version numbers on imports. Imports are cached by symbolic name and everyone is explicitly expected to rely on this for program correctness (i.e., your library can have global state and the client will get a singleton module object). People just didn't notice/care because the entire "ecosystem" concept didn't exist yet.

I have at least one local from-source build of every Python from 3.3-3.14 inclusive (plus 2.7); it's easy to do. But I have them explicitly for testing, not because using someone else's project forces me to. The ecosystem is just not like that unless perhaps you are specifically using some sort of PyTorch/CUDA/Tensorflow related stack.

> It's the standard now because system Python can't do it.

Your system Python absolutely can have packages installed into it. The restrictions are because your Linux distro wants to be able to manage the system environment. The system package manager shouldn't have to grok files that it didn't put there, and system tools shouldn't have to risk picking up a dependency you put there. Please read https://peps.python.org/pep-0668/, especially the motivation and rationale sections.

> major breakages in point version upgrades

I can think of exactly one (`async` becoming a keyword, breaking Tensorflow that was using it as a parameter name). And they responded to that by introducing the concept of soft keywords. Beyond that, it's just not a thing for your code to become syntactically invalid or to change in semantics because of a 3.x point version change. It's just the standard library that has changes or removals. You can trivially fix this by vendoring the old code.

Post reply on HN