Hacker News Reader

Comment by adamnemecek | Hacker News Reader

I'm not surprised that the language is dying. They seem to be spending time on things no one cares about and things that are inconsequential.

View on HN

Could it be that the Perl language (and especially Perl 5) but as a community in general, is established and mature, and very stable, that the only things that are mentioned are just not the things that newer, fast moving languages such as Rust and Go talk about? I don't think that the naming situation is trivial, I really think it has had a negative effect on both Perl 5 and Perl 6.

>Could it be that the Perl language (and especially Perl 5) but as a community in general, is established and mature, and very stable

No, it's also declining. If not for anything else, because most younger devs won't touch it (either 5 or 6).

This is by far the most important thing they could be doing right now. It should have been done 10-15 years ago, and is arguably the dominant remaining reason for why the work done on both Perls since Perl 6 has failed to payoff the way it should have.

There is a certain contingent of developers who should have been all over Perl 6 and very excited about it. We should have been seeing the stream of "$COMMON_LIBRARY but in Perl 6!" postings on HN for a couple of years, along with the blog posts of "look how crap this is to write in $OTHER_LANGUAGE but with this bit here and there look at how slick the Perl 6 solution is!" every couple of weeks. We should be seeing blog posts about the joys of working in a language with built-in grammar support replacing the old ad-hoc regex support, and how well it integrates with the rest of the features. We should have even eventually seen the contrarian backlash posts about how much of a mess you can make if you overload all your operators and grammar constructs and use all the features at once in an ill-advised manner, followed by comment thread semi-flamewars about whether bad code is the fault of the programmer or the language.

But we didn't.

Bias disclosure: I actually have no interest in Perl 6, so this isn't advocacy. Anything I've ever seen that Perl 6 looks interesting to me (emphasis) for, I'd rather just use Haskell, which I've already learned and actually does quite a lot of what Perl 6 does. But Perl 6 does it without being a immutable functional programming language, making this all a lot more accessible to a lot of programmers. I'm not saying I'm interested in Perl 6; I'm saying, there is definitely a chunk of programmers who should have been interested in it who are not.

And from what I can see, this naming confusion is one of the major reasons.

(One other one I would point to is the Perl 6 community's multi-year "joke" that Perl 6 would be released "next Christmas", which nobody outside of the Perl 6 community found even slightly funny, instead creating a reputation for the community that overpromises and underdelivers; that a few people would swoop in to those conversations to actually mock people who weren't insiders enough to know it was a joke and not a real promise, which is to say, 99.9999999% of humanity (that is not random nines; that is all but ~700 people; take one off if you like), really didn't help. I put "remaining reason" in my first paragraph because this has been resolved for many years now. But I can tell you that this significantly diminished my own personal interest, and I'm sure I'm not alone.

Finally, I'd point to it just never being done, but, arguably, that alone couldn't have killed it. There's plenty of languages that grow quite substantially over time; the Python of when Python first really got popular and the Python of today are very different, for instance. Had more people been interested and pushing for something usable $TODAY, with more work being done later, this probably wouldn't have been as big a deal.)

I've found over the past 6 years that anything nice about Perl is negated by how hard it is to think of the right way to do something from among the 30 different ways. And it makes it difficult to write maintainable code because there are no good ways to constrain the input domain of functions.

I also don't think it's a good thing that the language has idioms. In a human language idiomatic expressions are a barrier to learners, and it's the same with Perl. The context-sensitivity of expressions is also a huge barrier to maintainability because it's impossible to know from looking at the code what the acceptable contexts are for a variable. You basically have to keep track of the state of a variable separately if you want to avoid usage errors.

Finally, the fact that Perl users consider the arcane-ness of Perl to be a good thing is the last nail in the coffin for me.

While it's true in human language that idiomatic expressions are a barrier to learners, they are also a means of enhancing communication between experienced users of the language. Take Jargon for example, I've not got deep experience in functional programming, category theory, or discrete mathematics (really anything much higher than college stats), so the phrase "constrain the input domain of functions" set me scratching my head a little. I'm still not exactly sure what you meant by it.

