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

My perspective is that I'm glad that they are entertaining themselves, but they aren't going to succeed.

It is easy to run a subset of Perl 5 faster than Perl 5. But when you add in all of the features, beating Perl 5 on speed becomes hard.

It always was the dream to integrate Perl 5 and Perl 6. But cleaning up the internals of Perl 5 until general people could work on it would be a several month project that only a handful of people in the world have the expertise to do.

And even if you did that, how do you reconcile Perl 5 reference counting with Perl 6 true garbage collection? The two do not cooperate very well, and a lot more Perl 5 code than you would think relies on things like reliable timing of destruction. On this issue the community has generally been divided into people who think that this won't be doable, and people who think that some day a smart solution will be produced. To date, no smart solution has emerged.

Also Perl 6 was a wonderful dream to entertain people, but its real world adoption is..limited. Like it or not, Perl 6 is effectively here and is named Python 3. No, it doesn't look like the Perl 6 people thought it would, but sometimes that is life.




I'm generally in agreement with everything you state. I do think, however, that with the appropriate amount of engineering, one could build an incremental JIT compiler that sped up common base idioms meaningfully while executing the whacky stuff using the old perl VM. (Ie. more like psycho, as opposited to a full reimplementation such as PyPy.)

Yes, there's a while slew of things you can't do in the case - the old guts and data structures would permeate it. It would be a bit of a horrible maintenance burden. And it's generally not worth it (anymore). There's simply better options available.

I played around with something like that, wow, the better part of a decade ago. The approach was to go from the OP tree back to something that had a few of the execution specifics undone such that it resembled an AST a bit more. Then find sections that could be compiled by the partial implementation and convert those. Tracing facilities were there just at a function level. We'd settled on optional type annotations using a keyword plugin that would populate a structure attached to the CV (function struct) with that information as it went through regular perl compilation. Of course, this falls short of any sort of interesting complier work.

Anyway, my point is that I think it'd be doable for a sufficiently motivated and skilled (and funded) team of folks, but there's very little economic incentive to do so.


Several misunderstandings. we are not implementing a subset of perl5, we are continuing the development of perl5, which stopped around 2002. there are much more features in cperl than in perl5. perl5 is stripping its features, because they are not able to fix the bugs. cperl on the other hand fixes them, and constantly adds new features.

we don't entertain ourselves for fun, we do it for the technical necessity, because p5p is not able to, not willing, left the path to perl6 already, and broke up all cooperation. we need to fixup all the damage done by p5p, because nobody else is doing it.

perl6/rakudo is nice concept but not going anywhere. the architecture is just too broken to be realistically fast enough in production. but who knowns. moar is nice. and we've seen python 3 in production, and compared to that perl6 is a godsend.

cperl will not switch to a gc soon, neither will it provide proper lockless threading. simple goals first, like an object system, types, ffi, async/await, regexp, match, hashtable, inlining, jit, symbol table, ...

cperl easily beats perl5 in performance, but is investing it into better security checks. it's the only language with proper Unicode support already. with the jit and the inliner it will match php7. i.e. not 20x slower, just 10x slower, which is fine.

it's not a dream, it works and used in production. it is also recommended in production over perl5.

rperl already matches C++ performance.


Can I install cperl via plenv maybe? I'd like to test out production code on it and my prime number crunching benchmark.


https://perlbrew.pl/ can do it.

    $ perlbrew available | grep cperl
    cperl-5.24.4
    cperl-5.26.3
    cperl-5.26.4
    cperl-5.28.0
    cperl-5.28.1
    cperl-5.29.0

    $ perlbrew version
    perlbrew  - App::perlbrew/0.84


I'd be interested in this as well. I hadn't looked into cperl in depth until today and its starting to seem appealing after reading a few of the author's posts on reddit and the perl11 blog.


> the architecture is just too broken to be realistically fast enough in production

How so?


The startup overhead, the nqp overhead.

