Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

blogs.perl.org

Post reply on HN
Print view View original

121–130 of 148 posts

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#121

Post by kbenson »

chromatic wrote: post #114
perlgeek wrote: post #95

Earlier quoted context omitted.

> What are the advantages of MoarVM over Parrot Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage. That means cleaner design, less memory footprint, faster execution. > and why were we stuck at Parrot for so long before giving it up? Rakudo works on Parrot. Why drop support for it? Once you frame the question that way, the answer be…

Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage. I think you're being uncharitable. It's clear enough in retrospect that plenty of Rakudo developers wanted to get rid of Parrot years ago, but wanted to couch their "Let's burn it all down and start over" in much more careful terms which allowed them to take advantage of Parrot's st…

That's... an odd way to start a response in which you are very obviously being uncharitable yourself in assessing the motivations and actions of real people. What's more, you are doing it as a non sequitur.

I'm really not sure what you're trying to say here. How is a later project being able to look at what came before and try to determine what decisions were good and bad of the prior project and trying to avoid them being uncharitable, and what does that have to do with whether some people wanted something different long ago?

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#122

Post by ab5tract »

SrslyJosh wrote: post #117
xaa wrote: post #112

Earlier quoted context omitted.

I'm also interested in an answer to this question. Perl 6, as a feature set, looks awesome and I'd really consider replacing my use of Python with it, espcially because of the gradual typing and fast startup time (assuming Perl 6 follows Perl 5 in this regard; my initial experiments haven't been encouraging though). In general, I think there's huge latent demand for a relatively fast, "next-gen" scripting language, a…

> On a related note, should I, as someone who does not know Perl, bother learning Perl 6 yet? Or is it likely to change a lot before release? I don't think so. Everything I've read in recent years has indicated that the grammar is stable, which implies that the operators and planned feature set are also stable. If you want to melt your brain, you can take a look at STD.pm6, the official grammar for Perl 6, which is a…

Just to clarify, as you responded "I don't think so" to two questions, the language is not going to change too significantly prior to release, so yes you should bother learning Perl 6. No one I've met who has actually bother to use the language has had anything but excitement about it.

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#123

Post by ab5tract »

chromatic wrote: post #83
perlgeek wrote: post #80

Earlier quoted context omitted.

> I've been a professional Perl developer for a long time, and I've followed Perl 6 since the first announcements. There is some impressive and really interesting work going on there, but from my perspective it seems to be a new language rather than a new version of Perl. It's both, really. If you use it (and after a while of getting used it), it just feels like perl. > I fully support the development of Perl 6, but…

But that's too late now.... Come now; that was the excuse given five and ten years ago. the "Perl" brand is still very strong Some would argue (including the post to which you're replying) that the brand is much less so, thanks to the very line of thinking you're defending.

I've been in and around Perl for a long time, and this line of argument feels very tired to me.

Perl 6 did not "kill" the Perl brand, the state of Perl circa-2000 "killed" the Perl brand. All the issues @perlgeek just noted, those "killed" the Perl brand. The fact that Python was simply a better option for 99% of the projects that were started around that time (even if half or more went with PHP instead) "killed" the Perl brand.

If Perl 5 as a programming language is so susceptible to "oh but this new version makes it seem that there are deficiencies in the current version", could it be because there are deficiencies in Perl 5? If hiding that fact from others is so important to the "brand of Perl", what does that actually imply?

Please stop pretending that starting a project to build a better Perl somehow killed the camel. It's obvious that this is not true even from a Perl 5 usage standpoint, but it's even more absurd from the standpoint of next year, or the year after...

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#124

Post by wantarray »

raiph wrote: post #101
wantarray wrote: post #76

Earlier quoted context omitted.

> Why would I learn this rather than Haskell? You wouldn't. That is to say: You might learn Haskell if you want do write 100% functional code, and Perl 6 if you want to write imperative/procedural/OO code with functional idioms mixed in here and there (in places where that facilitates a more elegant approach). I.e. the two languages are not really competing in the same category. Even though Perl 6 has first-class cod…

