Live data from Hacker News

Perl - the Detroit of scripting languages

speakerdeck.com

31–40 of 100 posts

Re: Perl - the Detroit of scripting languages

#31

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…

Ruby ... fixes everything about perl5 that annoys me, except that Ruby's OO and metaprogramming is weak sauce compared to Moose (written by the presenter of these slides).

Without a proper role system, I can't replicate a lot of my designs. Without a proper meta-model, I can't write attribute traits to extend the OO system when I need to.

So any time a ruby program of mine gets large enough to need a significant number of classes, it gets ported back to perl5 first so I can do it properly.

If you want something lightweight to experiment, try looking at Moo (written by me for smaller projects) - you may find that declarative attribute definitions, method modifiers and roles become very addictive very quickly :)

Re: Perl - the Detroit of scripting languages

#32
post #2

In perl5 : - I can have a prototype running in a matter of minutes - I have access to a vast library of modules doing everything I need (which helps the former) - I write quick and efficient code Do I really care about what other people think about the languages and tools I use? No. However, I do care about efficiency and results And, uh, working with a language that has been out for tens of years makes me believe my…

> That's a cheap place to bootstrap a business for sure.

Depends on what you're willing to give up. Emergency response time can be pretty important.

Re: Perl - the Detroit of scripting languages

#33
post #32
post #2

In perl5 : - I can have a prototype running in a matter of minutes - I have access to a vast library of modules doing everything I need (which helps the former) - I write quick and efficient code Do I really care about what other people think about the languages and tools I use? No. However, I do care about efficiency and results And, uh, working with a language that has been out for tens of years makes me believe my…

> That's a cheap place to bootstrap a business for sure. Depends on what you're willing to give up. Emergency response time can be pretty important.

Especially in a city that is consistently in the top-5 most violent cities in the U.S.

(disclaimer: I live in Flint, MI, another of those top-5 cities)

Re: Perl - the Detroit of scripting languages

#34
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…

C?

Re: Perl - the Detroit of scripting languages

#35
post #3
post #2

In perl5 : - I can have a prototype running in a matter of minutes - I have access to a vast library of modules doing everything I need (which helps the former) - I write quick and efficient code Do I really care about what other people think about the languages and tools I use? No. However, I do care about efficiency and results And, uh, working with a language that has been out for tens of years makes me believe my…

I can have a prototype running in a matter of minutes That's the case for any microframework whose language you're comfortable in. BTW, Maybe buying a home in Detroit (especially now that it's officially bankrupt and will hopefully be able to break out of the unions commitments) would be a good business move? That's a cheap place to bootstrap a business for sure. Not really because part of having a business is stayin…

For the record, I know plenty of alive people in Detroit :)

Re: Perl - the Detroit of scripting languages

#36
post #13

Earlier quoted context omitted.

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

> That is already the reality of Python and Ruby.

And, Common Lisp and Scheme and Java and C and C++ and SQL and Pascal and BASIC and C# and JavaScript and ... pretty much every language that is (or ever has been) both popular enough to have interest enough to support multiple implementations and not proprietary to a single vendor.

Re: Perl - the Detroit of scripting languages

#38
post #37
post #17

Earlier quoted context omitted.

Whose irony tag are you closing? I looked at the page source and couldn't find an opening irony tag.

[deleted]

The joke wasn't lost on me, it's just a super-tired slashdot era thing that needs to die.

Re: Perl - the Detroit of scripting languages

#39
post #5
post #2

In perl5 : - I can have a prototype running in a matter of minutes - I have access to a vast library of modules doing everything I need (which helps the former) - I write quick and efficient code Do I really care about what other people think about the languages and tools I use? No. However, I do care about efficiency and results And, uh, working with a language that has been out for tens of years makes me believe my…

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.

The Alioth benchmarks do a really bad job of capturing the reality of language-related performance issues. The choice of specified algorithm is going to dominate all other concerns in their benchmark, and that's not the sort of problem people face in the real world, perhaps out of rarefied HPC circles where benchmarks on one quad-core machine aren't relevant to anything.

Performance handling in high level languages is more about knowing where the landmines are (total heap usage in GCed languages, various troublesome malloc()s, weird caches in dynamic languages...) and trying to figure out as quickly and cheaply as possible if the program you're planning on writing is going to hit them, and how much it's going to cost to mitigate it. It's not relevant if the actual runtime overhead of the problem is 5% or 1000x, the end product is either fast enough or it isn't, and the workaround is either viable or it isn't.

Trying to protect yourself from this by picking the fastest language in a shootout isn't going to work because the perfect, gotcha-free language hasn't been invented yet. There are sound performance reasons to avoid any language, not just Perl.

Re: Perl - the Detroit of scripting languages

#40
post #25
post #21

Earlier quoted context omitted.

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

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.
Post reply on HN