The startup overhead is caused by the idea to have the stdlib in perl6 source code (similar to mature languages like common lisp), and that the compiler will be good enough to produce good enough code. But the sigs of all methods need to be dumped somehow into the binary, and this done beyond naive. Emacs or Common Lisps solved this problem pretty well, via dumping native image of the compiled code, java has a good native class layout, but rakudo is just slow.

The nqp overhead is when you look at the compiled moar code and compare the bytecode to a fast vm. Its still too bad code. moar itself is fine, but the rakudo and nqp layers not. Same for the new jit template idea, which does not scale. At all. There are so many people with so many bad ideas who are not willing to listen to more experienced dev's, so I stopped caring also. It's not worth it, esp. after the parrot debacle. But perl6 people are generally very nice, competent and open, in total opposite to p5p.


perl11 exists because the perl community is full of whacky crazy people who like to shoot for the moon.

Realistically, though, it's not something anybody actually writing perl5 or perl6 cares about or expects to achieve anything. Basically 'urbit with $ signs'


Yeah... I was going to say urbit is urbit with dollars signs, but they are some kind of crypto-token signs, not dollars...


I'm pretty sure cperl is doing exactly that though: http://perl11.org/cperl/STATUS.html


cperl is a trainwreck that only exists because the author forked perl5 because he was removed from the maintainance list because he couldn't stop insulting people.

Don't bother pretending it'll ever be a viable project - periodically he sends patches trying to force perl5 modules to change their code because his type checking code doesn't work, then follows it up with a volley of insults when the maintainers go "huh?"


cperl is not a trainwreck, only perl5 is. cperl exists because the perl5 maintainers are totally incapable of doing their job, and risking the jobs of thousands of fellow perl5 developers. Most of them already switched to something else in the last years. cperl on the other hand implemented most missing features from the last 15 years in 2-3 years, fixed the worst mistakes, and is 10-30x faster and better developed than perl5. perl5 is dead, it is not going anywhere. You had your chance, but you failed. Now the only thing you have left is doing the culture war thing, throwing around CoC accusations. Having no faith, insulting the devs.

Typechecking errors? There are occasional errors because of adding more strictness and warnings from perl6 (strict names, hashpairs, ...) and some internal test and bignum modules are typed for 2x faster performance and to catch typical errors at compile-time. There's an API, and the types reflect that. The problem is that the implementations and the users don't care about the API at all, and neither about typechecks catching these errors.

There are no volleys of insults to any maintainers at all. You still don't get the difference between necessary technical and professional criticism and personal attacks. In fact p5p is throwing around personal attacks and insults all the time. E.g. you are one of the main examples of immature racism in your very public YAPC talks, accusing all Germans to be Assholes (in allcaps) for years. Thought about that once? Why do you think you were not accepted as pumpkin and again the technical most incapable person was elected?

p5p had their chance to do anything with the language in the last 15 years, they had a proper design and spec and sister languages doing the same. They did nothing, all attempts failed and they blocked all improvements from outside. There's no proper management, no process. Either you are committer, then you can do what you want, or not, then you may not do anything. Well, in fact there are only 4-6 bad apples at the top. The rest is doing good, but silent. But the TPM board is protecting the bad apples, promoting the most incompetent, they are even collecting the worst of them. Only if you managed to completely fail a huge project you are the perfect member for the board. Only the most unsuccessful culture warriors are lining up there.

perl5 is not recommended to be used in anything serious anymore. There are dozens of serious bugs and design errors not fixed, and errors and destruction being added every new release. I have no time to file all the CVE's, look at the cdelta's. 90% of the decisions are wrong. The new code of conduct is being misused to silence valid technical criticism, because perl5 is now a religion, and you may not distrust the leaders. This was literally the explanation.


(rurban is the author of cperl and technically brilliant)

I did, indeed, have a couple of slides in my talks where I said "if you think somebody's an asshole, you could be wrong, maybe they're actually just german" - referencing the direct german style of communication, which I personally rather like.

Taking this exactly backwards and then calling it "immature racism" is ... precisely the sort of thing I was referring to, as is deriding everybody you've had technical disagreements with as "unsuccessful culture warriors".