However, it's one of those phrases that I'm sure is immediately clear to your intended audience. One who has experience and understands that monads are simply endofuctors that map between two category spaces (I think I got that right, and if I didn't the main point was illustrated anyway). As a person gains experience their language usage become much more intentional and expressive. Idiomatic language is really only this expression of experience and an effort to communicate the full context and nuance as succinctly as possible.

The best Perl developers I know understand this and what you see as praise for arcane-ness is usually in my opinion just embracing the idea that jargon and idiomatic language is inescapable, and should be just another tool in the toolbox for expressive writing.

Also Perl does some weird shit, and sometimes you gotta hack around that.

> While it's true in human language that idiomatic expressions are a barrier to learners, they are also a means of enhancing communication between experienced users of the language.

Except that this is a computer language. Computer languages don't have nearly the same range as a human language, and there are very specific formal rules to be followed. If I want to I can speak English without any idioms. Another difference between computer language and human language is that there is a huge amount of duplicated information in a human language, whereas a computer language like Perl is designed to be as terse as possible. So if I want to know what an idiom means in English, I can A) ask the speaker what they meant by it, B) infer what it means based on the context in which it was spoken which includes the time and place and the situation, or C) look it up on the internet.

In a computer language, A requires either direct access to the language designer, code comments, or dialogue with the user of the idiom. B requires context information, which is simply not present. There is no situational analogue to the scene and people involved in an English conversation. You're conversing with a compiler. C is made difficult by the terseness of the syntax. So really having idioms in a computer language doesn't work at all without having someone to decode those idioms for you. And in the end if we all have to decode idioms then we should just make the meaning explicit in the code. If you have too many idioms then your code becomes unreadable without some kind of codex.

> The best Perl developers I know understand this and what you see as praise for arcane-ness is usually in my opinion just embracing the idea that jargon and idiomatic language is inescapable, and should be just another tool in the toolbox for expressive writing.

While I think we can agree that Thomas Pynchon is a highly expressive writer, I also think we can agree that he is very obtuse at times. It's fun if you get it, but it's infuriating if you don't. There's a difference between being expressive and having so many facilities that casual users of the language can't remember how to do simple things because there's just so much syntax to learn and so few mnemonics with which to do so.

I believe Perl 5's decline and Perl 6's failure to catch on is evidence of the failure of their common underlying TMTOWTDI philosophy, which encourages write-only "creative snowflake" Perl code that's an inscrutable, unreadable, unmaintainable nightmare. (The sigil-heavy line-noise syntax sure doesn't help, either.)

https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...

http://wiki.c2.com/?ThereIsMoreThanOneWayToDoIt

While I believe Python's continuing success is evidence supporting the truth of its Zen of Python philosophy: "There should be one — and preferably only one — obvious way to do it."

https://www.python.org/dev/peps/pep-0020/

So I basically agree with you & jschwartzi. But to expand or reinforce my original point, it is very clear there is a substantial contingent of programmers who do not. While of course in my own opinion, my own opinion is correct (duh), at a more global level, or maybe in a more academic sense, I'm open to the possibility that I'm wrong. I've already flopped on that matter once in my career and I reserve the right to be convinced by another language that I'm wrong now, too.

You don't have to be "wrong". You just have to be not exactly the same as everybody else. And of course, nobody is exactly the same as everybody else, therefore there is not possible for there to be such a thing as The One Perfect Language. The right tool for the job; but also the right tool for the workman.

The idea that there's only one way implies that code context means nothing.

For example, if you have a simple function that kicks backed cached values:

  sub foo ($bar) {
    if %cache{$bar}.defined {
      return %cache{$bar}
    }
  }

Is an absolutely correct way of doing things. But it's messier then using a postfix:

  sub foo ($bar) {
    return %cache{$bar} if %cache{$bar}.defined
  }

Or simplifying:

  sub foo ($bar) {
    return $_ with %cache{$bar}
  }

While it's true that

  sub foo ($bar) {
    .return with %cache{$bar}
  }

is possible, I don't tend to use it too much because the dot syntax isn't as pretty with postfixes ha. But each of these options has a place where it is the better option, but none of them is universally the one and only best option. Nested ifs with multiple statements may go better with the first one, but if several conditionals have similar elements and are simple statements it might behoove to line them up with whitespace. But the placement of return right at the outset (as opposed to nestled in an if statement) to me makes it clear the return value is a gate-keeper of sorts. Ditto for using 'die if [cond]' which much more in your face then 'if [cond] {die}'.

All of the above code is readable though. Of course, a functional approach could be just as valid and readable, and clear:

  multi sub foo ($bar where %cache{$bar}.defined)

{ %cache{$bar} } multi sub foo ($bar) { ... }

Or taking advantage of traits:

  sub foo ($bar) is cached { ... }

Almost inevitably the unreadable code is where someone is trying intentionally to be cute and write unreadable code. But that can be done in languages like C too, or with any language that allows single letter variables.

>"There should be one — and preferably only one — obvious way to do it."

Which Python manages to break all the time. How many ways are there to format a string again?

Any examples?

the name is the example

Reply on news.ycombinator.com