Hacker News Reader

Comment by jannotti | Hacker News Reader

Oh man. I don't know what to say. In the process of trying to bust myths, this confirmed every practical concern that the "myths" actually express.

Perhaps the worst was: "Myth: Perl 6 will never be finished"

The author of this actually tried to argue against that "myth" by saying, "Perl 6 is defined as a set of test cases." and goes on to say that since the tests were written long ago Perl 6 is done, and has been since like, forever.

If that's the level of "Well, actually..." that this community uses, you can see why they've become irrelevant.

I LOVED Perl.

View on HN

The Rakudo compiler targeting MoarVM is also "finished" in the sense I expect it would take you a while to find something not implemented from the spec. More advanced things like concurrency and parallelism features are ready, and there are even nice things built out of them like the Cro microservices framework https://cro.services/. You can also build applications with Cro using full integration with a JetBrains based IDE https://commaide.com/, which feels like a level of maturity and support someone might expect of a finished product? Thats the real myth, is someone can read this article and still not realise Perl 6 is an entirely useful and complete language with a good implementation and nice tooling.

Then the article should say that, not just say that the Platonic ideal of Perl 6 is well-defined in the writings of the prophet Larry.

... but still dog slow. Sorry, it matters.

Ruby is reasonably fast now, but when it became popular it still was very slow. So while speed definitely matters, maybe its lack is not an insurmountable obstacle.

The competition is a lot hotter these days.

Is it? It seems like the scripting language world is incredibly stagnant these days. Can you name an "up-and-coming" scripting language?

Maybe that's because scripting languages are a bad idea for anything performance critical anyway - and experience has shown that even if things are not performance critical initially, they might become eventually.

So why would you write anything in a scripting language only to rewrite it later in a compiled langue, if you could have used an equally capable compiled language in the first place?

Time to market.

Performance just isn’t the only, or always the most important factor when choosing a language. Sometimes we choose a language and it’s ecosystem for factors we know we value right now, rather than ones we might value later on.

> Maybe that's because scripting languages are a bad idea for anything performance critical anyway

This is an example of how programming as a discipline and activity is consistently dismissed by the software community as an unnecessary contrivance. "What about absolute performance?" But the reality is you're making tons of those tradeoffs. You're using a compiler, on an instruction set designed for humans, leaning on network stacks that do work for you in generic but sub-optimal ways, using container systems that introduce huge performance penalties.

Those are socially acceptable to you. They're special in that you think they aren't special.

> So why would you write anything in a scripting language only to rewrite it later in a compiled langue, if you could have used an equally capable compiled language in the first place?

This assumes they are in fact equally capable. Please don't retort with Turing completeness. That's a copout and we all know you aren't about to go shipping things in BF.

Or they go the other way, after an initial assumption that the task was performance-critical when in fact a scripting language was perfectly capable and took 1/10 the effort to write.

https://opensource.com/article/18/1/my-delorean-runs-perl

Elixir?

Anyway, I'd argue competition is tougher not because there are more competitors (there might be, I don't know) but because they have advanced.

Compared to 15 years ago, Python has gained a lot of stuff, JavaScript has become an ok language with very fast implementations, there's a dozen funcional scripting languages targeting browsers, optional typing has made a comeback, Ruby has native threads and a decent vm and a large ecosystem, Go is a valid solution for things were you might have used a scripting language, lua owns the embedded space and luajit is the state of the art etc.

In 1998 it was enough to have closures and objects to be a potential perl replacement.

Python has gained barely anything at the interpreter and language level, tho?

Mmh, depends on when you start to count. I still consider 1.5.2 the gold standard for Python -- but I am weird. :) Anyway, since then it has gained new-style classes (which gave explicit methods to things like strings, tuples and numbers), list comprehensions, generators (which also gained some changes over time like 'yield from'), generator comprehensions, built-in sets with new syntax, dictionary comprehensions, decorators, descriptors, properties, context managers and the 'with' keyword, absolute vs relative imports (again with new syntax), import hooks, a boolean type, extended slices, a ternary if, ordered dictionaries, async/await, extended tuple/list unpacking, the @ operator, several new ways of string formatting, ... And of course 3.x brought major changes to the way Unicode was handled. Never mind those, um, interesting type hints and the upcoming := operator.

