unpythonic

The other article fails to mention the building vs land+building valuation. I posted it over there, but thought this was a better article on its own.

Sadly, it's not always that simple. If one of your well-pinned packages has a build dependency which is not correctly pinned, then you're subject to the problem.

Oh yeah! Perl sure did have a bunch of ugly programs, but I believe that was because it was so easy for non-experts to program in it. There have been many companies successfully built atop of a Perl code base, and I've seen fantastic systems built with it. I've also seen one-off programs handed from manager to manager which would scare you to death.

Horror is apt.

You hit it on the head with the slowness of loops when the body comprises a series of program invocations. The horror really seeps in when you realize the original author wasn't stopped by the lack of data structures: they could get around that with some creative variable names.

The effortless composition of complex commands out of simple standalone programs is one of the best features of Unix. And yes, I admire and love it as well.

That said, imagine a metrics system for a huge networking company that used these methods to cover all automated testing or defect analysis. Those inner loops were made of greps and seds and so forth, and each one is the invocation of a new program. It wasn't uncommon for these runs to take almost a day.

Besides performance, the other nightmare was was someone described below: each script was a one-off that didn't leverage the work from others. If the author only new C shell, then you know you're going to be doing gymnastics to catch the stderr of some of those programs (you can't capture it in the same manner that Bourne variants do).

Anyway, yes, we all adore the Unix philosophy, but there are limits.

When perl came out we were living in horrific times. You had the choice of either Bourne, C or Korn shell. Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things.

Perl in one stroke collapsed the programming of C, text manipulation, the capabilities of all of the Unix utilities, and data structures into one system. For anything which wasn't subsumed into the monolith of Perl, you could easy access via backticks. It was very friendly in dealing with text streams, and that's what those call-outs in those back ticks spoke.

Yes, awk and sed were replaced by Perl, but more importantly, the unmaintainable nightmare that glued all of it together was wiped out.

The claim: reduces CO₂e emissions by up to 80%*

The asterisk: water boiling phase excluded

When I boil pasta, I use full heat to get the water boiling, drop in the pasta, then let it come back up to a boil, then drop the temperature as low as possible to keep a slow boil going--about medium-low.

Guesstimating that the boil takes about as long as the time to cook the pasta, I'd say that the pasta cooking portion only takes up about 1/3 of the energy of the total (cold pot to cooked pasta).

The 80% savings only covers the pasta cooking phase, so overall, it's only saving 4/15 or 27% (roughly). If you use a lot more water, then that initial boil time further reduces your savings.

If you read through to the bottom, you'll see the article itself is just a call to action for yet another service which the author is starting. It's an ad. Seeing it buried so deep doesn't make me feel that the author has any better intentions than Google itself -- credibility already gone.

The article is just an ad.

> This was my motivation for starting GlacierMD: I wanted to give consumers the information they needed to make evidence-based health decisions. And although I lost that battle (spectacularly) I'm still fighting the war! If this is a topic that interests you, I'd urge you to