in reply to Re^2: It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?
in thread It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

As if a change in the name of Perl 6 would be needed for Perl 5 to continue to live. The community of people who keep on maintaining Perl 5 is large, the ecosystem is healthy, problems are solved. Plenty of people (but more are welcome) cooperate between Perl 5 and Perl 6.
  • Comment on Re^3: It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

Replies are listed 'Best First'.
Re^4: It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?
by syphilis (Bishop) on Jul 15, 2018 at 13:21 UTC
    As if a change in the name of Perl 6 would be needed for Perl 5 to continue to live

    I look at it the other way. I think Perl6's best chance of survival is to keep the "Perl" in its name, and I think Larry recognized that - which is the reason that he opted for the "Perl 6" name in the first place.
    I think he realized that, without the Perl 5 association, there was a good chance that the new venture would fail - thereby exhibiting his lack of faith in the ability of his new programming language to stand on its own merits.
    (This is the only sensible explanation of the name choice that I can think of. Do you have an alternative ?)

    So ... I guess that if Perl 6 takes off I'll be wondering whether it's because of the smart name choice, or because it really did have the wherewithal to stand on its own merits.
    I don't really care about the correct answer. All I know is that, for me, Perl's great strength is XS and Perl 6 doesn't have that.

    Cheers,
    Rob
      But Perl 6 has the Native Calling Interface which allows you to "Call into dynamic libraries that follow the C calling convention". This means that if you're using XS for accessing external libraries, you won't have to use XS. Which I think a lot of people would see as a plus. For example, this is the code to interface with the C-function ctime:
      use NativeCall; sub the-time(Int() $it = time) { # coerce to Int, cu +rrent time default sub ctime(int64 is rw --> Str) is native {*}; # the actual interf +ace my int $time = $it; # the rest is synta +ctic sugar, really. ctime($time) }; # the actual call i +nto the C-library } say the-time; # Sun Jul 15 17:05:34 2018
      And if you want to interface with your own C-code: turn it into a small library and call that using NativeCall. The t/04-nativecall directory contains several examples of how to do this. All in all, I'd say not having XS is a plus, rather than a minus. As it is XS out there in the wild, that is keeping Perl 5 from advancing in the multi-threaded world. Which is also why Perl 5 ithreads continue to have scalability issues for the past 15 years!
        All in all, I'd say not having XS is a plus, rather than a minus

        Yes, not everyone views XS favourably. That's ok, I'm not going to try to convince you otherwise.
        But that's not my view.

        Cheers,
        Rob
        But Perl 6 has the Native Calling Interface which allows you to "Call into dynamic libraries that follow the C calling convention".

        I only just noticed - that seems to imply that the Native Calling Interface is for use with "dynamic libraries" only.
        Hopefully there'd also be an interface to static libs ? (It's no big deal to me ... I'm simply curious about it.)

        Cheers,
        Rob
        Which is also why Perl 5 ithreads continue to have scalability issues for the past 15 years!

        That statement is as wrong today, as the post you've attached it to was wrong, when you wrote it 15 years ago.

        The only scalability issue with iThreads is the implementation (not the model) of shared memory aggregates.

        Proof: The following simple demo code starts ARGV[0] threads that each lock/increment/release a shared scalar every 1/100th of second $ARGV[1] times:

        #! perl -slw use threads stack_size => 4096; use threads::shared; $|++; sub usleep{ select'','','',$_[0] } my $count :shared = 0; sub doit{ do{ lock $count; printf "\r[%u] %u\t", threads->tid, ++$count; usl +eep 0.01 } for 1 .. $_[0]; } my @t = map threads->create( \&doit, $ARGV[1] // 300 ), 1 .. $ARGV[ 0 +]; $_->join for @t; print $count;

        And a run:

        C:\test>t-stress 3000 100 300000

        That runs in a tad over 2GB, and once all 3000 threads are running -- a matter of a few seconds -- it consumes less that 1% cpu. That's as, if not more, scalable than any true (kernel) threading interpreted language as I know of, and better than many fully (native) compiled languages.

        The fact that you wrote that despicable document without having the understanding to realise what a steaming pile it was, is lamentable.

        The fact that 15 years on you haven't learnt enough to realise your mistake and are still promoting it; would be laughable if it wasn't so beyond the pale.

        The fact that you are apparently designated (in large part) for specifying the multi-tasking in P6 -- despite being responsible for this other steaming pile of abandonware -- would be scary as well as irresponsible; were it not for the fact that P6 will never challenge even AppleScript or Logo for performance, and is thus useless for anything in the real world; so your brand of throw-in-everything-including-the-kitchen-sink programming will likely never be a serious bottleneck, cos no one will ever use it.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
        In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
          A reply falls below the community's threshold of quality. You may see it by logging in.

      At the time it was "named" no one expected it to take so damn long and stray so far off the original. No lack of faith or intent to piggy-back on an established trademark. Originally it was supposed to be a new, improved and slightly incompatible version of the same language and all would be well if it worked out like that.

      Jenda
      Enoch was right!
      Enjoy the last years of Rome.