20 ms·

UNIX scales very well. This is coming from someone who programs in regular expressions. Nothing wrong with not using bash, or ruby|python|perl when everything c

by UNIXgod 13y ago

UNIX scales very well. This is coming from someone who programs in regular expressions. Nothing wrong with not using bash, or ruby|python|perl when everything can be done in the small one. The posix sh has a 70k footprint. There is nothing that can't be accomplished in the shell with both less code while defeating complexity through both recursion and stream processing. They hit it spot on with the philosophy and operating system semantics. It's just another way of using it.

mitchty 13y ago
If the argument for posix sh is that its 70k, I'm not sure thats a pro or con. I compared the runtime of a perl script versus shell doing pretty much the same thing, and perl was much faster because there was significantly less fork/exec going on. Sure the executable is say 70k versus dunno 5 megs for perl lets say. In the end, if you're that constrained for memory, you should be using c not shell or even perl. My aversion to shell is more related to finding, and eventually having to support, 20k shell "programs". They are inevitably always brittle creations with no tests or even design philosophy behind them. They nominally were cobbled together to fill a niche. From which I'm impressed they work, but inevitably they fall on their own petard. I've rewritten most of them with some scripting language and reduced their complexity by orders of magnitude and made them easier to use as well as orders of magnitude faster. Stream/pipe processing isn't the only way to skin some cats, despite its simplicity. I guess I just find the "I know i'll use shell" behavior to really really end up being its own detriment in later use. Shell may be turing complete but things like spaces for example really make using it easily and simply very much a losing proposition compared to say tcl. I'm not against shell, its a great glue language, but it just seems to get over used in some domains. Eh, time to go drink I'm rambling aimlessly now.

by UNIXgod 13y ago

mitchty 13y ago

If the argument for posix sh is that its 70k, I'm not sure thats a pro or con. I compared the runtime of a perl script versus shell doing pretty much the same thing, and perl was much faster because there was significantly less fork/exec going on. Sure the executable is say 70k versus dunno 5 megs for perl lets say. In the end, if you're that constrained for memory, you should be using c not shell or even perl. My aversion to shell is more related to finding, and eventually having to support, 20k shell "programs". They are inevitably always brittle creations with no tests or even design philosophy behind them. They nominally were cobbled together to fill a niche. From which I'm impressed they work, but inevitably they fall on their own petard. I've rewritten most of them with some scripting language and reduced their complexity by orders of magnitude and made them easier to use as well as orders of magnitude faster. Stream/pipe processing isn't the only way to skin some cats, despite its simplicity. I guess I just find the "I know i'll use shell" behavior to really really end up being its own detriment in later use. Shell may be turing complete but things like spaces for example really make using it easily and simply very much a losing proposition compared to say tcl. I'm not against shell, its a great glue language, but it just seems to get over used in some domains. Eh, time to go drink I'm rambling aimlessly now.