Python as it is now, is a very different language than it was in those days. Even ignoring the whole ecosystem with libraries and package management etc, and standard library changes, it's just a much bigger language.

In 1998 you would definitely need closures and objects to replace Perl, since Perl has had both since 1994.

I was using closures to great effect in Perl before I even knew what a closure was. (Are closures supposed to be a difficult or extraordinary feature?)

I really find it funny when other languages do things that Perl has already been doing for years.

Go2 is basically copying the way Perl5 has been advancing without breaking backward compatibility. (They don't seem to realize this.) JavaScript copied use strict. PowerShell copied $_. Everybody copied Perl extensions to regular expressions. (I can't wait for them to copy the cleaned-up, easier and more powerful Perl6 regular expression syntax.)

Every feature that I've heard that Python3 changes directly correlates with a similar change that has happened in Perl5. (Only Perl5 has done them in a way to reduce breaking your old code.)

Those are just a few of the the ones I know of.

Perl has been a far more influential language than anyone gives it credit for. Though that is probably because they just use the feature without knowing the history of it. Eventually Perl6 will be just as influential.

---

I agree that optional typing is good, I use it everyday in Perl6. (And have been for nearly ten years.)

You misunderstood me: I mentioned closures and objects as something perl had, which were also one of the selling points of ruby and python at the time, which would be considered competitors to perl.

The example was meant to show the "minimum" needed to be an interesting scripting language.

Edit: I love perl. I love perl6. I hope languages get inspired from it.

Scripting languages were to the 200x's what visual 4GL's were to the 1990's, i.e. a whole bunch of them came and went, and only a few gained mass adoption, perhaps 4GL's Visual Basic and Delphi, and scripting languages Javascript and Python. The rest are dead, or slowly dying.

Red, sort of kind of.

I have been thinking that there might be room nowadays for a new language that is unabashedly a "scripting language"... something you can easily write scripts with, but which doesn't necessarily aspire to scale real far beyond that, so people will not immediately reach for it to write, say, 250K-line web applications. :3 (Then again, if a language is good/useful/flexible enough, people will use it for everything.)

Anyway, I would like to see such a language. The old stalwarts will probably still work just fine for this purpose, but I am curious to see if there's any innovation left/possible in this particular space.

I have one I'd _like_ to see in a very limited domain: Dhall.

Dhall is amazing. But it's domain is very limited.

Julia

Is it a scripting language? I suppose so!

Good answer!

Well, it's both really. That's what makes it special.

All of the popular interpreted languages we use now were dog slow when they originally came out and we still had to deal with many the quirks of low level languages back then but here we are. If you don't like it just don't use it.

This really depends on the task in question and which languages you were comparing it to. Back in the day it was fairly common to have Perl, PHP, Python, etc. outperform languages like C in cases where the task complexity meant that the C programmer had been so busy debugging that they never got around to implementing a better algorithm which required more complex code, or it turned out that the C code behind the Perl regex engine, Python list/dict, etc. already had those optimizations. Java and C++ were compiled but back then the implementations were far less mature and it was easy to find cases where they underperformed in cases which should have been easy on paper. Not having a package manager really favored languages with one or a strong standard library since the alternative was often someone doing a quick naive implementation and never getting around to significant optimizations. The other thing to remember is that in the pre-SSD era it was much easier to be I/O-bound, masking most of the differences.

Someone once posted Perl6 and C/C++ code to #perl6 on freenode.net

According to them, Perl6 was faster.

(The Perl6 code was also a lot shorter, and I could argue it was easier to understand.)

