6 ms·

For a general-purpose problem, Perl won't be particularly fast. For a Perl-type problem (scanning and parsing big files), Perl is very fast. Doing a Perl-type

by cleaver 12y ago

For a general-purpose problem, Perl won't be particularly fast. For a Perl-type problem (scanning and parsing big files), Perl is very fast. Doing a Perl-type problem in a general-purpose language would be considerably slower. However, Python or others will perform much better in the "can I read my own code six months later" benchmark.

csirac2 12y ago
I don't know why I always have to chip in on "perl is unreadable lol" comments, but over the last 8 years apart from a steady trickle of C coding here and there the bulk of my dayjob has moved around from C/Verilog, then I discovered Ruby, then Perl/R/Python, to full-time Python now. It's true that unsupervised, weak coders using perl turn out worse code than in other languages. But it really doesn't take much to produce good code if you have a tiny bit of supervision/discipline (which stems mostly from 80% of perl tutorials on the web are teaching 1997-era perl anti-patterns). And/or if you happen to be a stronger programmer in something else, hopefully you stumble across perlcritic and modern perl patterns more quickly. Well-written Moose code involves less boilerplate, the declarative nature and composability of classes, types and data members with free type/value validation is a delight to maintain, and results in more robust code with a lot fewer silent failures (or objects happily chugging along silently with invalid state) than typical Python classes. Of course, now that I can't use Moose and the Python community actively seems to discourage the very thought of relying on any superset of core Python OO features like enthoughts' traits package - I really want to revisit static/stronger typed programming languages for large projects. So it feels like I've come full-circle in my programming career...
- pwr22 12y ago
  Well said :). I like Perl but when I write it I'm aiming above all for readability
