Hacker News Reader

Comment by frakkingcylons | Hacker News Reader

I see this is written in Perl, is that the case with most Debian tooling?

One of the authors of strip nondeterminism is here. The primary reason it's written in Perl is that given that strip-nondeterminism is used when building 99.9% of all Debian packages, using any other language would have essentially made that language's runtime a dependency for all building Debian packages. (Perl is already required by the build process, whilst Python is not.)

Question: is Perl the only runtime the Debian build process relies on?

Any packages with "Essential: yes" (run 'apt list ~E' to see them) are required on any Debian system. Additionally, the 'build-essential' pulls in other packages that must be present to build Debian packages via its dependencies: https://packages.debian.org/sid/build-essential

It’s helpful to think of Perl as a superior bash, rather than a worse python, when it comes to scripting.

stealing this, thank you

Notably, they forgot to improve on readability and maintability, both of which are markedly worse with perl.

Look I get people use the tools they use and perl is fine, i guess, it does its job, but if you use it you can safely expect to be mocked for prioritizing string operations or whatever perl offers over writing code anyone born after 1980 can read, let alone is willing to modify.

For such a social enterprise, open source orgs can be surprisingly daft when it comes to the social side of tool selection.

Would this tool be harder to write in python? Probably. Is it a smart idea to use it regardless? Absolutely. The aesthetics of perl are an absolute dumpster fire. Larry Wall deserves persecution for his crimes.

Did you miss the post a few above yours, where an author of this tool explained why it’s written in Perl? Introducing a new language dependency for a build, especially of an OS, is not something you undertake lightly.

Right. Good luck finding people who want to maintain that. It just seems incredibly short-sighted unless the current batch of maintainers intend to live forever.

Counterpoint: if someone knows Perl, they are much more likely to have the requisite skills to be a maintainer for a distro. It’s self-selection.

Imagine the filtering required for potential maintainers if they rewrote the packaging to JS.

How is that helpful to ignore a better alternative just because a worse one exists?

They precisely say they use it as a better alternative to bash. Obviously they don't think that Python is a better alternative here... or did I misunderstand the question?

Not obvious to me that they think Python is worse than Perl, and make the phrase even less sensible.

Weird wording yes. I read it as "yes perl is better than bash" (I assume for tasks that need actual programming languages), "no it's not worse than python".

I'm not reading it as "it's not worse than python", I am reading it as "the choice was between bash and perl, python was not an option for reasons unrelated to its merits"

So you genuinely believe that they think Python is a better choice in this case, but still chose to go for Perl because they believe it's worse? How does that work?

It works by not mixing two different people: the commenter and the implementer.

Also, it works trivially even in the case of the implementer - he might believe Python is better, but chose Perl because he likes it more

The same reason people write C++ instead of better^TM alternatives.

Pick the tool you already know and focus on solving the problem.

Packaging and making build scripts is perhaps one of the most unrewarding tasks out there. As an open source project where most work is done for free, debian can't afford to be prescriptive about what languages are used for this sort of task.

Actually it can and it is. Build system dependencies, especially ones that apply to all packages, are something that concerns the distribution as a whole and not something where each developer can just add their favorite one.

I checked the code. Perl is suitable for these kind of tasks.

some, but not all. There's a bunch of historical code which means that Perl is in the base install, but modern tooling has a lot of Python too, as well as POSIX shell (not bash).

Though a lot of the apt tooling is definitely written in Perl the last time I had to deep dive

And a lot of OpenBSD-related stuff is written in Perl, too. I do not think it is a bad thing at all.

I absolutely love Perl. I'm just so sad Python won because Google blessed it as a language and at the time everyone wanted to work for Google.

Perl always gets hate on HN, but I actually wonder of those commenter, who has actually spent over a single hours using Perl after they've read the Camel book.

Honest opinion: if you're going to be spending time in Linux in your career, then you should read the Camel book at least once. Then and only then should you get to have an opinion on Perl!

I mostly agree with you, though I do think Perl is genuinely harder to read than many other languages. Perl was often my goto for scripts before I learned Ruby (which has many glorious perl-isms in it even if most rubyists nowadays don't know or want to acknowledge that :-D ), and even looking back at some of my own code and knowing what it does, I have to read it a lot slower and more carefully than most other langs. Perl to me feels wonderfully optimized for writing, sometimes at the expense of reading. I love Perl's power and expressiveness, especially the string processing libs, and while I appreciate the flexibility in how many different ways there are to do things, it does mean that Perl code written by someone else with different approaches can sometimes be difficult to grok. For my own scripts I don't care about any of those issues and I often optimize for writing anyway, but there are plenty of applications where I would recommend against Perl, despite my affection for it.

And yes agree, people should read the camel book!

> there are plenty of applications where I would recommend against Perl

Yes of course, I would not write any type of servers in Perl, I would pick Go or Elixir or Erlang for such an use-case.

Last time I checked a lot was also written in Python.

Reply on news.ycombinator.com