> lack of static typing A key feature of Perl 6 is optional static nominal typing: http://www.reddit.com/r/perl6/wiki/gradualtyping

That looks like strict nominal run-time type checking to me, not static typing.

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#125

Post by wantarray »

DonHopkins wrote: post #97
sigzero wrote: post #42

Earlier quoted context omitted.

> A library and a language are apples and oranges. Python's library ecosystem is more comprehensive than Perl's language. Because most any language minus all of its libraries is less "comprehensive" than another language's libraries, simply because most mature library ecosystems are much more massive than the language itself. That doesn't even make sense.

What he said, "Also, Perl's library system, CPAN, is far more comprehensive than many languages", doesn't make sense, because he's comparing a "library" to "languages": apples and oranges.

Come on now, it's clear that he meant to compare CPAN to the corresponding module repositories of those other languages.

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#126

Post by ab5tract »

DonHopkins wrote: post #98
kbenson wrote: post #36

Earlier quoted context omitted.

>>"most of the other languages were modeled on it." >Having a regexp library is hardly "modeling a language on Perl". I don't know about most , but both PHP and Ruby were heavily influenced by Perl. If you've used both, this should be apparent, if not, you can easily find references on record to the effect. The original statement may have been a bit hyperbolic, but in context and with constraints something similar is…

It's true that most popular scripting languages today were influenced by the same scripting (and other types of) languages that Perl was influenced by. Namely shell scripting and Lisp. What I object to are the terms "most" and "modeled on", each of which are hyperbolic, but taken together are "hyperbolic squared" (to stretch the mathematical metaphor). And Perl 6 hasn't had much influence at all, since nobody's been…

You are really reaching to say that sed/awk/shell and Lisp were more of an influence on either Ruby or PHP. Ruby has all the same special variables as Perl, FFS! PHP was originally written in Perl. But somehow awk was the bigger influence in either case?

Sorry, but your retcon fails. Even Scala admits it has Perl influences -- http://perl8.org.

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#127

Post by latk »

SwellJoe wrote: post #71
mfrager wrote: post #11

I hope Perl 6 has better runtime speed and memory efficiency because those are the only downsides of Perl 5. However I seriously doubt that will be the case. Perl 6 will most likely be more bloated and slow, but I very much hope that I'm wrong. Just for reference my company's software is all built with Perl 5 and runs great. Most of the execution time is within the database calls so there is no impact from using Perl…

When did Python become faster than Perl 5? I'm not trying to be argumentative, but the last realistic comparisons I did had Perl running quite a bit faster. For example comparing ack to grin, which are very similar projects in Perl and Python respectively...at the time, admittedly several years ago, ack was an order of magnitude faster than grin. I also wrote a few log parsers in both Perl and Python (at a time when…

Perl5 has a lot of historical baggage that makes certain things difficult to do efficiently. For example, how objects work. There is an insane amount of indirection involved for a simple method call, and this indirection can't generally be removed if we want Perl5 to stay highly backwards-compatible. Numerics aren't particularly efficient either. Perl5's opcodes are very high-level. That makes each individual opcode pretty fast, but makes it difficult to inline stuff. Variables can have “magic” attached that can change their semantics substantially. While this is very flexible and allows to do some amazing things, this also requires this magic to be checked on each access. So Perl5 has a lot of features that rank high on “clever”, but low on “can be optimized”. Perl5 never got JIT support, and only has a couple of very experimental Perl-to-C transpilers.

What is fast is string handling and log mangling. Perl was created for that; everything else is bolted on.

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#128

Post by FROGGS »

chromatic wrote: post #28
JadeNB wrote: post #8

I can't find it right now, but I like how this harks back to the original announcement that Perl 6 would be ready in time for Christmas—just with no commitment to which Christmas.

