Hacker News Reader

Comment by izietto | Hacker News Reader

Personally, I find it very readable. My only criticism is that its syntax looks "weird" nowadays. I mean, a newborn language would never go with `my` as local variables declaration prefix, or `->` for object method call, or `sub` for function declaration. I think Perl would benefit of a transpiling approach, like what Elixir is to Erlang.

View on HN

This is I think in large part that Larry Wall[0] is a linguist and I think this influenced both Perl and its descendant Raku[1]. Thats why it has this almost natural-ish looking syntax in alot of ways, and relies on symbolism. I also think this is why Perl is legendary for regular expressions

[0]: https://en.wikipedia.org/wiki/Larry_Wall

[1]: https://www.raku.org/

Ironically these features make Perl feel very far from natural language, much moreso than other programming languages, even some symbol-heavy ones like Java. It feels more like IPA pronunciation notation than anything naturally derived. Raku I can't speak for because I haven't used it beyond "hello world", but it has a huge pile of symbolic infix operators in the standard library and that makes me squirm, because it's probably my most-disliked Haskell feature and IMO a substantial design mistake.

I dislike same thing in Rust and it is much worse on that.

Bit of nitpicking: This is, because `my` doesn't declare a local variable (you do this with `local`), but a lexically private variable, which is something different. Expressing that something "belongs" to a private scope by `my` isn't much weirder than, say, referring to an object in its own context as `me`, as seen in HyperTalk.

> Personally, I find it very readable.

A lot of Perl can be readable. But sometimes you get a backend where someone with , let's say, a "unique" view of software development writes a huge monolithic monstrosity by creating their own ORM and object model with almost zero documentation in or out of the code and hoo boy, that is not going to be a fun time 10 years later when basically nothing has changed because no-one has the time or energy to parse out what they've "crafted".

I'll never understand this Perl readability sentiment.

Any time I've ever tried to look into <insert random open source C project>, I typically find the most esoteric and tersely named functions inhumanly imaginable. Variables like gt, pn, r8, _on, etc. I mean terse to a point of cruelty. And yet these projects often have hundreds of contributors who are happy to gloss over said unreadability, or at least forgive it more than Perl.

You can write unreadable code in any language, and I also find complaints about about perl being unreadable unfair, but I have to admit that it does give you so much freedom that it's easier to end up with poorly written code than it is in some other languages. When I need to throw something quick and dirty together I love that freedom, but you do have to apply some self-discipline when you move to something more complex since it isn't imposed on you all the time.

It may happen when one directly translates into code an algorithm, a concept, or a formula from mathematics, physics, or computer science theory, where all the symbols are terse, you're supposed to have read a hefty book or stack of papers where those are introduced, and the author laments the demise of APL with all the nifty symbols it had.

Oh, and you're fully expected to speak their argot fluently, of course, otherwise you're a castaway to be thrown stones at.

> A lot of Perl can be readable. But sometimes you get a backend where someone with , let's say, a "unique" view of software development writes

I agree. Perhaps Perl culture encouraged that kinds of development. But I've a seen number of monstrosities in other, better known languages that are "crafted" that way as well. I'm currently working with a large commercial product in C that would undoubtedly be easier for the 50-strong team of devs to work with if it was written in Perl (though they would still complain), and ironically it would probably run faster in Perl too (and be much more secure).

I don't think the problem is the language really, as Perl can be written in a modular and fairly clean way too (compared with many other languages) if the developers are minded to. I think it's the culture in which those large projects were developed. Or rather, the lack of software engineering culture for long-term maintanence, and a disinclination to use frameworks and patterns that would be familiar to new developers coming in later, especially from other environments. It may be that Perl's rise and fall was a product of its timing relative to software-at-scale culture as much as anything.

Despite its origins as a glue language, Perl 5 is a Lisp-like once you see past the syntax. Perhaps that's part of its problem: Lisp encourages creative and unique approaches to large projects too, and also isn't widely used any more.

> I think it's the culture in which those large projects were developed.

Definitely you can keep your Perl under control with a strict(ish) culture but that tends to be the kind of culture Perl acolytes traditionally chafe against. I do somewhat blame the "there's more than one way to do it" Perl culture - that definitely encourages a, uh, "cowboy" approach to development that I've seen a lot in Perl houses (compared with, e.g., the Go houses that I now deal with because Go has a definite "one way to do it" culture.)

But yeah, pretty much any language can be twisted into a monstrosity if you let the devs run wild.

The mistake was to think Perl was suitable for those types of applications in the first place. Perl was designed for writing small scripts to glue C programs together in a more convenient way than using shell scripts and AWK. A lot of its idiosyncratic design decisions make sense in that context. But when Perl advocates starting pushing it for writing large applications with OOP (with, of course, multiple competing object systems) it was the beginning of the end. Add in the vapourware that was Perl 6 and it was game over.

... You worked with POOF too? https://metacpan.org/pod/POOF

Maintaining that in house codebase that used it was such a pain. I had to help keep that ORM up to date with the new data models after the acquisition.

Nope, not POOF. From what I can see, it didn't make it to CPAN because it was entirely in-house work (and/or was too horrible even for there.)

Reply on news.ycombinator.com