I find this a shame, but we've discussed it more than once over the years and given I haven't convinced you yet, I find it unlikely I ever will.


I'm German and I find that funny.

It's not that I cannot be offended by stupid stereotyping and attacks on Germans (Erik Naggum had some really vile posts in that regard), but the above is not even on my top ten list of things bothering me today.

Number one is cooking quinces to death, because I just wanted to blanch them a bit and forgot to turn the stove lower), so still pretty inconsequential.


The aggravating thing to me is it wasn't even an attack, it was part of a talk about "assholes, idiots, whiners and trolls" that basically said "none of these people are necessarily that, here's how to look at things differently and maybe end up getting on with them instead".

Every other german who rendered a comment on said talk thought it was hilarious and clearly got that I sympathised due to being pretty blunt myself (oh gods east coast american middle managers, how easy they are to offend ...)

My commiserations on the unplanned demise of your quinces.


Why is that even a YAPC talk?

I've heard points similar rurban makes from mlehmann, who also got tired of p5p and maintains his own perl5 fork.

http://schplog.schmorp.de/2015-06-06-a-stable-perl.html


It was a keynote because open source is made of people and encouraging helpers and contributors is how open source projects prosper.


Points taken! Thanks for adding some insight.


Your slide was simply:

    GERMAN
    ASSHOLES
We were not amused but didn't cry wolf as it would happen nowadays with a CoC. I would never use such terms, but perl5 leaders are very keen to throw such accusations around all the time because it conveniently distracts from the technical arguments you need to avoid. You kept with this slide for several years, but since then deleted all youtube instances.

I'm not a german btw. but my mother was born there, so I felt with them.


Actual slides: https://shadow.cat/resources/slides/matt-s-trout/2011/yapc-n... - and I did use part of these slides once more, but that's not exactly "several years".

If anybody's confused why there's a downwards arrow on one of the slides it was so I could stand underneath it to proclaim myself loud, blunt and obnoxious at the start of the 'assholes' section because this was a community hacking talk and I was identifying myself as part of the group I was about to talk about.

I don't even have access to any of the relevant bits of youtube.