This original announcement, which said "18 to 24 months, with a prerelease targeted for [July 2001]"? http://use.perl.org/use.perl.org/articled5d3.html?sid=00/07/...

And at that point they found out that Perl 6 will be a complete rewrite and not just a cleaned up Perl 5. I also guess that the Second System feeling already arrived in some minds, the problem IMO is more that the 'by Christmas' joke has been kept alive for so many years, without specifying a year.

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#129

Post by chromatic »

kbenson wrote: post #121
chromatic wrote: post #114

Earlier quoted context omitted.

Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage. I think you're being uncharitable. It's clear enough in retrospect that plenty of Rakudo developers wanted to get rid of Parrot years ago, but wanted to couch their "Let's burn it all down and start over" in much more careful terms which allowed them to take advantage of Parrot's st…

That's... an odd way to start a response in which you are very obviously being uncharitable yourself in assessing the motivations and actions of real people. What's more, you are doing it as a non sequitur. I'm really not sure what you're trying to say here. How is a later project being able to look at what came before and try to determine what decisions were good and bad of the prior project and trying to avoid them…

After the first Rakudo Star release, I personally volunteered to spend my Parrot time fixing bugs which affected Rakudo, improving the performance of Rakudo, and adding features for Rakudo, in that order. I offered several suggestions (including native registers, better profiling, object system improvements) and was repeatedly told not to work on them. I will say this, though: there was no friction to working on the profiling system (though it went unused). This happened to other people as well.

I've documented this at length elsewhere.

Those specific features we were told explicitly not to work on were on the top of the list of "Reasons Rakudo Must Abandon Parrot". I find that disingenuous, as if Parrot had been set up for failure.

Perhaps I should apply Hanlon's Razor here, but that feels even less charitable.

Re: Perl 6 developers will attempt to make a Version 1.0 release by Christmas 2015

#130

Post by raiph »

wantarray wrote: post #124
raiph wrote: post #101

Earlier quoted context omitted.

> lack of static typing A key feature of Perl 6 is optional static nominal typing: http://www.reddit.com/r/perl6/wiki/gradualtyping

That looks like strict nominal run-time type checking to me, not static typing.

Thank you for replying.

    my Int $age = 40;

    $age = "old";
That will generate a compile-time error. (Because the "old" bit is a string literal which is interpreted in this case as being of nominal type Str which isn't compatible with the nominal type Int).

Do you have any tips for me on how to make it clearer on the page I linked that this is compile-time checking? Or, more simply, did you just not believe the "compile-time" comment on the page I linked or did you just miss it, perhaps because it's "commented out"? Would it make sense for me to incorporate some of what I write below?

----

Perl 6 supports more than just static nominal typing. You can add arbitrary constraints:

    my Int $school-age where 5..18 = 40;
The code that comes after the 'where' (the '5..18' bit) can be arbitrary code. It is tested against any value that would be assigned to the $school-age variable.

Most folk will just like the convenience of this construct and won't care whether it results in a check at compile-time or run-time.

But some will care.

So, while nominal typing is a compile-time checking affair, what about these arbitrary constraints? Do these result in checks at compile-time or run-time? Well, it depends.

Key quotes from the relevant language design doc[1] are:

> A where clause is considered static if it can be applied to the types to the left of it at compile time to produce a known finite set of values.

The line of code we're looking at:

    my Int $school-age where 5..18 = 40;
can clearly be reduced to the set of integers from 5 to 18. And the compiler code to successfully make that analysis is fairly straight-forward, so it could fairly easily be implemented in Rakudo today.

However, for 6.0.0 (by which I mean the suite of 35K+ tests that are supposedly going to reach beta status by September and the Rakudo compiler that is supposedly going to reach gold status by the end of the year) there's this:

> for 6.0.0 any structure type information inferable from the where clause will be ignored

In other words, the line we've been looking at with the `where` clause will result in a run-time check for 6.0.0.

----

[1] http://design.perl6.org/S12.html#Multiple_constraints

Post reply on HN