zlacker

[parent] [thread] 33 comments
1. pavel_+(OP)[view] [source] 2025-12-06 18:49:46
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 documentation. And I did. But until I did so, what the code was doing was completely opaque to me. That feels like bad language design.)

Some of it I recognize as being an artefact of the time, when conciseness really mattered. But it's still obnoxious in 2025.

The whole thing reminds me of D&D, which is full of classes & spells that only exist in modern D&D because of One Guy who happened to be at the table with Gygax, who really wanted to be a wuxia guy he saw in a movie, or because he really wanted a spell to be applicable for that one night at the table, and now it's hard-coded into the game.

replies(6): >>phil21+c5 >>altair+S5 >>petre+F6 >>tasty_+I8 >>lo_zam+r9 >>kamaal+p01
2. phil21+c5[view] [source] 2025-12-06 19:28:53
>>pavel_+(OP)
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”.

replies(2): >>pavel_+eb >>SoftTa+1Y
3. altair+S5[view] [source] 2025-12-06 19:36:10
>>pavel_+(OP)
> Some of it I recognize as being an artefact of the time, when conciseness really mattered

It was an artefact of bursting out of those constraints, but honoring them still. The roots of perl as a “more capable, less restrictive” sed/awk means that it must support `perl -pi.bak -e oneliner file`, just like sed did — and so from that core requirement forward, everything it did, does. By the heyday of Perl5 era, conciseness was not a requirement, but the sed-compat roots remained a focus of the language’s creator.

4. petre+F6[view] [source] 2025-12-06 19:43:21
>>pavel_+(OP)
Yup, Perl is something clearly out of Unseen University, err I mean Berkeley linguistics dept.

I liked it, thought the sigils were a cute way to singal that something is a variable. When you work with deeply nested data structures, dereferencing arrays and hashes that sort of changes and becomes kind of annoying. Nowadays I like Ruby. Compared to it, Perl does feel like spells mixed with C and Posix stuff. But if I want to feel smart, I'll write some code in Scheme, thank you.

5. tasty_+I8[view] [source] 2025-12-06 20:00:24
>>pavel_+(OP)
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 be relegated to the dustbin. The answer is to write readable code, no matter which language is in use.

replies(3): >>harpia+E9 >>pavel_+Ab >>AlexCo+Z41
6. lo_zam+r9[view] [source] 2025-12-06 20:06:43
>>pavel_+(OP)
The term "surrogate activity" comes to mind, specifically, activities of no real value that some people like to waste time on to feel better about themselves.
replies(1): >>__patc+F11
◧◩
7. harpia+E9[view] [source] [discussion] 2025-12-06 20:08:04
>>tasty_+I8
Seems like the essential criteria is not whether you can write opaque code in it, but rather whether the language enables you to accomplish most tasks using clear, readable code. They aren't mutually exclusive.

Hopefully I am paraphrasing you correctly.

◧◩
8. pavel_+eb[view] [source] [discussion] 2025-12-06 20:23:47
>>phil21+c5
Was Perl one of your first languages by any chance? I freely admit that I've only been poking at it for a few months; maybe by this time next year, I'll be boggled at the comment I left, like it was written by a different person.

> in between “bash script” and “real developer”.

One of my coworkers gave me some great perspective by saying, "at least it's not written in Bash!"

replies(2): >>phil21+0f >>asa400+Df
◧◩
9. pavel_+Ab[view] [source] [discussion] 2025-12-06 20:27:32
>>tasty_+I8
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?

- What's going on with qx, qw, qq?

- What does chomp do when it's just on its own line, with no arguments given to it?

replies(6): >>tasty_+qe >>montro+Je >>Egregi+Tf >>skywho+Ui >>inkyot+WH >>nmz+f51
◧◩◪
10. tasty_+qe[view] [source] [discussion] 2025-12-06 20:54:54
>>pavel_+Ab
Again: python syntax is more akin to what you are used to, and so it feels more comfortable to you.

$_ is inscrutable if you haven't studied perl, but the same thing would happen to anyone who sees a python decorator for the first time. what does "else: do after a while loop in python? Only people who know python know what it does (and I suspect most don't). The different quoting operators are also trivial to learn. In comparison, yield from python is also simple syntax but the semantics are much more involved.

BEGIN? Take 60 seconds to read what it means. And if you knew awk, you'd not have to do that, as it was directly lifted from awk.

replies(2): >>skywho+dj >>BrenBa+Ds
◧◩◪
11. montro+Je[view] [source] [discussion] 2025-12-06 20:57:59
>>pavel_+Ab
Yeah, it's true that Perl did not have as a design goal that a complete newcomer should be able to intuitively understand the code without having any prior exposure to the language. There is a little bit of a learning curve, and that was completely expected by Perl's creators. Yes, you have to learn about the idioms above, but they became second-nature. For many of us, the model clicked in our heads and the terseness was worth it. You could express a lot of functionality in very few characters, and if you had invested in learning, it was very quick to grok because common patterns were reduced to familiar abstractions in the language.

