Hacker News new | past | comments | ask | show | jobs | submit login

One of Perl 6's original design goals was that it should "still be Perl". In that sense, I think it's a failure. Aside from a superficial syntactical resemblance, it really doesn't feel much like my beloved Perl 5 at all. Its semantics are very different.

It also seems to suffer from an advanced (possibly fatal) symbolpasta diarrhoea. Perl 5 was not pretty, but Perl 6 at times can be downright hideous.

If Perl 6 is a Lisp, that's great! You know, I am deeply and madly in love with Clojure at the moment. But that manages to be a Lisp without falling even deeper into the line noise trap than P5 did. But, you know, syntax is just syntax.




> Perl 5 was not pretty

Beauty is in the eye of the beholder. I won't bore you with the details, but rest assured that there are many others like me, who appreciate Perl 5 both for its aesthetics, and are able to use the technical consequences of said aesthetics for productivity.


You're right that it's subjective, but I think it's true to say that the most commonly appreciated programming language aesthetic has shifted since Perl 6 started to when it delivered. Back then many programmers appreciated the whimsical, pseudo natural-language nature of Perl. These days I don't think that style is as fashionable amongst most programmers and purity and straight-forwardness is more appreciated. Perl 6 is going to lose out because of that.


I like P6 syntax and semantic more them P5.

My only one problem about P6 is the fact they dropped the effort of having the specification so others can implement the language too. Looks like they prefer a conformance test instead of a formal/complete specification.

While that is perfect fine, I would say having both the test and the spec is even better, for those trying to learn and implement the language.

A good, formal and complete specification will make my learning process much better, IMHO.


I've recently been implementing a language based on a conformance test instead of a spec, and it's really hard. I often have two tests that do different things with seemingly similar inputs, and I struggle to find the underlying reason behind what is going on and what the cause of the difference in output is.


There are still the design docs (http://design.perl6.org/) which are essentially spec documents. They are what implementors have been using over the years. Don't forget the tests came from Pugs and now Rakudo is using the same test suite, so it's more portable than you perhaps imagine. The tests are the stamp of approval for a version number conformance. If you can pass all the versioned tests then you are that version of the language. I think that's a lot stronger statement than the engineers think they understood a spec document, even if formally specified. What are your thoughts on why that isn't ok or worse than relying on pure docs?


I think you've misunderstood the original intent as expressed by Larry Wall in 2000, the current situation, and the future intent and practical realities.

For the original intent I'll quote Larry from the day he announced Perl 6 in 2000[1]:

"I don't know how strict a spec it will be from the language design point of view. I'm not really big on that sort of spec and there is some value to using the reference implementation approach and what we currently have is a reference implementation [with] no second implementation, well, unless you count the JVM work, but, obviously there are benefits to having things justified well enough that you could implement another one even if you didn't want to, so we'll definitely be working in that direction and - do you have something? And there was something else I was going to say - what we particularly want to stress in terms of - is not perhaps so much the spec as developing our current regression test. Well, we call them regression tests, but they're almost more acceptance tests, but, we developed our acceptance into real regression tests then you'd further 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 say, "This is Perl, this is not Perl," 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."

I think the 6.Christmas release corresponds fairly directly to this original intent.

In the meantime the spec docs (as against the spec test suite), which are currently referred to as either "speculations" or "design docs" to better emphasize their contemporary role, are currently well behind the test suite and implementation. This is presumably what caught your attention.

The current thinking is that Perl 6 will follow the pattern adopted by many other mainstream languages in terms of the timing of development and publication of a relatively formal and debugged prose specification.[2]

This thinking in turn suggests it would be best if the spec docs caught up with the spec test suite and Rakudo and were then polished and formally published in a frozen form, some years from now.

At that point making a significant effort to provide practical support for alternate compiler implementations ought once again become compelling.

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

[2] http://pmichaud.com/2015/pres/fosdem-specs/fosdem-specs-1.pd...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: