5 ms·

What do you mean by cheap? Also, perl is incredibly inefficient: it's even slower than Python. Also, how is Perl any less stable than other languages? Are you

by smabie 6y ago

What do you mean by cheap? Also, perl is incredibly inefficient: it's even slower than Python. Also, how is Perl any less stable than other languages? Are you saying the language doesn't change much or that it doesn't crash?

kbenson 6y ago
> it's even slower than Python. It's faster at some things and slower at others. It's fairly similar in speed profile to Python in my eyes. > Are you saying the language doesn't change much or that it doesn't crash? Both is probably what was meant. They are literally changing the major version so they can change some backwards compatibility, as Perl has made strong backwards compatibility a goal and selling point for decades. You can take a script written in 2000, and it will likely run without problem if you run it on a Perl 5.30, released last year.
1996 6y ago
- Efficient: from prototype to deployment, it's a matter of days. The choice of styles let people use paradigms they are familiar with, meaning they do things quickly. - Cheap: it does not cost much to hire someone to write perl. If they don't know how yet, the choice in style let them be efficient quickly. The code to be deployed is very lightweight, both in CPU and RAM usage. - Stable: no API break. No new module that reinvent the wheel and breaks your codebase. Unit testing is about everywhere in cpan. Code written 20 years ago still run fine.
- continuational 6y ago
  The reason that code written 20 years ago still runs fine is that they rolled back 20 years of changes!
  - 1996 6y ago
    This is a pointless attack. The modules available on CPAN usually have a strong emphasis on backwards compatibility.
cutler 6y ago
On my 4-core i7 Macbook Pro: time ./startup_time.pl 0.016s time ./startup_time.py 0.295s Parsing a 20Mb log file with a regex: time ./parse_log.pl 0.683s time ./parse_log.py 1.534s For which metric are you claiming Perl is slower than Python?
- orf 6y ago
  Lets see the code? Regex has always been a Perl selling point, and you're just benchmarking the Python Regex library (written in C) against Perl's regex library. That's not a fantastic basis for a comparison.
  - cutler 6y ago
    Perl 5: #!/usr/bin/env perl use 5.026; open my $fh, '<', 'logs1.txt'; while (<$fh>) { chomp; say if /\b\w{15}\b/; } close $fh; Python 3.8 #!/usr/bin/env python import re with open('logs1.txt', 'r') as fh: for line in fh: if re.search(r'\b\w{15}\b', line): print(line, end='') Why isn't it a fair comparison? The startup time is generic and string parsing is a major feature of, say, web development. I didn't say Perl5 numerics match Python's but even there Python relies on external libs.
    - dgfitz 6y ago
      The python code should run much faster if you don't print.. Edit: perl is still faster, to be clear
      - cutler 6y ago
        That's like saying they're both as fast if you amputate one of Perl's legs.
    - tomku 6y ago
      It doesn't account for anywhere near the whole difference, but in a tight loop like that Python's going to be spending a good chunk of its time re-compiling the regex from the raw string literal every iteration. Hoist the regex definition out of the loop like so and it'll probably run about 30% faster: #!/usr/bin/env python3 import re with open('logs1.txt', 'r') as fh: regex = re.compile(r'\b\w{15}\b') for line in fh: if regex.search(line): print(line, end='') Perl almost certainly does this by default for regex literals, and that's a fair advantage for the "kitchen sink" style of language design versus orthogonal features (regex library, raw strings) that Python uses.
yellowapple 6y ago
> Also, perl is incredibly inefficient: it's even slower than Python. That's debatable for single-threaded workloads (they're typically pretty comparable in my observation), and highly unlikely for multi-threaded workloads (Python has a global interpreter lock whereas Perl does not AFAICT; you can work around that in Python, but it typically involves spawning entirely separate processes, thus introducing IPC overhead that wouldn't be present in a Perl equivalent). Looking at some comparative benchmarks (https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/perl-python3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...), Perl seems to be faster in a slight majority of cases, and in nearly all cases has a lower memory overhead. Not that benchmarks really matter anyway, given that they're usually a poor indicator of real-world performance, but still.

by smabie 6y ago

kbenson 6y ago

> it's even slower than Python. It's faster at some things and slower at others. It's fairly similar in speed profile to Python in my eyes. > Are you saying the language doesn't change much or that it doesn't crash? Both is probably what was meant. They are literally changing the major version so they can change some backwards compatibility, as Perl has made strong backwards compatibility a goal and selling point for decades. You can take a script written in 2000, and it will likely run without problem if you run it on a Perl 5.30, released last year.

1996 6y ago

- Efficient: from prototype to deployment, it's a matter of days. The choice of styles let people use paradigms they are familiar with, meaning they do things quickly. - Cheap: it does not cost much to hire someone to write perl. If they don't know how yet, the choice in style let them be efficient quickly. The code to be deployed is very lightweight, both in CPU and RAM usage. - Stable: no API break. No new module that reinvent the wheel and breaks your codebase. Unit testing is about everywhere in cpan. Code written 20 years ago still run fine.

continuational 6y ago
The reason that code written 20 years ago still runs fine is that they rolled back 20 years of changes!
- 1996 6y ago
  This is a pointless attack. The modules available on CPAN usually have a strong emphasis on backwards compatibility.

cutler 6y ago

On my 4-core i7 Macbook Pro: time ./startup_time.pl 0.016s time ./startup_time.py 0.295s Parsing a 20Mb log file with a regex: time ./parse_log.pl 0.683s time ./parse_log.py 1.534s For which metric are you claiming Perl is slower than Python?

orf 6y ago
Lets see the code? Regex has always been a Perl selling point, and you're just benchmarking the Python Regex library (written in C) against Perl's regex library. That's not a fantastic basis for a comparison.
- cutler 6y ago
  Perl 5: #!/usr/bin/env perl use 5.026; open my $fh, '<', 'logs1.txt'; while (<$fh>) { chomp; say if /\b\w{15}\b/; } close $fh; Python 3.8 #!/usr/bin/env python import re with open('logs1.txt', 'r') as fh: for line in fh: if re.search(r'\b\w{15}\b', line): print(line, end='') Why isn't it a fair comparison? The startup time is generic and string parsing is a major feature of, say, web development. I didn't say Perl5 numerics match Python's but even there Python relies on external libs.
  - dgfitz 6y ago
    The python code should run much faster if you don't print.. Edit: perl is still faster, to be clear
    - cutler 6y ago
      That's like saying they're both as fast if you amputate one of Perl's legs.
  - tomku 6y ago
    It doesn't account for anywhere near the whole difference, but in a tight loop like that Python's going to be spending a good chunk of its time re-compiling the regex from the raw string literal every iteration. Hoist the regex definition out of the loop like so and it'll probably run about 30% faster: #!/usr/bin/env python3 import re with open('logs1.txt', 'r') as fh: regex = re.compile(r'\b\w{15}\b') for line in fh: if regex.search(line): print(line, end='') Perl almost certainly does this by default for regex literals, and that's a fair advantage for the "kitchen sink" style of language design versus orthogonal features (regex library, raw strings) that Python uses.

yellowapple 6y ago

> Also, perl is incredibly inefficient: it's even slower than Python. That's debatable for single-threaded workloads (they're typically pretty comparable in my observation), and highly unlikely for multi-threaded workloads (Python has a global interpreter lock whereas Perl does not AFAICT; you can work around that in Python, but it typically involves spawning entirely separate processes, thus introducing IPC overhead that wouldn't be present in a Perl equivalent). Looking at some comparative benchmarks (https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/perl-python3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...), Perl seems to be faster in a slight majority of cases, and in nearly all cases has a lower memory overhead. Not that benchmarks really matter anyway, given that they're usually a poor indicator of real-world performance, but still.