- Cyther606 12y ago
  Check out Nim. import rdstdin, strutils let time24 = readLineFromStdin("Enter a 24-hour time: ").split(':').map(parseInt) hours24 = time24[0] minutes24 = time24[1] flights: array[8, tuple[since: int, depart: string, arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."), (583, "9:43 a.m.", "11:52 a.m."), (679, "11:19 a.m.", "1:31 p.m."), (767, "12:47 p.m.", "3:00 p.m."), (840, "2:00 p.m.", "4:08 p.m."), (945, "3:45 p.m.", "5:55 p.m."), (1140, "7:00 p.m.", "9:20 p.m."), (1305, "9:45 p.m.", "11:58 p.m.")] proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int = hours * 60 + minutes proc cmpFlights(m = minutesSinceMidnight()): seq[int] = result = newSeq[int](flights.len) for i in 0 .. <flights.len: result[i] = abs(m - flights[i].since) proc getClosest(): int = for k,v in cmpFlights(): if v == cmpFlights().min: return k echo "Closest departure time is ", flights[getClosest()].depart, ", arriving at ", flights[getClosest()].arrive https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers
  - rdtsc 12y ago
    If I had to guess speed is pretty close to C, right. Nim is pretty awesome and has been around for a while. I wish one of big entities out there Google, Mozilla, Microsoft, Apple would have adopted Nim and ran with it instead of inventing their own langauges.
    - bjz_ 12y ago
      At the time when Go and Rust were conceived Nim would have certainly not been on their radar. Both were announced in 2009, at a time when the Nimrod repository had barely even got off the ground[0]. And Nim doesn't really address one of Apple's chief concerns: smoothly transitioning away from Objective-C. [0]: https://github.com/Araq/Nimrod/graphs/contributors https://github.com/Araq/Nimrod/graphs/contributors
- fidotron 12y ago
  Last time I used Perl it went badly, but it was a typical hacked up mess. For someone mainly in the Python/Java/C++ world is Moose something worth looking at as a mind expansion exercise? Your description makes it sound appealing. And, dare I ask, what about Perl 6?
  - csirac2 12y ago
    I want to write something concise and coherent, but it's not happening today :) Instead, assuming you've read the teasers in the Moose manual [1] I'd recommend this [2] interesting comparison of how horizontal code re-use can be achieved in Java, Ruby, PHP and Perl+Moose. There's more philosophical/winding essays on Moose from Chromatic, for example at [3]. Roles/traits/method modifiers/MOP/composability etc. are all great things for getting more reusability... however (and this might sound stupid) the thing that saddens me most when writing Python code is when I find myself adding a bunch of asserts or adding program logic "manually" in situations where I'd normally specify that sort of thing declaratively in a Moose class definition or by referring to a centrally managed Type or delegate stuff through attribute features. On the other hand, I'm barely into year 2 of full-time Python dev, so perhaps I've yet to find the idiomatic way of doing Python things I used to take for granted in Moose. Regarding Perl 6, I don't know much about it, except that the original authors of Moose had some inspiration from it. Is picking up Perl+Moose mind-expanding? It was for me, but I feel that what Moose gave me in Perl was a bit of a band-aid over the fact that it's such a malleable open-ended dynamic language. So as a C++/Java programmer this aspect might not be so enlightening to you, except to see how Moose achieves it in a pretty painless way that I think is very nice and idiomatic for a dynamic language (with the caveats that brings). To put it another way: it gives Perl some of the great benefits of properly declaring things up-front, without the boilerplate/inflexibility pain that I perceive the Java ecosystem's bureaucracy to be (I haven't touched Java for 10 years, so take that with a grain of salt). If you want to explore some Moose-ish kinds of things within Python, check out [4] (there's another Moose clone in Python that's similarly inactive, sadly) and [5] (Enthought's stuff is perhaps a bit too heavy and incomplete to be the "Moose of the python world", but it gives you a good idea of some of the nice patterns possible when you think outside of the core Python OO featureset). [1] http://search.cpan.org/dist/Moose/lib/Moose/Manual.pod http://search.cpan.org/dist/Moose/lib/Moose/Manual.pod [2] http://radar.oreilly.com/2014/01/horizontal-reuse-an-alternative-to-inheritance.html http://radar.oreilly.com/2014/01/horizontal-reuse-an-alterna... [3] http://modernperlbooks.com/mt/2009/05/perl-roles-versus-interfaces-and-abcs.html http://modernperlbooks.com/mt/2009/05/perl-roles-versus-inte... [4] https://github.com/frasertweedale/elk https://github.com/frasertweedale/elk [5] http://code.enthought.com/projects/traits/ http://code.enthought.com/projects/traits/
- albertzeyer 12y ago
  Python 3 has function annotations and you can use it for static type checks. See this: http://www.infoq.com/news/2014/08/python-type-annotation-proposal http://www.infoq.com/news/2014/08/python-type-annotation-pro... https://mail.python.org/pipermail/python-ideas/2014-August/028618.html https://mail.python.org/pipermail/python-ideas/2014-August/0... http://mypy-lang.org/ http://mypy-lang.org/ https://docs.python.org/3/tutorial/controlflow.html#function-annotations https://docs.python.org/3/tutorial/controlflow.html#function...
  - andreasvc 12y ago
    Those are only checks, and don't make your code faster (in fact, slower, when checks are enabled). To get efficiency benefits you need a language/compiler designed around static typing. Cython offers a superset of Python that can be statically typed.
haberman 12y ago
> For a Perl-type problem (scanning and parsing big files), Perl is very fast. I think it's a matter of what you're comparing it to. Compared to using Perl for a general-purpose problem, Perl for scanning/parsing is fast. Compared to scanning/parsing with C, Perl is not fast. $ ruby -e '1.upto(1000000) { |n| puts "This is line number #{n}" }' > file $ time perl -ne 'print if /number 12345/' < file [...] real 0m0.193s user 0m0.189s sys 0m0.004s $ time grep "number 12345" file [...] real 0m0.023s user 0m0.019s sys 0m0.005s I gave Perl every possible advantage here. I didn't actually even write any Perl except a regular expression, which is delegated immediately to C. I didn't even write the loop in Perl, I like the Perl main() function handle that. And still the C program is almost 10x faster. Note: these test runs are from Linux. On OS X the Perl results were almost the same, but "grep" was unexplainably way slower. It seems to hang after it's already dumped all of its output. Basically grep on OS X appears to be badly broken somehow.
- Igglyboo 12y ago
  I think the takeaway is that perl is "fast enough" for perl type problems. Writing a complicated file parser in C would be a nightmare.
  - visarga 12y ago
    When I have a one-time computation job that takes an hour to write and two hours to run in Perl, but in C takes 10 hours to write and half an hour to run, then Perl is faster than C. And these one-time/rare/short jobs are much more frequent than intense, high throughput C code like the nginix web server or the node javascript interpreter.
    - Igglyboo 12y ago
      I see your point, C is definitely the choice for long running jobs or jobs that will be run more than a handful of times, in my experience however I'm writing a lot of one-off scripts that take 30 seconds tops to run so Perl wins out pretty hard over C.
- 12y ago

by cleaver 12y ago

csirac2 12y ago

I don't know why I always have to chip in on "perl is unreadable lol" comments, but over the last 8 years apart from a steady trickle of C coding here and there the bulk of my dayjob has moved around from C/Verilog, then I discovered Ruby, then Perl/R/Python, to full-time Python now. It's true that unsupervised, weak coders using perl turn out worse code than in other languages. But it really doesn't take much to produce good code if you have a tiny bit of supervision/discipline (which stems mostly from 80% of perl tutorials on the web are teaching 1997-era perl anti-patterns). And/or if you happen to be a stronger programmer in something else, hopefully you stumble across perlcritic and modern perl patterns more quickly. Well-written Moose code involves less boilerplate, the declarative nature and composability of classes, types and data members with free type/value validation is a delight to maintain, and results in more robust code with a lot fewer silent failures (or objects happily chugging along silently with invalid state) than typical Python classes. Of course, now that I can't use Moose and the Python community actively seems to discourage the very thought of relying on any superset of core Python OO features like enthoughts' traits package - I really want to revisit static/stronger typed programming languages for large projects. So it feels like I've come full-circle in my programming career...

pwr22 12y ago
Well said :). I like Perl but when I write it I'm aiming above all for readability
Cyther606 12y ago
Check out Nim. import rdstdin, strutils let time24 = readLineFromStdin("Enter a 24-hour time: ").split(':').map(parseInt) hours24 = time24[0] minutes24 = time24[1] flights: array[8, tuple[since: int, depart: string, arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."), (583, "9:43 a.m.", "11:52 a.m."), (679, "11:19 a.m.", "1:31 p.m."), (767, "12:47 p.m.", "3:00 p.m."), (840, "2:00 p.m.", "4:08 p.m."), (945, "3:45 p.m.", "5:55 p.m."), (1140, "7:00 p.m.", "9:20 p.m."), (1305, "9:45 p.m.", "11:58 p.m.")] proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int = hours * 60 + minutes proc cmpFlights(m = minutesSinceMidnight()): seq[int] = result = newSeq[int](flights.len) for i in 0 .. <flights.len: result[i] = abs(m - flights[i].since) proc getClosest(): int = for k,v in cmpFlights(): if v == cmpFlights().min: return k echo "Closest departure time is ", flights[getClosest()].depart, ", arriving at ", flights[getClosest()].arrive https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers
- rdtsc 12y ago
  If I had to guess speed is pretty close to C, right. Nim is pretty awesome and has been around for a while. I wish one of big entities out there Google, Mozilla, Microsoft, Apple would have adopted Nim and ran with it instead of inventing their own langauges.
  - bjz_ 12y ago
    At the time when Go and Rust were conceived Nim would have certainly not been on their radar. Both were announced in 2009, at a time when the Nimrod repository had barely even got off the ground[0]. And Nim doesn't really address one of Apple's chief concerns: smoothly transitioning away from Objective-C. [0]: https://github.com/Araq/Nimrod/graphs/contributors https://github.com/Araq/Nimrod/graphs/contributors
fidotron 12y ago
Last time I used Perl it went badly, but it was a typical hacked up mess. For someone mainly in the Python/Java/C++ world is Moose something worth looking at as a mind expansion exercise? Your description makes it sound appealing. And, dare I ask, what about Perl 6?
- csirac2 12y ago
  I want to write something concise and coherent, but it's not happening today :) Instead, assuming you've read the teasers in the Moose manual [1] I'd recommend this [2] interesting comparison of how horizontal code re-use can be achieved in Java, Ruby, PHP and Perl+Moose. There's more philosophical/winding essays on Moose from Chromatic, for example at [3]. Roles/traits/method modifiers/MOP/composability etc. are all great things for getting more reusability... however (and this might sound stupid) the thing that saddens me most when writing Python code is when I find myself adding a bunch of asserts or adding program logic "manually" in situations where I'd normally specify that sort of thing declaratively in a Moose class definition or by referring to a centrally managed Type or delegate stuff through attribute features. On the other hand, I'm barely into year 2 of full-time Python dev, so perhaps I've yet to find the idiomatic way of doing Python things I used to take for granted in Moose. Regarding Perl 6, I don't know much about it, except that the original authors of Moose had some inspiration from it. Is picking up Perl+Moose mind-expanding? It was for me, but I feel that what Moose gave me in Perl was a bit of a band-aid over the fact that it's such a malleable open-ended dynamic language. So as a C++/Java programmer this aspect might not be so enlightening to you, except to see how Moose achieves it in a pretty painless way that I think is very nice and idiomatic for a dynamic language (with the caveats that brings). To put it another way: it gives Perl some of the great benefits of properly declaring things up-front, without the boilerplate/inflexibility pain that I perceive the Java ecosystem's bureaucracy to be (I haven't touched Java for 10 years, so take that with a grain of salt). If you want to explore some Moose-ish kinds of things within Python, check out [4] (there's another Moose clone in Python that's similarly inactive, sadly) and [5] (Enthought's stuff is perhaps a bit too heavy and incomplete to be the "Moose of the python world", but it gives you a good idea of some of the nice patterns possible when you think outside of the core Python OO featureset). [1] http://search.cpan.org/dist/Moose/lib/Moose/Manual.pod http://search.cpan.org/dist/Moose/lib/Moose/Manual.pod [2] http://radar.oreilly.com/2014/01/horizontal-reuse-an-alternative-to-inheritance.html http://radar.oreilly.com/2014/01/horizontal-reuse-an-alterna... [3] http://modernperlbooks.com/mt/2009/05/perl-roles-versus-interfaces-and-abcs.html http://modernperlbooks.com/mt/2009/05/perl-roles-versus-inte... [4] https://github.com/frasertweedale/elk https://github.com/frasertweedale/elk [5] http://code.enthought.com/projects/traits/ http://code.enthought.com/projects/traits/
albertzeyer 12y ago
Python 3 has function annotations and you can use it for static type checks. See this: http://www.infoq.com/news/2014/08/python-type-annotation-proposal http://www.infoq.com/news/2014/08/python-type-annotation-pro... https://mail.python.org/pipermail/python-ideas/2014-August/028618.html https://mail.python.org/pipermail/python-ideas/2014-August/0... http://mypy-lang.org/ http://mypy-lang.org/ https://docs.python.org/3/tutorial/controlflow.html#function-annotations https://docs.python.org/3/tutorial/controlflow.html#function...
- andreasvc 12y ago
  Those are only checks, and don't make your code faster (in fact, slower, when checks are enabled). To get efficiency benefits you need a language/compiler designed around static typing. Cython offers a superset of Python that can be statically typed.

haberman 12y ago

> For a Perl-type problem (scanning and parsing big files), Perl is very fast. I think it's a matter of what you're comparing it to. Compared to using Perl for a general-purpose problem, Perl for scanning/parsing is fast. Compared to scanning/parsing with C, Perl is not fast. $ ruby -e '1.upto(1000000) { |n| puts "This is line number #{n}" }' > file $ time perl -ne 'print if /number 12345/' < file [...] real 0m0.193s user 0m0.189s sys 0m0.004s $ time grep "number 12345" file [...] real 0m0.023s user 0m0.019s sys 0m0.005s I gave Perl every possible advantage here. I didn't actually even write any Perl except a regular expression, which is delegated immediately to C. I didn't even write the loop in Perl, I like the Perl main() function handle that. And still the C program is almost 10x faster. Note: these test runs are from Linux. On OS X the Perl results were almost the same, but "grep" was unexplainably way slower. It seems to hang after it's already dumped all of its output. Basically grep on OS X appears to be badly broken somehow.

Igglyboo 12y ago
I think the takeaway is that perl is "fast enough" for perl type problems. Writing a complicated file parser in C would be a nightmare.
- visarga 12y ago
  When I have a one-time computation job that takes an hour to write and two hours to run in Perl, but in C takes 10 hours to write and half an hour to run, then Perl is faster than C. And these one-time/rare/short jobs are much more frequent than intense, high throughput C code like the nginix web server or the node javascript interpreter.
  - Igglyboo 12y ago
    I see your point, C is definitely the choice for long running jobs or jobs that will be run more than a handful of times, in my experience however I'm writing a lot of one-off scripts that take 30 seconds tops to run so Perl wins out pretty hard over C.
12y ago