Hacker News Reader

Comment by AceJohnny2 | Hacker News Reader

Yeah, I'm ambivalent about this. (For some background, I used to hate Perl until I had to write some non-trivial shell scripts, then I realized Perl was a godsend compared to shell).

We've long been at the point where you can expect Perl and Python to be installed (Perl is required by the Debian's base tools, and Python by Redhat's).

You may not have the libraries you need at the version you need, and it's a shame that neither system has a convenient way to address that (Python virtualenv remains a hacky solution IMHO).

I was initially enthused by Shellfire's offering but, come to think of it, all it's doing is bringing SH scripting to some level with Perl or Python... but, as you point out, we have those already.

View on HN

> I used to hate Perl until I had to write some non-trivial shell scripts, then I realized Perl was a godsend compared to shell

If the job requires one page of code or less, use shell. If it requires more than one page of code, use Python or whatever. Simple as that.

I still hate Perl anyway - source code obfuscation by design is a terrible thing to do to your brain.

That's mostly my heuristic as well, except there's a sweet spot for Perl somewhere in the middle.

Python has a upgrade problem. We're still running a bunch of CentOS 5.5 machines which depend on Python 2.4. In my org, we still have scripts littered around that expect a later version of python, but are executed from just "#!/usr/bin/python" instead of "python2.7". which fails on those old CentOS machines, on which you can't just set a newer version of Python as default because that'll break many system utilities.

Also, Perl's syntactic sugar for regular expressions turns out to be very useful (and I say this after years of grumbling against it).

> If the job requires one page of code or less, use shell. If it requires more than one page of code, use Python or whatever. Simple as that.

The problem with this simple guideline is that tools grow, so what was well less than a page becomes much more—and each small increment is too small to justify a complete re-write, so eventually you wind up with a huge shell-script monster.

What is wrong with virtualenv?

It's not path-relative: I can't copy an env from one dir to another. It's an external tool that you need to enable separately from your execution, when really it should've been part of Python's base binary (resolving libs from the CWD to user libpath to system libpath), to name just a couple issues.

virtualenv appears to be a giant, epic work-around for... what exactly? Somehow, perl managed to achieve the same thing with the PERL5LIB envar. And did it in a far more portable, reusable and repeatable way.

Exactly. I love Python for many other reasons, but how they still haven't managed to fix local vs user vs system libraries, when pretty much every other language has, and think virtualenv is an acceptable solution, is beyond me.

Of course, since they have many geniuses working on their codebase, I assume the problem must actually be pretty fundamental and tricky.... right?

Reply on news.ycombinator.com