And yet, as the industry grew and all sorts of people from all sorts of backgrounds converged in this space, the tolerance and appetite for funky/terse waned in favor of explicit/verbose/accessible. It's probably for the better in the end, but it did feel a little bit like the mom-and-pop store on the corner that had weird pickled things at the register and a meemaw in the back got replaced by a generic Circle K with a lesser soul.

replies(1): >>asa400+sg
◧◩◪
12. phil21+0f[view] [source] [discussion] 2025-12-06 21:01:43
>>pavel_+eb
Yep, first language I learned. And since I was somewhat early to the Internet thing, I found IRC when I was about 14 years old and actually learned from a lot of the folks who have authored books on Perl or are at least (were) well known in the community.

It certainly was the major factor in how I connected the dots!

Haven’t really thought about it until now, but I suppose having Larry Wall and Randal Schwartz telling you to RTFM guides your early development in a certain manner.

I certainly have never considered myself a developer or programmer though. I can pick up enough syntax to get a quick hack done or start a MVP to demo my ideas, but I leave the “big boy” dev stuff to the professionals who can run circles around me.

replies(1): >>alsetm+rf
◧◩◪◨
13. alsetm+rf[view] [source] [discussion] 2025-12-06 21:05:57
>>phil21+0f
Not the person you replied to, but I thought the same thing. Perl was my first as well, and it certainly shaped the way I think about coding. It made Python feel too rigid and Ruby feel familiar. There's something to be said for the restrictions of an environment when you're learning how to operate in a domain that seems to shape future thinking.

I'm sure there are people who started in a language and later found something that made more sense. I'm just reflecting on what I've found in my experience.

replies(1): >>Andrew+qs
◧◩◪
14. asa400+Df[view] [source] [discussion] 2025-12-06 21:07:36
>>pavel_+eb
> 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.

replies(2): >>skywho+Ji >>BobbyT+P11
◧◩◪
15. Egregi+Tf[view] [source] [discussion] 2025-12-06 21:10:16
>>pavel_+Ab
Honestly, $_ and "what does a function do when I don't supply any arguments?" are really nice in Perl, and not that difficult to understand. I think a lot of languages could use a 'default variable'.
replies(1): >>partom+L51
◧◩◪◨
16. asa400+sg[view] [source] [discussion] 2025-12-06 21:15:54
>>montro+Je
> And yet, as the industry grew and all sorts of people from all sorts of backgrounds converged in this space, the tolerance and appetite for funky/terse waned in favor of explicit/verbose/accessible. It's probably for the better in the end, but it did feel a little bit like the mom-and-pop store on the corner that had weird pickled things at the register and a meemaw in the back got replaced by a generic Circle K with a lesser soul.

This is an amazing point that I haven't seen anyone else make about languages in this way.

As someone who got into the industry right after Perl's heyday and never learned or used it but learned programming from some former Perl power users, Perl has a pre-corporate/anarchic/punk feel about it that is completely opposite to something like Golang that feels like it was developed by a corporation, for a corporation. Perl is wacky, but it feels alive (the language itself, if not the community). By contrast, Golang feels dead, soulless.

◧◩◪◨
17. skywho+Ji[view] [source] [discussion] 2025-12-06 21:36:38
>>asa400+Df
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.
replies(2): >>skydha+5q >>keerna+8I
◧◩◪
18. skywho+Ui[view] [source] [discussion] 2025-12-06 21:38:49
>>pavel_+Ab
You’re mad that you have to look up what keywords do in a programming language you aren’t familiar with? If you think Python is always clear, I can guarantee you (as someone with relatively expert grasp of Bash, Ruby, Go, and once long ago, Perl) that no, it isn’t always obvious.
◧◩◪◨
19. skywho+dj[view] [source] [discussion] 2025-12-06 21:40:54
>>tasty_+qe
Given python’s love for string-leading sigils, the previous commenter should be quite comfortable with the idea of obscure single-letter operators that dictate the interpretation of the following tokens.
◧◩◪◨⬒
20. skydha+5q[view] [source] [discussion] 2025-12-06 22:41:32
>>skywho+Ji
CLI usage revolves around text and bash is a meta layer above that. Given curl, jq, and awk, you can create a quick MVP client for almost any api. Doing the same in Python and Go is much more involved.
◧◩◪◨⬒
21. Andrew+qs[view] [source] [discussion] 2025-12-06 23:03:03
>>alsetm+rf
> There's something to be said for the restrictions of an environment when you're learning how to operate in a domain that seems to shape future thinking.

