Live data from Hacker News

Perl - the Detroit of scripting languages

speakerdeck.com

21–30 of 100 posts

Re: Perl - the Detroit of scripting languages

#21
post #18
post #5

Earlier quoted context omitted.

I challenge your efficiency claims. The benchmarks just do not support. I mean, roughly in parity with Python and PHP, 20x slower than Clojure on average, 30x slower than Haskell, and on many tasks 100x slower than C. Over the whole bredth of the Alioth shootout programs, Perl trades places with JRuby as the slowest tested language.

When I look Alioth I really don't see this, particularly the "slowest but JRuby" claim. What is your methodology? --- Edit: What I do see is all the fastest test program for the interpreted languages, ruby, python, etc are all trading places for the slowest language - the differences seem to be completely minimal. (As there seem to be more perl test programs per benchmark the slowest of them is often near the bottom…

Look at e.g. http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... and flip through the various benchmarks

Re: Perl - the Detroit of scripting languages

#22
post #11
post #7

Earlier quoted context omitted.

tl;dr:   The talk might have been different, but there is nothing of substance in the slides.

I haven't even looked at these since it doesn't interest me, but I think posting slides is kind of bizarre: if they're done properly, there shouldn't be anything much of substance in them.

Generally at this point the only reason I post slides at all is for people to leave open and click along while they're watching a video of the talk.

Re: Perl - the Detroit of scripting languages

#23
To add two different thoughts:

* Perl is widely used and has inspired many other languages. These are not small accomplishments.

* How many major revision bumps can a language undergo before it loses its identity? How many breaking changes are allowed before it becomes something else? Perhaps the name is about something more than the language as crystallized at any one point in time? But how do you convey that to the community as the language changes?

Re: Perl - the Detroit of scripting languages

#24

For me, the biggest pros for Perl were it's extreme expressiveness and the power of CPAN. However, it wasn't without it's warts - odd threading, weird sub signatures, faked OO, etc .. I've spent a lot of time explaining the nuances of these warts to others, which only made me realize how serious these issues are. I was sold on the promises of this thing they were calling Perl 6, that was supposed to break backwards c…

You got two things wrong there: > weird sub signatures No core signatures, but modules on CPAN that make signatures available. > faked OO The OO in Perl works almost identically to the one in Python, and i assume Ruby is similar too. The difference is that OO syntax sugar is implemented in core in Python and Ruby, while in Perl it is implemented in Perl directly and available on CPAN but in core. There's nothing fake…

> The difference is that OO syntax sugar is implemented in core in Python and Ruby, while in Perl it is implemented in Perl directly

I see what you mean. However, that syntax sugar is what people are used to from other OO implementations. Lacking that sugar meant that I found myself regularly explaining the workings of blessed hashes.

Re: Perl - the Detroit of scripting languages

#25
post #21
post #18

Earlier quoted context omitted.

When I look Alioth I really don't see this, particularly the "slowest but JRuby" claim. What is your methodology? --- Edit: What I do see is all the fastest test program for the interpreted languages, ruby, python, etc are all trading places for the slowest language - the differences seem to be completely minimal. (As there seem to be more perl test programs per benchmark the slowest of them is often near the bottom…

Look at e.g. http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... and flip through the various benchmarks

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...

Re: Perl - the Detroit of scripting languages

#26
post #21
post #18

Earlier quoted context omitted.

When I look Alioth I really don't see this, particularly the "slowest but JRuby" claim. What is your methodology? --- Edit: What I do see is all the fastest test program for the interpreted languages, ruby, python, etc are all trading places for the slowest language - the differences seem to be completely minimal. (As there seem to be more perl test programs per benchmark the slowest of them is often near the bottom…

Look at e.g. http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... and flip through the various benchmarks

When flipping through them, note that Perl is consistently faster than other dynamic languages when dealing with text while also being very concise in code (generally a sign for code that can be written quickly).

Re: Perl - the Detroit of scripting languages

#27
post #5

Earlier quoted context omitted.

I challenge your efficiency claims. The benchmarks just do not support. I mean, roughly in parity with Python and PHP, 20x slower than Clojure on average, 30x slower than Haskell, and on many tasks 100x slower than C. Over the whole bredth of the Alioth shootout programs, Perl trades places with JRuby as the slowest tested language.

Well, what does "efficient" actually mean here? I like Perl (for medium-small programs) because it's quick to write, doesn't require lots of boilerplate like Java does, and allows a much more direct translation of my intent than shell scripts do.

Personally, if sounds like you need to expand your horizons if you feel that Perl is mostly competing with Java or shell scripts as the best language for the job.

Re: Perl - the Detroit of scripting languages

#28

Earlier quoted context omitted.

You got two things wrong there: > weird sub signatures No core signatures, but modules on CPAN that make signatures available. > faked OO The OO in Perl works almost identically to the one in Python, and i assume Ruby is similar too. The difference is that OO syntax sugar is implemented in core in Python and Ruby, while in Perl it is implemented in Perl directly and available on CPAN but in core. There's nothing fake…

> The difference is that OO syntax sugar is implemented in core in Python and Ruby, while in Perl it is implemented in Perl directly I see what you mean. However, that syntax sugar is what people are used to from other OO implementations. Lacking that sugar meant that I found myself regularly explaining the workings of blessed hashes.

Yes, that is true. I only meant to correct your use of fake. In the past OO was a holy pain in the behind in Perl. However, nowadays that has changed considerably, and with Moo [1] we have a reliable, pure perl, fast, and easy-to-use sugar layer for OO. :)

[1] https://metacpan.org/module/Moo#SYNOPSIS

Re: Perl - the Detroit of scripting languages

#29
post #10
post #5

Earlier quoted context omitted.

I challenge your efficiency claims. The benchmarks just do not support. I mean, roughly in parity with Python and PHP, 20x slower than Clojure on average, 30x slower than Haskell, and on many tasks 100x slower than C. Over the whole bredth of the Alioth shootout programs, Perl trades places with JRuby as the slowest tested language.

Most of what I do involves loading text files with fixed width records. A file is between 500M and 4Gb. Then I do things with these records. So far I have not found anything faster than perl unpack (1), but I would be happy to. I plan to investigate Go soon. Would you have another suggestion? 1 : or marginally faster, with the advantages negated by the time it takes to write the code. However, a 10x improvement would…

Well that's great... For your very narrow use case.. It is not however an effective rebuttal to the points brought up in a more general case.

Re: Perl - the Detroit of scripting languages

#30
post #13
post #6

tl;dr - the author wants someone to re-write Perl 5 and CPAN to add some features he likes and remove some features he doesn't like.

My tl;dr - The author says people are currently writing "perls" that add features that he likes and remove features that he doesn't like - and he would like us all to consider them all the perl not just the one binary. IE the future of perl is many runtimes, that are slightly incompatible.

> IE the future of perl is many runtimes, that are slightly incompatible.

That is already the reality of Python and Ruby. ;)

Post reply on HN