---

My guess is that the reason was that the C/C++ code had to scan for null terminators often, and copy strings around. (Or perhaps more precisely the stdlib had to do that.)

MoarVM doesn't use null terminated strings, and it treats strings as immutable objects. If you do something like create a substring, it creates a substring object that points into the original string. So rather than copying a bunch of data it basically just creates a pointer.

(Strings are technically immutable in Perl6, it is easy to assume otherwise though.)

Compared to Python? They're like, comparable no?

Depends: Some things can still be really (and I mean really) slow. For example, I've been complaining about the speed of the regex/grammar engine for years.

On the upside, the parallelism story is better than Python's or Perl5's.

> Oh man. I don't know what to say. In the process of trying to bust myths, this confirmed every practical concern that the "myths" actually express.

I think this is part of the joke.

My favourite was “Myth: Perl6 is slow” “Reality: Look at all these open performance tickets!”

Many of those are because one way to write the code is slower than another way to write it.

So it is more about the speed not being evenly distributed.

Based on the rest of the blog, I can't actually tell if this is tongue-in-cheek or not...

It's very poorly written satire if so. You can't point out the absurdity of something by repeatedly arguing that it's not absurd. The point about Chinese characters being unfamiliar to readers of Latin alphabets is a good one, for instance. It would be like Dilbert having a week where the pointy-haired boss's apparent nonsense is actually good management practice that Dilbert has been misunderstanding: it would neither be funny nor effectively educational.

He replied to me on twitter, it’s not supposed to be a satire

https://twitter.com/aearnus/status/1147960078680485889?s=21

Thanks for the clarification.

This all reminds me of Poe's law

> https://en.wikipedia.org/w/index.php?title=Poe%27s_law&oldid...

"[W]ithout a clear indicator of the author's intent, it is impossible to create a parody of extreme views so obviously exaggerated that it cannot be mistaken by some readers for a sincere expression of the parodied views."

> I LOVED Perl.

Perl isn't going anywhere. It is under active development.

One unfortunate thing about naming the sister language Perl 6 is that it tends to indicate that it is the Next Perl (like Python 2 vs 3). But it is not, Perl 5 is a very different language (and I wonder if at some point Perl 5 will switch to Perl 7.x just for the fun of it).

> One unfortunate thing about naming the sister language Perl 6 is that it tends to indicate that it is the Next Perl...

This is a fair and it's one of the reason why Larry Wall created the alias Raku.

But let's entertain for a moment that there wasn't even an alias for the language. I'm sure we both agree that for a person who comes across the names Perl 5 and Perl 6, the latter seems to indicate that it's the next version of the former. In fact, this is totally excusable. After all, why should the person assume they're different languages and disregard what seems to be a logical conclusion? 6 is immediately after 5 and it suggests some sort of progression. Thus, it was on the community to make it clear and unambiguous to newcomers but I'd daresay it failed at that. Raku is an attempt at correcting that blunder but who can say it will succeed in that area?

Now...

Would it be logical for the same person to rehash the same "assumption" after they already learned about it regardless of the context of the conversation? If you've (you in general) learned that Perl 5 and Perl 6 are different languages, what's the merit behind pointing out the obvious? Again, I'm referring to people who, for one reason or another, already know they're both different languages yet still are set to bring out, whenever the opportunity arises, the same and old "naming" debacle as a reason for people to avoid/bash either Perl 5 and/or Perl 6

When I first heard about C++, I myself was confused on whether it was the next and better version of C. However, it just took me an internet search to realize that C++ and C are two distinct languages. Afterwards, I haven't confused the two anymore. One might certainly argue that version numbers are different to use of operators (specifically, ++) but who decides that? For me, the ++ in front of a language's name implies the same type of progression 6 does over 5.

> "Perl 6 is defined as a set of test cases." ... "Perl 6 is done"

Quoting Larry Wall from 2000:

