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

Why I’m Learning Perl 6

evanmiller.org

Post reply on HN
Print view View original

151–160 of 380 posts

Re: Why I’m Learning Perl 6

#151

Post by smitherfield »

kbenson wrote: post #150
smitherfield wrote: post #141

Earlier quoted context omitted.

Edit: I mistakenly read "OS-level threads" again where s/he said "application level threads" in the quote. > For others, application level threads don't achieve the parallelism requires to efficiently use the hardware available. You've got this backwards: OS-level threads execute in parallel (or, rather, may be executed in parallel), while green threads spawned within the same OS-level thread execute sequentially on…

I think you missed where I linked "application" threads to "green" threads, as opposed to OS level threads.

My apologies; I read your comment too quickly.

Re: Why I’m Learning Perl 6

#152

Post by dmytrish »

bloobloobloo wrote: post #133
Rjevski wrote: post #28

My personal issue with Perl is how much of a mess the syntax is (10 different ways of doing the same thing), and the lack of a standard library (CPAN is not a viable replacement).

> 10 different ways of doing the same thing Mostly an urban myth. Where it isn't, at least 8 of those ways are actually important. Exercise: write a python program that prints Python's quoting documentation, without external files, without editing the documentation. Spoiler alert: it's impossible.

So, how exactly these different ways of getting sub arguments are useful?

    sub add1 {
        my ($arg1, $arg2) = @_;
        $arg1 + $arg2;
    }

    sub add2 {
        my $arg1 = shift;
        # possibly two screens of dense code here, then
        my $arg2 = shift;
        $arg1 + $arg2;
    }

    sub add3 {
        $_[0] + $_[1]
    }

    # There may be some other ways to extract arguments 
    #  that I am not aware of.
    # It's possible to combine any of the methods!
And this is just argument access, one of the core language primitives.

Re: Why I’m Learning Perl 6

#153

Post by kbenson »

Sean1708 wrote: post #122
hpcjoe wrote: post #76

Earlier quoted context omitted.

I find it somewhat humorous that more than 25 years on, we are effectively reverting to static linking and bundling [1]. Way ... way back in the day, the argument was it would save memory, encourage reuse, etc. While some of this may have been true, it also gave rise to dynamic library hell. Reuse was overshadowed by incompatible versions, or API changes between versions that became the stuff of legends. This would m…

> Way ... way back in the day, the argument was it would save memory ... it also gave rise to dynamic library hell. Could you expand a bit on how static linking would cause either of those things? It seems to me that they are both consequences of dynamic linking.

I think "the argument" being referred to was the push for dynamic linking, and the consequences in question are for dynamic linking. I think there was just a somewhat unclear implicit shift in the subject.

Re: Why I’m Learning Perl 6

#154

Post by bigleagueposter »

krylon wrote: post #138
athenot wrote: post #131

I'm glad Perl6 finally went the route of MoarVM. I always felt that ParrotVM (which was supposed to also run Python and Ruby) was a terrible distraction and scope creep. The idea was laudable but it would have required buy-in from the other communities. As much as I like Perl, I don't think that would have been fair to them, as Python and Ruby have evolved into their own respective identities.

> The idea was laudable but it would have required buy-in from the other communities But imagine how cool it would have been - write a class in Python, sub-class it from Ruby, use that subclass in a function written in Perl, call that function from Lua code... Okay, I see it now. It was just too awesome for its time. Maybe in a hundred years or so...

JVM is now becoming what Parrot was intended to be with Graal/Truffle.

Re: Why I’m Learning Perl 6

#155

Post by fundabulousrIII »

fusiongyro wrote: post #116
totalperspectiv wrote: post #68

Earlier quoted context omitted.

I hadn't heard of Tcl before but it looks awesome! What do you find its ideal use cases to be?

Tcl is pretty old. A lot of the territory it covered well is now better covered by other things. One of its great strengths was being extensible. It's pretty easy to bake some functionality into Tcl and provide a new shell with it. This is what expect ( http://expect.sourceforge.net/ ) is, for instance. Another early advantage of Tcl was Tk, which provided Tcl extended with GUI stuff. Tk was cross-platform and establ…

Old is relative. There is a good core dev community and recent development is promising. It's interesting you mention Lua because that is a language I picked up when looking to move from Tcl at some point in the last 8 years. I decided rather quickly against that.

The reason is the swig bindings for Tcl are sufficient to generate decent package cores for just about anything I care to extend and I can optimize later.

Re: Why I’m Learning Perl 6

#156

Post by bigleagueposter »

oconnor663 wrote: post #59
rurban wrote: post #10

Earlier quoted context omitted.

GIL less yes, but not lockless. The previous perl6 VM, parrot, had lockless threads, scaling linearly per native core. MoarVM even needs to lock on hash or array accesses, which is certainly not state of the art.

How did parrot write arrays from multiple threads without a lock somewhere in there?

The parrot threads didn't communicate with each other and you could wait until all of them finished. They provided a tiny subset of the functionality real threads offer but in a more efficient way.

Re: Why I’m Learning Perl 6

#157

Post by fundabulousrIII »

le-mark wrote: post #101
totalperspectiv wrote: post #68

Earlier quoted context omitted.

I hadn't heard of Tcl before but it looks awesome! What do you find its ideal use cases to be?

TCL is pretty old school and doesn't get a lot of attention nowadays. The main use I'm aware of is in BigIP F5 config files. There are some really interesting things about it though, for example how control flow constructs (if/else, while) are implemented as commands, using built in uplevel and upvar [1] commands to control the scope of the currently executing code. Some people say it's lisp-like, that's one of the t…

upvar and uplevel are also the only parts of the language that I do not use in production scripting. They have their place. It is not in end user space.

Re: Why I’m Learning Perl 6

#158

Post by sigzero »

fusiongyro wrote: post #116
totalperspectiv wrote: post #68

Earlier quoted context omitted.

I hadn't heard of Tcl before but it looks awesome! What do you find its ideal use cases to be?

Tcl is pretty old. A lot of the territory it covered well is now better covered by other things. One of its great strengths was being extensible. It's pretty easy to bake some functionality into Tcl and provide a new shell with it. This is what expect ( http://expect.sourceforge.net/ ) is, for instance. Another early advantage of Tcl was Tk, which provided Tcl extended with GUI stuff. Tk was cross-platform and establ…

I just purchased the new book by Ashok myself that covers Tcl (not Tk) 8.6. I have always thought Tcl a fun language and have decided to more of my daily stuff with it. I hang out on the developers list just to watch what is going on.

Re: Why I’m Learning Perl 6

#159

Post by petepete »

bjd2385 wrote: post #67
forinti wrote: post #38

Earlier quoted context omitted.

Perl 6 still has to overcome Perl 5, which is everywhere and is a great language. I never get around to using Perl 6 because 5 is already there in every Linux distribution.

I wish Linux distros shipped with more recent language versions, e.g. Python 3.6 and Perl 6 in addition to just 3.4/5 and 5. I understand that it's not their job to try and push people to update their language skills, but it'd be nice to have access to them right off the bat if they feel like it.

Some do.

https://www.archlinux.org/packages/extra/x86_64/python/

Re: Why I’m Learning Perl 6

#160

Post by kbenson »

dmytrish wrote: post #152
bloobloobloo wrote: post #133

Earlier quoted context omitted.

> 10 different ways of doing the same thing Mostly an urban myth. Where it isn't, at least 8 of those ways are actually important. Exercise: write a python program that prints Python's quoting documentation, without external files, without editing the documentation. Spoiler alert: it's impossible.

So, how exactly these different ways of getting sub arguments are useful? sub add1 { my ($arg1, $arg2) = @_; $arg1 + $arg2; } sub add2 { my $arg1 = shift; # possibly two screens of dense code here, then my $arg2 = shift; $arg1 + $arg2; } sub add3 { $_[0] + $_[1] } # There may be some other ways to extract arguments # that I am not aware of. # It's possible to combine any of the methods! And this is just argument acce…

> So, how exactly these different ways of getting sub arguments are useful?

Because in the second (add2), you might do something interesting with the second (or third) arguments depending on the first. You might have optional arguments. Your arguments might be a list of items you don't know the size of. It allows you to develop what you need out of the extensible core mechanism. Modules can and have built on that.

> # There may be some other ways to extract arguments

There are. Now you can just do

    sub add( $arg1, $arg2 ) {
        $arg1 + $arg2;
    }
My personal favorite is to use Function::Parameters[1]

    fun add( Num $arg1, Num $arg2 ) {
        $arg1 + $arg2;
    }
which allows named params, type constraints (runtime), default params, etc.

1: https://metacpan.org/pod/Function::Parameters

Post reply on HN