On 22 January 2012 16:44, Baho Utot <baho-utot@...> wrote: > > > On Sunday 22 January 2012 01:21:42 pm Darrell Anderson wrote: >> > Unless you're already good at C++, just about any other >> > language is going to be faster >> > to program in. Programmer time is more valuable than >> > machine time these days for >> > the majority of applications--and for small- to >> > medium-sized programs, no one is going >> > to notice the difference in execution speed between one and >> > three milliseconds anyway. >> >> A funny thing about speed. Possibly experienced coders see a difference >> whereas every day users probably do not. Yet speed is relative. Often I >> have read how shell scripts are slow. From a strict theoretical and design >> perspective, I am sure that is true. In certain iterative tests, I'm sure >> shell scripts can be shown to be slower than other scripting languages. Yet >> in my every day usage, and I have written a few long shell scripts, I don't >> notice anything. I once read a person's comment that once a shell script >> grows to beyond a few dozen lines that a person should move to Python or >> Perl. Okay. Whatever. > > > +1 > > Arch linux package manger make extensive use of bash. Have a look at makepkg > mkchroot and repo-add etc. > > few dozen lines indeed ;) > > I take it they have not seen my shell scripts :) > > For system admin etc bash is great. We say that scripting is great, but it often causes a mess once it gets to big. Ever worked on a project at a company and there is just one old perl script that nobody dares touch? it's several thousand lines and is hiding in some obscure folder. But every week a cron job runs this script and things continue as normal. Scripting needs to be watched carefully before it grows out of control