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