Re^4: Myth busted: Shell isn't always faster than Perl

So, you do everything with Perl scripts, so you're not a monoculture programmer? Interesting. What's your definition of monoculture then?

Yes, pretty well anything I write that has to be run on multiple enviorments (which in theory is most of what I do) is written in perl.

Monoculture to me is writing code that expects to be run on/in a certain OS/Shell/Architecture.

But I will say that your bike/truck point is a powerful one.

---
$world=~s/war/peace/g

Comment on Re^4: Myth busted: Shell isn't always faster than Perl

Replies are listed 'Best First'.
Re^5: Myth busted: Shell isn't always faster than Perl by Tanktalus (Canon) on Jan 03, 2006 at 04:13 UTC
"Monoculture" should not include "shell" any more than it should include "perl". Both are just interpreters that one may use to write the programs we're referring to. Besides, I write perl to run on only three more platforms than I write for shell. I write cross-platform shell at work for AIX (4, 5), Sun (5-9), HP/PARISC (10+), HP/ia64 (11.23+), and Linux for ia32, ia64, x86-64, ppc, and s390/s390x. Add Windows for ia32, ia64, and x86-64 to get my perl list. I write both production and tooling in both languages for all platforms. And I have over 10,000 lines of production code that I've written and/or maintain in each language. I dispute any attempt to claim cross-platform problems in shells at any significant difference from perl. Core tools, much like core perl, is pretty much ubiquitous. Non-core tools, which perl would often need to use system() to call anyway, won't be any more difficult in shell than perl. In fact, the only reason why we don't actually ship perl scripts (we only use them for development) but we do ship shell scripts is trying to convince management to rely on a decent version of perl being installed everywhere. We have no problems with being convinced of Bourne Shell syntax everywhere (although we actually use bash on Linux). The version dependancies in shell are way less than we've had with perl where multiple times we've needed upgrades to handle things. Shell has just worked. For minor, one-off scripts, I still fall back to shell. For complex things, I move over to perl. But even then, there are just some limitations. Such as trying to have a simple command to effect great changes to one's environment. Perl just can't do it without spawning a subshell, or running inside a shell 'eval' statement, both of which have annoyances/limitations. Contrast with the shell's limitation on compile-time checking (there is none) or lexical variables (again, no such thing), and you end up with reasons to keep both tools in one's toolchest. For me, learning both tools (shell and perl) has made me more efficient on all platforms. Especially unix/linux. Knowing their limitations allows me better access to each of their strengths.	[reply]

Replies are listed 'Best First'.

Re^5: Myth busted: Shell isn't always faster than Perl
by Tanktalus (Canon) on Jan 03, 2006 at 04:13 UTC

"Monoculture" should not include "shell" any more than it should include "perl". Both are just interpreters that one may use to write the programs we're referring to.

Besides, I write perl to run on only three more platforms than I write for shell. I write cross-platform shell at work for AIX (4, 5), Sun (5-9), HP/PARISC (10+), HP/ia64 (11.23+), and Linux for ia32, ia64, x86-64, ppc, and s390/s390x. Add Windows for ia32, ia64, and x86-64 to get my perl list. I write both production and tooling in both languages for all platforms. And I have over 10,000 lines of production code that I've written and/or maintain in each language.

I dispute any attempt to claim cross-platform problems in shells at any significant difference from perl. Core tools, much like core perl, is pretty much ubiquitous. Non-core tools, which perl would often need to use system() to call anyway, won't be any more difficult in shell than perl.

In fact, the only reason why we don't actually ship perl scripts (we only use them for development) but we do ship shell scripts is trying to convince management to rely on a decent version of perl being installed everywhere. We have no problems with being convinced of Bourne Shell syntax everywhere (although we actually use bash on Linux). The version dependancies in shell are way less than we've had with perl where multiple times we've needed upgrades to handle things. Shell has just worked.

For minor, one-off scripts, I still fall back to shell. For complex things, I move over to perl. But even then, there are just some limitations. Such as trying to have a simple command to effect great changes to one's environment. Perl just can't do it without spawning a subshell, or running inside a shell 'eval' statement, both of which have annoyances/limitations. Contrast with the shell's limitation on compile-time checking (there is none) or lexical variables (again, no such thing), and you end up with reasons to keep both tools in one's toolchest.

For me, learning both tools (shell and perl) has made me more efficient on all platforms. Especially unix/linux. Knowing their limitations allows me better access to each of their strengths.

[reply]