Hacker News Reader

The more I think about it, the more I realize that Perl 6 was misnamed. It should have been treated as a new language with some Perl heritage, not just a new version of Perl.

The Perl 5 diehards aren't going to switch, and people who aren't already Perl hackers are going to think it's the same old Perl that scared them off ages ago.

It's a shame, because Perl 6 is a great language (and I say this as somebody who was put off by Perl 5), and the Parrot VM is particularly awesome.

It also has some of the best error reporting I've seen: it offers a number of possible solutions, and if you try to use a Perl 5-ism that's not supported anymore, it'll tell you what the Perl 6 equivalent is.

> Perl 6 was misnamed

Damian Conway agrees with you - but Larry Wall decides, and he insisted on calling it Perl 6. Maybe Conway has a point, but maybe so many people wouldn't have worked so hard on it for so long if it was called something else.

As someone that uses Perl daily I totally agree with you.

The name not only is bad for newcomers but also for Perl itself. Perl 5.0.0 was released in 1994 (!), today's Perl 5.20 is miles ahead but we can't bump the version because it would only make things even more confusing..

> and people who aren't already Perl hackers are going to think it's the same old Perl that scared them off ages ago.

consire though, that perl6 is soon going to be 20 years old, there is a whole generation of devs which were never scared off by perl5 at all. I say this as someone who, ten years ago, didn't understand a lot of the complains about perl because they were mostly directed at perl4 problems :)

Perl unless true

Yes, rewriting Perl 5 in Perl 6 would be quite an endeavor. However, that's why Inline::Perl5 was invented. It lets you use Perl 5 libraries in Perl 6 code:

  use Inline::Perl5;
  use MyProprietaryModule:from<Perl5>;
  use YAML:from<Perl5>;  # take advantage of p5 cpan

  my $foo = YAML::LoadFile('foo.yaml');
  my $bar = MyProprietaryModule.someMethod('baz');

So what this allows you to do is use P6 features where they might benefit your project, but still use all the P5 code you've invested in. There are some cases where Inline::Perl5 has problems, such as running P5 code multithreaded, but aside from that I've had few problems using it with stuff from CPAN and with my company's own proprietary code base.

There are also the modules Inline::Python and Inline::Java (for the JVM backend), but I haven't used them.

Inline::Perl5 is just a very thin layer to communicate with a Perl 5 process. This works well for small things but it's not practical for more complex ones. You can call code of any language from any language using this technique, that doesn't mean the languages are integrated.

Have you tried it this year?

In his three minute lightning talk in October last year[1] nine demo'd the small things I think you're talking about (calling Python code from within Perl 5 code from within Perl 6 code and using XS-based Perl 5 modules from CPAN).

But that talk was merely a snapshot of his progress just a few hours after he began.

If you read the examples in the README of Inline::Perl5 as it is today I think you'll see that it is already a lot more capable than you are thinking it is. [2]

[1] https://www.youtube.com/watch?v=m_Y-lvQP6jI&list=UU7PuZDAIVM...

[2] https://github.com/niner/Inline-Perl5

Note that no actual IPC is involved: The Perl5 interpreter gets loaded from a shared library and afaict does not run in a separate process.

"The Perl case, on the other side, is much worse. Migrating a relatively complex project from 5 to 6 is extraordinarily hard. It's probably the same as a whole rewrite."

One of the features of Perl 6 discussed in the article is "Fully backwards compatible with the use of Inline::Perl5". So why is it extraordinarily hard to migrate? I admit it is non-trivial, but the designers made it a key point to be backward compatible. No need to rewrite, Perl5 and Perl6 can co-exist in the same codebase.

"There is no incentive for migration."

Have you looked at the features Perl6 provides[1]? They may not seem valuable to you but it cannot be denied that the new features are plentiful and powerful from a programming language perspective. [1]http://www.perlfoundation.org/perl6/index.cgi?the_long_perl_...

Inline::Perl5 is just some glue to communicate to a Perl 5 interpreter from Perl 6. It's a simple form of inter-process communication between Perl 5 and 6. It's not that you can continue writing your Perl 5 program/library in Perl 6.

This approach is not only really bad for performance, it's also very limited. For example, you can't just share data between both interpreters, however you can send some basic datatypes from one to the other.

This has been done for other languages as well, for example, check Inline::Python [1]. It's an interesting thing, but not very useful for production.

[1] http://search.cpan.org/~nine/Inline-Python-0.49/Python.pod

You do have a point, but your description sells Inline::Perl5 short: For example, it is possible for Perl6 classes to inherit from Perl5 ones.

Note that Inline::Python for Perl 6 allows one to do likewise with Python. [1]

"even PyQt's low level mingling finds all the information it needs and we can write programs using PyQt in Perl 6 :)"

[1] https://github.com/niner/Inline-Python/commit/82cab4181d98f0...

I would never say it is likely that any language will be well-adopted. Fortune plays too big a role.

However, what Perl's long development cycle means is that its widespread adoption would depend on new users taking it up. It will be a new language from their standpoint and backward compatibility will be less an issue.

Widespread adoption will also require transitioning of a core group of existing Perl power users. After 15 years, all the emotionally inflamed debates, tirades and rants have probably run their course. Everyone knows where they stand and has had time to come to piece with it...and even the youngest among those who have been there since the decision are long out of short pants. Zealots on both sides have been living together a long time.

> The true lesson learned for language developers is: Don't break backwards compatibility. Ever.

Certainly true, and yet this is the situation that led to a lot of the hate for C++.

The reason for the numerous meanings of the "static" keyword for example is because if you introduce more keywords then you might break peoples code that used those proposed keywords as variable names.

