News for hackers. Stuff that matters.
Re:Finally, a Makefile formatter (50 years overdue) by zahlman on Monday June 23, 2025 @11:25AM (#44356753)
> Yet everyone talks about performance when it comes to programming languages. Why?

I know this may come as a shock to the average HN reader, but most people do not think very clearly. Even programmers. And among those who do, it is quite rare that people speak precisely without putting in considerable effort.

> but even easier (and faster) to do on Perl.

You have no objective way to substantiate this claim (because such cannot exist), therefore it is in fact a matter of opinion.

Re:Finally, a Makefile formatter (50 years overdue) by johnisgood on Monday June 23, 2025 @04:08PM (#44359539)
Oh but there is an objective way to substantiate this claim. How familiar are you with Perl? It will not work (to convince you) if you do not know the language, you need to be quite familiar with it. There are extremely short ways to do string manipulation, for one, think 3 characters short. So, assuming you know Perl, it is definitely easier AND faster, than say, Python.

Trivial example:

Replace all numbers in a string:

Perl:

  $string =~ s/\d+/NUM/g;
Python:

  import re
  string = re.sub(r'\d+', 'NUM', string)
Perl's design history is text processing as a first-class goal. It has syntax-level efficiency, and expressive power (e.g. s///e, tr///, inline regex flags, etc.). Do you want me to go on? These are all objective ways to substantiate the claims I made.

Perl is implemented in C with a runtime that aggressively optimizes text processing. The core primitives such as split, join, substr, index, s///, etc.) are tight wrappers around C functions with minimal object overhead. In Python, even simple string manipulations go through Python's object system, and in Python strings are immutable, so every manipulation creates a new string object, which incurs extra memory allocation and garbage collection.

Perl is typically 30-80% faster in similar regex-heavy workloads because there is no import overhead, internal opcode dispatch for regex, and no allocation of new strings until match is confirmed.

Shall I go on?

Re:Finally, a Makefile formatter (50 years overdue) by johnisgood on Tuesday June 24, 2025 @10:21AM (#44366580)
Using the down-vote button is such an absurd way to disagree. So whoever you may be, you should engage in a conversation. With what do you disagree, and why?
Re:Finally, a Makefile formatter (50 years overdue) by johnisgood on Wednesday June 25, 2025 @06:23PM (#44382327)
FYI:

  [johnisgood@arch regex]$ hyperfine 'perl regex_test.pl' 'python3 regex_test.py'
  Benchmark 1: perl regex_test.pl
    Time (mean ± σ):      1.807 s ±  0.028 s    [User: 1.752 s, System: 0.054 s]
    Range (min … max):    1.780 s …  1.857 s    10 runs

  Benchmark 2: python3 regex_test.py
    Time (mean ± σ):      3.316 s ±  0.230 s    [User: 3.246 s, System: 0.069 s]
    Range (min … max):    3.052 s …  3.858 s    10 runs

  Summary
    perl regex_test.pl ran
      1.84 ± 0.13 times faster than python3 regex_test.py
This is for a very simple script!

You know why?

Because Perl was practically designed for text processing and regex.

It has:

- A regex engine that's deeply integrated and highly optimized.

- Less overhead (no interpreter startup, minimal memory structures).

- Simpler string substitution and less abstraction.

Seriously, it is not a matter of opinion.

I hope you are convinced now.

In case you are not, let me know, I will let you in on a lot of great details. :)