> [we should] develop the real regression tests into a validation test of what the language actually means and actually go out and explore all the nooks and crannies ... and then we actually have a machine-readable spec. And to me that’s actually a lot more important than what the verbiage on the human readable thing says.

The first implementation of this concept was released in 2016 as version 6.c. Then 6.d in 2018.

P6 will never be "done" but 6.c and a compiler for it was/is done, similarly 6.d, while 6.e is at an early work-in-progress stage.

Quoting Larry Wall from 2000

If you're going to quote Larry Wall from 2000, be honest and also quote him as saying he wanted to release a beta by TPC 2001 and get the final version out by 2002. Don't mislead people by cherry-picking quotes out of context to gaslight them.

That is, assuming you want to be an honest, good faith advocate.

Hi chromatic. I'm not going to engage with you beyond this comment.

----

To all readers,

Imo the issue of a time line (estimated or actual) is immaterial to the original point made up thread (the role of tests in determining a compiler's compliance to a language specification).

But I've decided to reply to chromatic's comment.

With luck chromatic and perhaps others will reply with substance and the result will be a useful HN record about the original P6 time line estimates. I apologize in advance for any further trolling or disconcerting further tangents my comment generates.

Besides quoting chromatic, all text I quote using `>` or "quoting" comes from sources I've linked in footnotes.

----

> If you're going to quote Larry Wall from 2000, be honest and also quote him as saying he wanted to release a beta by TPC 2001 and get the final version out by 2002.

The Perl 6 announcement, which is what I was quoting, doesn't mention these things. [1]

You were, as you tirelessly emphasize, physically in the thick of things, while I was merely reading things online as I found them, roughly contemporaneously with their publication, and then again in recent years. So feel free to provide your own quotes and links.

----

In the meantime, here's what Larry said about time lines in that initial speech:

> We are really jazzed about this. It is our belief that if Perl culture is designed right, Perl will be able to evolve into the language we need 20 years from now. It’s also our belief that only a radical rethinking of both the Perl language and its implementation can energize the community in the long run. In the long run means 10 and 20 years down the road. Finally, it is our belief that Perl 5 will be better supported than it would be if we merely tried to guard what we already have. The best defense is a good offense. Now, this is not going to happen quickly. We expect to have alpha code a year from now, for some definition of alpha. We might even ship it, but we expect it to be well-designed alpha code.

Perhaps mentioning this alpha time line was his first big P6 mistake. [2]

It seems Larry felt comfortable announcing the original one-year-to-alpha estimate. But his comment is clearly about an open source community effort, not something he could assert control over, especially time wise, even if he cared to try. (He had already made it clear, before Perl 6 began, that he did not.) So why did he say such a thing?

Perhaps he was thinking he had pulled off somewhat similar feats on his own before. After all, he wrote the original Perl 5 in about 18 months. And in the new project his anticipated initial role was "merely" thinking up a new language design with a view to keeping what was thought good about Perl 5, dropping what was thought bad, and integrating what he could from the dozen or so RFCs that the design process would supposedly be built around. So perhaps it was on that basis that he felt confident mentioning an alpha time line.

----

Imo, based on what I read at the time and have reread since (some key links are provided in this comment), less than 2 weeks later things were going downhill fast from a project management and time line estimate standpoint: [3]

* An unrealistic draft schedule that got zero feedback ("Nobody had any objections to the draft") was converted into the official one ("so the draft becomes the real one").

* Despite the ominous sign of having no feedback, an alpha millstone (typo intentional) that apparently halved the time from the original estimate Larry had announced ("Vendor liaison begins January 1st 2001 with the alpha release") was added "unilaterally".

* And to wrap up the whole arbitrary schedule "The final release will be on (he picks a date approx. 18 months from the start of the project) 1 January 2002."

While the schedule's overall "long term" time line was clearly a made up fantasy from the start, the short term (weeks) details were no better.

Larry was expected to start work on a language specification on Oct 1st 2000 and deliver it in FINAL form one month later. Imo this was obviously insane even if there were ZERO RFCs.

(Yes, Brendan Eich produced an initial JavaScript design and prototype implementation in 10 days. No, this does not mean it made sense that Larry would produce a new final P6 design in a month.)

Then, by the cut off date of Oct 1st the project had officially accepted not zero, not a dozen, but THREE HUNDRED AND SIXTY ONE RFCs. Many were substantive. Many were good ideas, poorly thought through.

Maybe Larry could just about have hit the Oct 14th draft date if he simply summarily rejected around 97% of them without reading them.

Or maybe he could if he had worked on it all, non-stop, without breaks for food etc., for 45 hours a week, spending FIVE MINUTES reading each RFC, FIVE MINUTES thinking about how to integrate it and FIVE MINUTES writing up a draft specification of that aspect.

Except that wouldn't leave time for the rest of the language that the RFCs didn't address, eg what was already in Perl 5.

And anyway, FIVE MINUTES?!? Imo an estimate of FIVE HOURS WALL CLOCK TIME for these tasks would not be unreasonable. FIVE MINUTES is INSANE. (Imo.)

So, imo, as early as Oct 1st 2000, the schedule's millstones were very clearly INSANE expectations.

----

But it's not just Larry and the RFCs.

The more general point is that the project's management failed to adapt to what had actually happened a few weeks into the project. There had been virtually zero input/help for management. That was an ill omen. In addition the language design task had grown to absolutely monstrous proportions. These ill omens were unexpected and then left unmitigated. [3] [4]

The functional response would have been to reset expectations. But that didn't happen. So instead of P6 being considered a project that was the sort of thing that takes a decade if it's just a mild rewrite (Python 3 arguably took longer) it was instead expected by some to be done in 18 months based on nothing more than wishful thinking. That's not a good start expectations wise.

----

I fully expect chromatic to want to attack me and/or Larry, point out that they're an authority and I'm not, suggest I'm throwing folk under a bus, etc. I won't be responding. Please take what they write with a bucket of salt.

----

[1] https://www.perl.com/pub/2000/10/23/soto2000.html/

[2] Larry has long said P6 would be a journey of mistakes, just like the journey with P5, albeit hopefully new mistakes.

[3] https://www.nntp.perl.org/group/perl.bootstrap/2000/08/msg11...

[4] https://www.nntp.perl.org/group/perl.perl6.meta/2000/09/msg4...

[5] https://www.nntp.perl.org/group/perl.perl6.meta/2000/09/msg1...

Imo the issue of a time line (estimated or actual) is immaterial to the original point made up thread (the role of tests in determining a compiler's compliance to a language specification).

The issue is whether P6 advocates are honest in their advocacy. Pretending that the goal was always to create a sister language or that the intent from the start was always to take 15+ years to release a stable version or that the intent was always to define P6 as a specification and test suite or that a cross-platform VM wasn't a goal from the start is dishonest.

>I LOVED Perl.

5 exists and will always exist. :-)

It will not, however, always get security updates, performance improvements, and maintenance for its libraries.

Can you elaborate on languages that will?

I wasn't commenting on Perl as a language, but rather a specific version of the language.

The thing is, Perl6 as it exists today can not be used as a replacement for Perl5, and in consequence, Perl5 development continues and will continue for the forseeable future. It's better to think of Perl5 and Perl6 as two separate languages in the Perl family, similar to various Lisp dialects.

Perl 5 and Perl 6 are essentially separate languages at this point, so Perl 5 will continue to get features and updates for as long as anyone uses it, which will be a very long time yet.

The current state of Perl 5 for Python fans:

----

Perl 5: I'm not dead!

TIOBE: 'Ere! 'E says 'e's not dead!

Internet: Yes he is.

Perl 5: I'm not!

TIOBE: 'E isn't?

Internet: Well... he will be soon-- he's very ill...

Perl 5: I'm getting better!

Internet: No you're not, you'll be stone dead in a moment.

TIOBE: I can't take 'im off like that! It's against regulations!

Perl 5: I don't want to go off the chart....

Internet: Oh, don't be such a baby.

TIOBE: I can't take 'im off....

Perl 5: I feel fine!

Internet: Well, do us a favor...

TIOBE: I can't!

Internet: Can you hang around a couple of minutes? He won't be long...

TIOBE: No, gotta get to Reddit, they lost nine today.

Internet: Well, when's your next round?

TIOBE: Next year.

Perl 5: I think I'll go for a walk....

Internet: You're not fooling anyone, you know-- (to TIOBE) Look, isn't there something you can do...?

Perl 5: I feel happy! I feel happy!

----

But seriously, Perl 5.30 just came out in May. It's not dead yet.

I didn't mean to suggest that Perl 5 is dead, only that it's reasonable for people to consider Perl 5 to be deprecated sooner than Perl 6 will be.

I am not so sure.

Perl 5 is more widely used and had much greater historical adoption as the "glue" of the early Internet.

Perl 6 has not displaced Perl 5 and does not appear to be in a position to do so. I believe Perl 5 may out last Perl 6 based on how widely it is used and available.

It is a different situation compared to Python 2 / Python 3. Whereas Python 3 is slowly replacing Python 2, the same cannot be said for Perl 6 slowly replacing Perl 5.

Python2 is EOL as of the end of this year.

Exactly--there is momentum to migrate from Python 2 to Python 3 since support for Python 2 is ending.

I prefer Python 3 to Python 2 and have migrated all my projects that still matter.

Support for Perl 5 is not (to my knowledge) ending anytime soon.

I see no realistic weight behind the notion that P5 will be deprecated in the foreseeable future (decades).

Python 2 or 3 fans?

Both.

It's taken with minor adjustments from this Monty Python scene: https://youtu.be/Jdf5EXo6I68

Wait, what? Is there a reason to believe that indefinite future maintenance of Perl 5 is more in doubt than of, say, Ruby or OCaml? (Of course it has a smaller community than, say, Python or Go, but the community is still existent and AFAIK intends to maintain it indefinitely.)

I don't doubt Perl's longevity, only the maintenance of a specific version. I'd say the same of Python 2, despite its alarmingly long afterlife thus far.

But the Python 2 development community a) has announced a specific date for end of life (January 1 of next year), b) had communicated the intention to sunset Python 2 in favor of Python 3 for years before the specific date was announced, c) is no longer applying anything but critical bugfixes to Python 2, and d) has collectively moved to developing Python 3. None of these are true of Perl 5/6.

Alternatively, if we're going to look for analogies in other languages instead of listening to statements from the Perl 5 community themselves, let's make an analogy to C and C++. Despite C++ having been a mature, usable language for decades, people are still using and developing C compilers and libraries.

Perl 5 and Perl 6 are completely separate languages, they aren't "versions" of the same language.

A rather non-obvious fact, because the language names clearly and misleadingly suggest otherwise.

You're right Perl 5.18 is no longer being maintained.

But Perl 5.30 is still maintained, and almost all Perl 5.18 code should run on it unaltered.

---

As far as I know, there is no-one who is involved with maintaining both Perl5 and Perl6. There are separate groups for both.

In fact I think there are more people being paid to work on Perl5 than there are being paid to work on Perl6.

It will never get a new major version number though.

... if they don’t decide to just name perl 5.100 “perl 7” instead

It's unfortunate, but it has no practical bearing on the fact that the language is still actively maintained and improved upon, with a major release every year in late May -- 5.32.0 being the latest such release.)

CPAN also exists, but not as it once did. Perl 5 wasn't just a language, but an ecosystem.

> CPAN also exists, but not as it once did.

Right, it's way better. What makes you ignore all the great improvements the PTS have made?

Reply on news.ycombinator.com