This is just getting silly now :(


I've met plenty of direct-talking Germans who wouldn't be mistaken for assholes.


Well, yes.

"Some people who initially appear to be in group X may turn out to actually be in group Y" does not, at all, require that all of group Y may appear to be in group X. Logic doesn't work that way :)


The natural successor of perl5 was supposed to be ruby, at least in the early 2000s. Python is nothing like perl (by design), but got adopted for the same tasks nonetheless.


> Python is nothing like perl (by design)

Which is ironic because python and perl are extremely similar. I like to say that "python is perl for bureaucrats". I've been doing a bit of python for (?:recre|educ)ational purposes recently due to its superior maths libraries. I can't say I see the advantages, but that's probably just me.


> Which is ironic because python and perl are extremely similar.

Would you mind expanding on this a bit? It's been a while since I did perl, but I remember it being fairly distinct from python, other than being a dynamically-typed "interpreted" language.


The feature set and type of problems that they are good at are similar. The personality of the language is not. But the translation is easy.

What is weird about Perl is that it is intentionally designed to use the part of our brain that parses syntax to encode a bunch of information. So $ means "the", @ means "these", and so on. The linguistic analogies are carried surprisingly far, and There Is More Than One Way To Do It is considered a feature.

By contrast Python tries to have a very simple and regular syntax. It has well-organized libraries. And aims to have one simple and right way to do it. (Though why their one way to handle opening external processes should be so Byzantine..well I digress.)

But both of them live in the space of dynamic interpreted libraries with similar kinds of introspection, similar native data structures and so on. Both take heavy advantage of the fact that between decent scalars, arrays, and hashes you can write algorithms for almost any problem which will perform within a constant factor of a theoretically ideal data structure. Therefore given the same problem it is natural to write the same solution in about the same way with very similar characteristics.

If you know one, learning to write the other isn't hard and the mental translation remains easy.

Oh, there are differences. Some things are easier to express directly in Perl. Like backticks. Python can let objects be used as keys in dictionaries. Perl's optional variable declarations catch a lot of minor bugs. Python's iterators/generators take a lot of work to replicate in Perl. (Yes, there are CPAN modules that make it doable. Have we agreed on which one is right?)

But on the whole for most code, you tackle it in the same way, with equivalent data structures and naturally organize it similarly using the same strategies.

Compare and contrast with, say, Java.

The fact that they are so close puts them in a natural competition. And there, well, Perl is not popular for new projects while Python is one of the most popular languages out there. All the cool new integrations are made available in Python first and Perl is an afterthought. If they are too similar to co-exist without competition, it is clear which one is going to win. And it isn't Perl.


> Python can let objects be used as keys in dictionaries.

In Perl 6 object hashes allow you to do the same (https://docs.perl6.org/language/hashmap#index-entry-object_h...). If you're only interested in checking for existence, you can use a Set (https://docs.perl6.org/type/Set). If you want to just count the number of occurrences, you can use a Bag (https://docs.perl6.org/type/Bag).

> Perl's optional variable declarations catch a lot of minor bugs.

In Perl 6, variable declarations are obligatory by default.

> Python's iterators/generators take a lot of work to replicate in Perl.

In Perl 6 there is an easy to use interface for creating iterators (https://docs.perl6.org/type/Iterator)

All of these features are built-in, so no module loading is necessary.


I do not think of Perl 6 as Perl, despite the naming and people involved. I believe that it is as easy to migrate from Perl 5 to another scripting language as it is to migrate to Perl 6.

Furthermore the last I heard, Perl 6 performance was a disaster story. And libraries + real world adoption is kinda thin on the ground. Therefore other scripting languages (particularly JavaScript and Python) are more compelling targets to migrate to.

Has this picture brightened in the last year or so?


> I do not think of Perl 6 as Perl, despite the naming and people involved. I believe that it is as easy to migrate from Perl 5 to another scripting language as it is to migrate to Perl 6.

These beliefs are shared by most users of both languages, which makes bringing up Perl 6's capabilities in a Perl vs Python discussion confusing.


I would say so, yes. For instance, basic object creation in Perl 6 is now faster than basic object creation in Perl 5. Both can be improved with some tricks that experienced developers know, such as not using accessors in Perl 5, but directly lookup keys in the underlying hash. Similarly in Perl 6 some tricks can be performed. And then still Perl 6 is faster. Introducing Moo or Moose on the Perl 6 side, will only make Perl 5 slower.

Making things faster in Perl 6 has been the main focus of development in the past 3 years.

See also our most recent teaser for the 6.d release: https://i.redd.it/et514ut106u11.jpg which shows that the use of set operators has become almost 50x faster in that period.


> Python can let objects be used as keys in dictionaries

You can do this in perl too with a core (since perl 5.004) module. https://metacpan.org/pod/Tie::RefHash.


Their type systems, object model and reflection capabilities are very alike.

It's been a long while since I've developed anything serious in Perl, but the main difference I find between Python and Perl, aside from the syntax, is the value/reference split: Python makes every (passed) value a reference implicitly, Perl uses references explicitly, that can affect an architecture in important ways.


Indeed. I managed to program Python a few years before really taking note of that difference. Couldn't understand why my data structures kept being corrupted. Ahem.


FWIW, in Perl 6, references do not exist at the language level. At the implementation level, you could argue that everything is passed by reference. Perhaps you may find https://opensource.com/article/18/8/containers-perl-6 enlightning.


Agreed. ruby is really nice. I've worked some time on a better ruby VM, potion by _why.

but in the end ruby had the same struggles as python and perl, and basically killed themselves. it's much more racist over there than in perl. php was the only major scripting vm which had some proper progress, but they started from a very poor stdlib, so the old sins are still hurting them.

It's more worrying that that such an absurd badly designed language such as Javascript took over, and Dart was put back. And that the Lua vs Luajit fights were not resolved. This hurts everybody in the long run, because luajit would have been the best of all.




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

Search: