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

Perl - the Detroit of scripting languages

speakerdeck.com

Post reply on HN
Print view View original

91–100 of 100 posts

Re: Perl - the Detroit of scripting languages

#91

Post by marpmarpmar »

TylerE wrote: post #90
meepmeepmeepmee wrote: post #88

Earlier quoted context omitted.

I'll happily explain, thanks for asking. First off, in Perl the parens for a function call are not mandatory. As such it is very useful for functions and variables to be visually difference, especially when you're using functions to generate parameters for other functions without any temp variables inbetween. my W = qq_mult ConjugateQ, qv_mult RotationQ, Vector; You can't tell at a glance what's going on and will nee…

> You can't tell at a glance what's going on and will need to > look carefully. Adding sigils makes it quite clear: > my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector; Actually, that's clear as mud. Is this a function call of 3 arguments? Function composition/chaining, an array of 3 items?

You're right. I did not explain that well enough. Even with sigils it is unclear whether qv_mult will take 1 or 2 arguments, or whether qq_mult will take 1, 2 or 3. What is however clear is that only qq_mult and qv_mult are function calls, which it previously was not. Worse, what i did not mention then: When reading carefully it was easy to tell that they had to be function calls; however it was impossible to tell whether the two quaternions and the vector were variables, or function calls that did not take any arguments. Only with sigils becomes this clear.

Re: Perl - the Detroit of scripting languages

#92

Post by TylerE »

marpmarpmar wrote: post #91
TylerE wrote: post #90

Earlier quoted context omitted.

> You can't tell at a glance what's going on and will need to > look carefully. Adding sigils makes it quite clear: > my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector; Actually, that's clear as mud. Is this a function call of 3 arguments? Function composition/chaining, an array of 3 items?

You're right. I did not explain that well enough. Even with sigils it is unclear whether qv_mult will take 1 or 2 arguments, or whether qq_mult will take 1, 2 or 3. What is however clear is that only qq_mult and qv_mult are function calls, which it previously was not. Worse, what i did not mention then: When reading carefully it was easy to tell that they had to be function calls; however it was impossible to tell wh…

I'm still unclear on what the dataflow is... is w set to the value of the qq_mult call and the rest just executed for side effects?

Regardless, please defend how that is not just an improvement over, but better than, say:

    my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector;

    w = qq_mult(qv_mult(CondugateQ, Vector))
or whatever the precedence and dataflow semantics are

Re: Perl - the Detroit of scripting languages

#93

Post by marpmarpmar »

TylerE wrote: post #92
marpmarpmar wrote: post #91

Earlier quoted context omitted.

You're right. I did not explain that well enough. Even with sigils it is unclear whether qv_mult will take 1 or 2 arguments, or whether qq_mult will take 1, 2 or 3. What is however clear is that only qq_mult and qv_mult are function calls, which it previously was not. Worse, what i did not mention then: When reading carefully it was easy to tell that they had to be function calls; however it was impossible to tell wh…

I'm still unclear on what the dataflow is... is w set to the value of the qq_mult call and the rest just executed for side effects? Regardless, please defend how that is not just an improvement over, but better than, say: my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector; w = qq_mult(qv_mult(CondugateQ, Vector)) or whatever the precedence and dataflow semantics are

That example doesn't show it very well. To be clear: The intended advantage is: Parens are optional. That permits syntax like the following to be implemented in pure Perl without changing the parser:

    try {
        die "foo";
    }
    catch {
        warn "caught error: $_";
    };
If parens were mandatory, it would need look like this:

    try(
        sub {
            die "foo";
        }
        catch(
            sub {
                warn "caught error: $_";
            }
        )
    );
Having the nicer form in the first example is possible only because sigils are mandatory, along with auto-flattening variables and easy code highlighting.

As for the example, with mandatory parens it would look like this:

    w = qq_mult( ConjugateQ, qv_mult( RotationQ, Vector ) );
In production i'd write it like this:

    my $W = qq_mult $ConjugateQ, qv_mult( $RotationQ, $Vector );
That gives a nice balance between a low number of parens, and clarity of intent.

Re: Perl - the Detroit of scripting languages

#94

Post by nmcfarl »

TylerE wrote: post #40
nmcfarl wrote: post #25

Earlier quoted context omitted.

That kind of shows my point. (Although not as well as some of the others.) On that particular benchmark Perl is faster than the fastest JRuby, and Python benchmarks. And faster than 11 other benchmarks, but the secondary perl benchmark program is the slowest of the bunch...

It's a log scale though, so it doesn't capture the magnitude of how much slower it is. When your argument is that you're 100x instead of 103x slower than C, that's not very convincing.

Not if it matters much, but I have no problem with the argument that some things should be written in C or on top of the JVM for performance reasons.

My problem is with people claiming that some popular scripting language, say Ruby, is massively faster than all the rest. Which as a general rule is simply not true (although it may be the cases, for some well defined set of problems).

Re: Perl - the Detroit of scripting languages

#95

Post by berntb »

fusiongyro wrote: post #87
berntb wrote: post #83

Earlier quoted context omitted.

>>That you can build an OO system comparable to what other languages have built-in My explicit point was that it is better [edit: which was an answer to your question about value from flexibility, compared to the cognitive cost], don't do straw man attacks please. ( Are you trolling?) Edit: Thanks for the downvote. :-) Edit 2: As answer to the next long, long comment with parts going all over: Of course complexity ha…

When someone says two systems are comparable, it is a different claim than that two systems are equivalent. In order for something to be better than something else they have to be comparable. Dynamic typing can be better than static typing only because they're both approaches to typing (please don't confuse this example with an opinion); static typing cannot be better than lexical scope because they're not comparable…

>> surely you do not believe one must learn a language inside out before knowing whether it is appropriate to a domain.

You had a hard opinion about something you admitted you don't know. That is just not a serious position.

>>We're talking about the cost/benefit of flexibility

Of course it has a cost with flexibility. The same goes for lisp variants, which have an even larger flexibility than Perl in the macro system. Since you claim to know many other systems than Python, you should know this...?

Every design choice have costs/benefits. You don't need to repeat that trivial point as if it is news.

(That you think another OO system is better without knowing both says more about you than anything else.)

And now you argue that because you (allegedly) know other stuff, your opinion is relevant?

(Why don't you go argue that the flexibility of easily reprogrammable syntax is bad with Lisp people instead? If Perl is bad according to you, their life must be Hell?)

(And fyi, re niches, all the scripting languages are very similar in capabilities and fill mostly the same niche. That is why we see so many language wars trolls from the aggressive language communities. But I think you know this.)

Re: Perl - the Detroit of scripting languages

#96

Post by fusiongyro »

berntb wrote: post #95
fusiongyro wrote: post #87

Earlier quoted context omitted.

When someone says two systems are comparable, it is a different claim than that two systems are equivalent. In order for something to be better than something else they have to be comparable. Dynamic typing can be better than static typing only because they're both approaches to typing (please don't confuse this example with an opinion); static typing cannot be better than lexical scope because they're not comparable…

>> surely you do not believe one must learn a language inside out before knowing whether it is appropriate to a domain. You had a hard opinion about something you admitted you don't know. That is just not a serious position. >>We're talking about the cost/benefit of flexibility Of course it has a cost with flexibility. The same goes for lisp variants, which have an even larger flexibility than Perl in the macro syste…

All this discussion is doing is illustrating your rescue-dog mentality. Don't worry, I won't waste another second on Perl. Enjoy your Detroit, you guys have earned it.

Re: Perl - the Detroit of scripting languages

#97

Post by berntb »

fusiongyro wrote: post #96
berntb wrote: post #95

Earlier quoted context omitted.

>> surely you do not believe one must learn a language inside out before knowing whether it is appropriate to a domain. You had a hard opinion about something you admitted you don't know. That is just not a serious position. >>We're talking about the cost/benefit of flexibility Of course it has a cost with flexibility. The same goes for lisp variants, which have an even larger flexibility than Perl in the macro syste…

All this discussion is doing is illustrating your rescue-dog mentality. Don't worry, I won't waste another second on Perl. Enjoy your Detroit, you guys have earned it.

Your "classy" insults aren't exactly screaming non-troll.

If you really are a non-troll wanting to seriously discuss a subject's pro/con, don't start with insults and then act innocent. I was polite to the first dozen language war trolls on HN claiming things were shit they have no clue about. That was a long time ago.

(Also, the net is full with Moose info -- I gave you my favorite reference and suggested you'd ask others. If you really wanted to read about roles, typing of attributes etc and build a serious opinion.)

PS For the third time: Have fun explaining to Lisp people your theories about flexibility's cost being too high. I'd love to see your insults to their reaction... DS

Re: Perl - the Detroit of scripting languages

#98

Post by Mithaldu »

berntb wrote: post #83
fusiongyro wrote: post #74

Earlier quoted context omitted.

I'm arguing that flexibility has a cost, and unless you can show me a tangible benefit, it's unnecessary cost. That you can build an OO system comparable to what other languages have built-in is a compelling demonstration of the extent of the flexibility, but it isn't a compelling demonstration of the need for the flexibility. Surely you have better examples of the extensibility of the language than stealing well-und…

>>That you can build an OO system comparable to what other languages have built-in My explicit point was that it is better [edit: which was an answer to your question about value from flexibility, compared to the cognitive cost], don't do straw man attacks please. ( Are you trolling?) Edit: Thanks for the downvote. :-) Edit 2: As answer to the next long, long comment with parts going all over: Of course complexity ha…

Actually, the Moose PDF is still the one i link to when necessary. However lately i've switched to simply linking to http://perl-tutorial.org and pointing out the relevant bits.

Re: Perl - the Detroit of scripting languages

#99

Post by [deleted] »

Mithaldu wrote: post #72
TylerE wrote: post #60

Earlier quoted context omitted.

> easy to read as Perl. So, that rules out Brainf--k I guess

Yes that is correct. Brainfuck is not as readable as Perl. (I think you need to train more with your witty comebacks. Also drop the meme that Perl is not very readable, when it has lately improved a LOT [1] in that regard.) [1] https://metacpan.org/module/Moo#SYNOPSIS

[deleted]

Re: Perl - the Detroit of scripting languages

#100

Post by pyre »

berntb wrote: post #70
tbrownaw wrote: post #51

Earlier quoted context omitted.

How so? Shell scripts are for things that have almost no logic besides running other programs. Perl is for things that do have internal logic, and aren't big enough for the lack of formal function parameters to be an issue. Java is for things that talk to the database (or need other libraries, such as for reading/writing Excel files), or are too large to keep in my head all at once (most of which talk to the database…

>>Perl [...] lack of formal function parameters http://search.cpan.org/~barefoot/Method-Signatures-20130222/... (And others on CPAN.) >> [C for suid flag] Afaik, you should be able to use anything for suid stuff.

There's a general idea that compiled programs are safer for the SUID flag because it's 'easier' to hijack a script (running in an interpreter) to execute arbitrary code than code that's compiled to machine language.
Post reply on HN