And then of course a large percentage of C++'s baggage is due to backwards compatibility with C in the first place. Without that baggage C++ would be a much better language and yet you can't deny C++'s success from that decision.

So the moral of the story is that you either make a language nobody uses or you continue to cop flak for all your old decisions forever.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup

Yeah, life sucks. There's no good solution to all that.

The approach used for new keywords is to use lots of '__' on one end or the other. Anybody that used variables with those names was asking for trouble. Yet, then, the new keywords look like crap. Nobody wins.

My favorite, years ago, was the usage in the normal C header files in Linux of a linked-list variable with the name 'new'. It was obvious that nobody in Linux-land had ever compiled a C++ program.

New C keywords now use a leading underscore (_Atomic, _Bool, _Static_assert, ...) and come with a header file you can include to get a more friendly name (stdbool.h, stdatomic.h, assert.h, ....).

As to not keeping your C code C++ clean: Just use a dedicated C compiler and link the object files.

Then what header files do you compile your C++ with? That's all there was at the time.

If it occurs in public header files or if you use C++ keywords as external symbols, that is indeed a bit... inconsiderate, to say the least.

Header files intended for public comsumption should stick to the intersection of C and C++ in most cases.

>>In the real world, adoption is not only driven by how cool a language is, but the ecosystem of tools and developers around it.

If it gets even half close to where Perl 5 is we can only expect great things from Perl 6.

>>The true lesson learned for language developers is: Don't break backwards compatibility. Ever.

If you look at the whole grammar system and the compiler design of Perl 6 you will see this is precisely what they have done.

>>Guido said this won't happen again.

Not that easy. To compete with newer and powerful tools you have to add features that you need. You can't do that without bloat or breaking things. Again look up the Perl 6 compiler design.

>>Migrating a relatively complex project from 5 to 6 is extraordinarily hard.

This is like saying migrating from C to Java is hard. Of course it is, because 5 and 6 are two different languages.

>>There is no incentive for migration.

There never ever was and should never be, Perl 6 is for new projects. Perl 5 and Perl 6 are two different languages which will have their own evolution path.

>>But Perl 6 while being a nice language, doesn't seem to have any killer feature compared to mainstream languages.

Seriously?? Have you even looked at Perl 6.

> Seriously?? Have you even looked at Perl 6.

Yes I have. Many interesting features. Most of them not good enough to be considered killer, IMO. What are your suggestions?

Here's one I've started to focus on in the last few months:

    say "ปฏิบัติจริง".chars; # says 7 [1]

Perl 6 may be a game changer in years to come among those who need to munge text that's Thai, Chinese, etc.

http://www.reddit.com/r/perl/comments/2szv7m/beginner_progra...

I don't see how this is a language killer feature. It looks more like a library feature. And yes, Perl 6 has a superb unicode library. In other languages, you can add the functionality as libraries. This is an example in Python:

    import unicodedata

    def count_graphemes(string):
        count = 0
        for codepoint in string:
            if not unicodedata.category(codepoint).startswith('M'):
                count += 1
        return count

    print(count_graphemes("ปฏิบัติจริง")) # prints 7

This example is over simplified as grapheme clusters are trickier to detect, but proper support is coming to Python's standard library: http://bugs.python.org/issue18406

(Edited to say "regular folk" instead of just "folk" in the last paragraph to make it clear I'm talking about non-expert coders who would much prefer that stuff like converting mixed case text to all lower or upper case, or making sure some text visually fits in a fixed length field, be a reasonably simple operation, like it already is when handling most Western languages.)

----

Would you agree that you are saying that you think it's OK that:

* The appropriate long term solution is to use library code when doing character or substring level operations on arbitrary Unicode text;

* Language implementors have generally not yet written said library code;

* The built in character and substring operations in mainstream languages unpredictably misinterpret and corrupt international text such as Thai, Chinese, etc.;

* The current solution for correct, non-corrupting character and substring handling of arbitrary Unicode text is to hand build custom code to do things like get the length of a string or replace a substring.

If you disagree with the above, then I'm confused.

If you agree, then you're in agreement with most folk and I think you and they are blind to the needs of regular folk who need to handle, say, Chinese text, and these latter folk will find the simple and correct built in character and substring handling in Perl 6 to be one of its killer features.

> Migrating a relatively complex project from 5 to 6 is extraordinarily hard.

Are you willing to share any details of the project you migrated?

I wonder if python3 design helped writing shorter and more robust programs.

I would think that correct unicode handling would satisfy that requirement.

It may be instructive to consider what exactly you mean by "correct unicode handling".

What would you say is the length of the Thai word ปฏิบัติจริง ?

What does Python 3 think is the length? What does Perl 6 think is the length? Can you explain the difference? And what do you think are the practical implications for code in Python 3 vs Perl 6 as it relates to "correct unicode handling", shorter code, and robustness?

I think he meant consistent more than correct. I've read that once decoded, the data will be stable, unlike python2 where transcoding (lossy one that is) may occur between different modules under your nose.

Right. Aiui both Python 3 and Perl 6 allow correct handling of Unicode byte buffers and whole strings.

Which will be great for applications that don't need to do anything at substring or character level.

Afaict, in Python 3, code that does things at substring/character level to Thai, Chinese, etc. text will be:

* buggy, even spuriously cutting characters in half if any string changes are made, if standard string/substring/character functions are used

OR

* verbose and messy, if the reqired-for-correctness grapheme handling is introduced

If you're a Perl programmer in Thailand, drop me an email

That's what I was thinking about when typing my comment. I only wanted field reports, not only theoritical (even though clear) advantages.