When at University the academic running the programming language course was adamant the Sapir–Whorf hypothesis applied to programming language. ie language influences the way you think.

replies(2): >>alsetm+NW >>algern+111
◧◩◪◨
22. BrenBa+Ds[view] [source] [discussion] 2025-12-06 23:04:26
>>tasty_+qe
It's not just a matter of "read the docs", though, because languages can differ in how many distinct concepts/constructs they employ. Python has gradually added more over the years but still I think is well short of Perl in this regard.
◧◩◪
23. inkyot+WH[view] [source] [discussion] 2025-12-07 01:18:44
>>pavel_+Ab
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 <file-in in the shell) when no input file name has been specified. So, when no <FILE1> given to chomp, it chomps on the standard input.
◧◩◪◨⬒
24. keerna+8I[view] [source] [discussion] 2025-12-07 01:22:32
>>skywho+Ji
>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.

◧◩◪◨⬒⬓
25. alsetm+NW[view] [source] [discussion] 2025-12-07 04:57:37
>>Andrew+qs
I only recently learned about this, maybe a month ago. It made a lot of sense to me.
◧◩
26. SoftTa+1Y[view] [source] [discussion] 2025-12-07 05:20:35
>>phil21+c5
I think if you were a sysadmin and used to shell scripts, sed, awk, grep and xargs then perl probably made more sense than if you were a programmer from a more traditional language coming into the perl world.
replies(1): >>aorlof+731
27. kamaal+p01[view] [source] 2025-12-07 05:58:51
>>pavel_+(OP)
>>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.

Those days were different. You could say what people are doing in months to years today, in many ways people back then were doing in days to weeks.

Pace and ambition of shipping has not only faded, that very culture is non existent. You don't see people building the next Facebook or Amazon these days, do you?

I remember managers asking Java programmers how much time it would take to get something done, and get timelines on months and years. They would come to us Perl programmers and get it done in a week.

The era didn't last long. I would joke around our team saying, ideally a Java programmer with 10 years experience was somewhat like like a Perl programmer with 1 year experience. This was one of the big reasons, most of these enterprise coders wanted Perl gone.

◧◩◪◨⬒⬓
28. algern+111[view] [source] [discussion] 2025-12-07 06:07:48
>>Andrew+qs
Seems somewhat related to Iverson's 1979 Turing Award lecture, "Notation as a Tool of Thought" (https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.p...)(>>25249563 )
◧◩
29. __patc+F11[view] [source] [discussion] 2025-12-07 06:18:48
>>lo_zam+r9
People summit Qomolangma. (with logistics)
◧◩◪◨
30. BobbyT+P11[view] [source] [discussion] 2025-12-07 06:21:25
>>asa400+Df
Indeed. If I had to download and install bash … I wouldn’t!

I write bash scripts only because I can rely on it being there.

◧◩◪
31. aorlof+731[view] [source] [discussion] 2025-12-07 06:39:17
>>SoftTa+1Y
If I am familiar with sed, awk, grep and xargs, was I a sysadmin ?
◧◩
32. AlexCo+Z41[view] [source] [discussion] 2025-12-07 07:01:34
>>tasty_+I8
When I was choosing between learning python and perl in the late 90's, it was the context sensitivity of perl expressions which really squicked me. To me, that was the critically bad language decision in perl. You can make context-sensitive expressions in python (using operator overloading, for instance), but you have to go out of your way to do it in one way or another. In perl you can easily do it by accident, and it can result in serious bugs. It seemed masochistic, to me.
◧◩◪
33. nmz+f51[view] [source] [discussion] 2025-12-07 07:05:08
>>pavel_+Ab
If you think that's bad, try learning python or a verbose language while not speaking english, all of these words like while, for, if, else, break are just gibberish and your code just reeks of some weird mish mash of broken english and broken <mother tongue>, I have a hypothesis that terseness favors universality, if you don't speak english, something like $_ is equal or easier to grasp, it honestly just looks like terse and weird math.
◧◩◪◨
34. partom+L51[view] [source] [discussion] 2025-12-07 07:12:38
>>Egregi+Tf
$_ was one of the things that put me off perl, because the same syntax meant different things depending on context.

The Pragmatic Programmers had just started praising Ruby, so I opted for the that over Perl, and just went with it ever since. Hated PHP and didn't like Python's whitespace thing. I never Ruby on Rails'd either. That said my first interactive website was effectively a hello world button with cgi/perl.

But trying to learn to code from reading other peoples perl scripts was way harder than the (then) newer language alternatives.

Now I'm over 50 none of that is nearly as important. I remember being young and strongly opininated, this vs. that - its just part of the journey, and the culture. It also explains the current FizzBuzz in CSS minimisation post. We do because we can, not necessarily because we should.

[go to top]