Live data from Hacker News

Perl's decline was cultural

beatworm.co.uk

411–420 of 472 posts

Re: Perl's decline was cultural

#411

Of course it was cultural. This article covers it all in more detail, but I was coding a lot in this period of Perl's decline, and in hindsight it was all so obvious. I wrote a lot of Perl 3 and Perl 4 to date my experience. Rails was designed to be a luxury hand-holding experience using a language that was intended - as a design goal - to make programming fun. There was even for a while in the late 2000s the culture…

> [..] as a design goal - to make programming fun. There was even for a while in the late 2000s the culture of _why and MINSWAN.

It was a great time - titles like Learn You A Haskell For Great Good and Land of Lisp really capture the zeitgeist.

Re: Perl's decline was cultural

#412
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'm having to pick up some perl now, and while I don't interact with the community, it surely _feels_ like it was written by wizards, for wizards. Obscure, non-intuitive oneliners, syntax that feels like it was intentionally written to be complicated, and a few other things that feel impossible to understand without reading the docs. (Before everyone jumps on me - yes, as a developer, I should be able to read documen…

[dead]

Re: Perl's decline was cultural

#413

Earlier quoted context omitted.

There is zero way you don't alienate anyone. Ask women software engineers if they ever feel alienated. That's the reason why some communities like the python community do outreach for minorities in tech. I'm a white man, and I have never felt "alienated" in so-called progressive spaces.

> outreach for minorities in tech Why is there no outreach to other minorities in tech, like the Amish, for example? They are certainly more underrepresented than women in the python community. Or how about male ballet dancers? Why isn't the python community allocating some of its resources to helping them feel seen and included? I'm giving ridiculous examples because the whole premise is ridiculous. And my general q…

> Why is there no outreach to other minorities in tech, like the Amish, for example? They are certainly more underrepresented than women in the python community.

Well the amish wouldn't want the outreach, because they're amish.

> There are plenty of other outlets more suitable for doing our civic duty.

I kind of hate this mentality, because there's no logic or reasonableness behind it.

There's ALWAYS another place you can do something. Always. Where you draw the line is arbitrary. There's no rulebook anywhere saying we can't do this in tech. That's just your opinion, that you made up. We don't have to do that and, evidently, we don't.

Re: Perl's decline was cultural

#414

Earlier quoted context omitted.

> the last project I encountered in a professional capacity in Python where optional type hinting was used but wasn't always accurate which was a special sort of hell. But that's the entire purpose of optional type hinting. If the hints had to be accurate, you'd have mandatory typing, not optional hinting.

No, optional type hinting means there's sometimes not a hint. Having a hint and then passing some type that's not that is wrong and hell.

Python's type hinting is horrible.

It's not checked, it's not required, and the bolted on syntax is ugly.

Even if the types were checked, they'd still fail at runtime and some code paths wouldn't get exercised.

We need a family of "near-scripting" languages like Go that check everything AOT, but that can be interpreted.

Re: Perl's decline was cultural

#415

Perl's decline was cultural in the same way VMS's decline was. A fantastic approach and ecosystem—just one overtaken by a world that was moving on to a different set of desires and values. PHP emerged as a separate language and community and "ate Perl's lunch" when it came to the dominant growing app style of the Aughties... web pages and apps. Had PHP instead been a Rails-like extension of Perl for the web, sigils w…

VMS decline was bound to a failing hardware business and company. That's a very different thing. Unix was around in the 80s and VMS did fine, its when DEC hardware business went down the tubes VMS lost out big time.

Re: Perl's decline was cultural

#416

Earlier quoted context omitted.

No, optional type hinting means there's sometimes not a hint. Having a hint and then passing some type that's not that is wrong and hell.

Python's type hinting is horrible. It's not checked, it's not required, and the bolted on syntax is ugly. Even if the types were checked, they'd still fail at runtime and some code paths wouldn't get exercised. We need a family of "near-scripting" languages like Go that check everything AOT, but that can be interpreted.

> It's not checked, it's not required,

It is both of those if you use a typechecker, which is the whole reason it exists (in fact, the first popular typechecker existed before the annotation syntax using type comments; type annotations were developed specifically so that it could be accommodated in the language rather than becoming its own separate language.)

Re: Perl's decline was cultural

#417
post #126

Earlier quoted context omitted.

It’s interesting to me how brains work. Perl has always “flowed” for me and made mostly intuitive sense. Every other language I’ve had to hack on to get something done is a struggle for me to fit into some rigid-feeling mental box. I understand I’m the weird one, but man I miss Perl being an acceptable language to pound out a quick program in between “bash script” and “real developer”.

If you’re in the market for fun hackable tool that sits between “bash script” and “real developer” I highly recommend checking out babashka. It lets you write shell scripts with clojure. Babashka itself is a single executable, so no JVM bulk or startup time. And the built-in libs include all sorts of nifty utilities. Parsers, servers, excellent async stuff (but IMO clojure might have the best async story of any langu…

a different approach is to replace bash altogether and switch to modern shells like fish, elvish, murex, nushell (not stable yet afaik) or oils (very interesting approach, it has a bash or sh compatible mode and another one with a more modern and cleaner syntax).

Re: Perl's decline was cultural

#418
Perl was super for little scripts hence it became popular. I think the killer feature was its fantastic regular expression language which beat everything at the time. All other languages had to do to was neutralise that one advantage and they did.

Perl was horrible to build, IMO, and seemed to require 100s of options to be selected which would mean that some script would or would not run with that particular build of Perl depending on what you chose.

Python had a more clunky but still excellent regexp package, it was a doddle to build and most of the things that affected compatibility were things you could install after the python executable was built and installed - i.e. users could get their code to work more reliably.

Re: Perl's decline was cultural

#419

Rather than its "decline was", Perl's existence is cultural. All programming languages (or any thought tools) are reflections and projections of the cognitive values of the community who creates and maintains them. In short, the Perl language shares the structure of the typical Perl dev's mind. A shift to Python or Ruby is fundamentally a shift to a different set of core cognitive patterns. This influences how proble…

>The Pervert's Guide to Computer Programming

That's a rather glamorous piece of discourse, yall aint sleepin

Re: Perl's decline was cultural

#420

Earlier quoted context omitted.

Python's type hinting is horrible. It's not checked, it's not required, and the bolted on syntax is ugly. Even if the types were checked, they'd still fail at runtime and some code paths wouldn't get exercised. We need a family of "near-scripting" languages like Go that check everything AOT, but that can be interpreted.

> It's not checked, it's not required, It is both of those if you use a typechecker, which is the whole reason it exists (in fact, the first popular typechecker existed before the annotation syntax using type comments; type annotations were developed specifically so that it could be accommodated in the language rather than becoming its own separate language.)

That's the problem! The code should not run if the types are wrong. Having an external tool is an antipattern.

Having to rely on process for validity is a recipe for bad. We already know how the greater python community has been with requirements.txt and dependencies. I've spent days fixing this garbage.

It's a tooling problem. Good tools make good habits part of the automation and stop you from having to think about it.

Post reply on HN