Scripting problem

[Polytropon]

On Tue, 17 Oct 2017 19:30:20 +0100, Frank Leonhardt (m) wrote:
> 
> 
> On 12 October 2017 00:01:55 BST, Warren Block <wblock at wonkity.com> wrote:
> >On Mon, 9 Oct 2017, Paul Pathiakis wrote:
> >
> >>> Quoting is sh's biggest weakness. Well, that and lack of basic data
> >>> structures, and the weak logical structures, and so on.
> >> 
> >> ### Well, yes and no. I consider it both a strength and a weakness. I
> >find sh to be exactly what I think of a scripting language to be...
> >glue. I don't
> >> expect to write a fully versed program in sh. I wouldn't be using sh
> >for that. I find sh to be that 'tool' to use when I want to call other
> >tools and
> >> utilities. (sed, awk, tr, etc)
> >> 
> >> ### I think people have gone way too far in creating 'scripting'
> >languages that are more programming languages than scripting....
> >Personally, I tried
> >> learning PERL which tries to be everything to regex. The problem?
> >Lack of coherence... "I can do this 5 different ways in PERL" Is that
> >supposed to be a
> >> good thing when all five seem to execute at different speeds, using
> >different resources, etc? (apologies to Larry Wall and the rest)
> >
> >The multiple domains that are utterly different are not just in Perl. 
> >In sh, you can use sed and awk, which have very little overlap.  In 
> >fact, you pretty much have to use sed *and* awk, because each is not 
> >quite powerful enough to do particular jobs.  Or use Perl, 
> >which is a superset of both.
> >
> >The trouble with sh is that it is so weak that it takes a lot of code
> >to 
> >accomplish anything. That comes back to haunt the programmer in the
> >long 
> >term, because simpler, shorter programs that use more powerful 
> >constructs are much easier to maintain.
> >
> >Perl is much-maligned, but every time I rewrite a shell script in Perl 
> >it gets shorter and easier to maintain.  Or longer and more powerful. 
> >Python and Ruby are similar.
> >
> >>> Someone once said that if a script is longer than twenty lines or
> >so, 
> >>> it probably ought to be done in a real scripting langugage. That was
> >
> >>> me, but Stephen Bourne has also said it. Yes, that Stephen Bourne.
> >> 
> >> ### I'll go off a little on this with kind of a corollary.... No sh
> >script should be more than 20 lines, however, I typically will call
> >shell scripts from
> >> other scripts. But I do agree, if you want to program, use a
> >programming language. (IMHO, C is still the best, most powerful
> >language around but, again,
> >> read a book, talk to the people who are in the know - My 'C' guru is
> >a guy who has written code that utterly shocked me in its elegance,
> >execution, and
> >> simplicity - and the occasional "You can do something like that in
> >C?" thoughts running through my head.)
> >
> >The distinction between programming and "scripting" has always been 
> >artificial to me.  You write a series of instructions for a computer, 
> >that's a program.  Give me powerful tools, I'm not interested in doing 
> >it the hard way to build character.  I have enough character. What I 
> >want back is the time I spend trying to fix sh scripts.
> 
> 
> Interesting debate this. Personally I have always regarded
> sh as a Job Control Language. Probably showing my age.

Well... JCL is more like a "declarative thing", comparable
at least a bit to Solaris SMF, or maybe even systemd... :-)

Using those "characteristic classes" (or programming paradigms),
sh would be an "imperative thing", as it causes actions
directly, instead of having a different subsystem dealing
with the actual programs depending on descriptive text,
i. e., the job deck.



> As such it's intended for controlling jobs written in 'C'
> (being Unix). All it had to do is put the data in the right
> place for input, and arrange for the output to end up where
> it should. In no way should it be used for implementing an
> algorithm.

Additionally, sh is - like JCL - a tool to _combine_ programs
(the steps inside a job), when they need to be run in a
certain order depending on exit code, or piping the output
of one step to the input of the next step.



> Now people are trying to write programs in it. Why? I suspect
> its because people haven't invested the time to learn a
> programming language, as it's quicker to find some cunning
> way of perverting the JCL one problem at a time.

One of the "stupidest" (and actually quite clever) things is
using the null program IEFBR14 (equivalent to /usr/bin/true)
to do things like file creation or deletion. As you see,
even the strictly controlled JCL does actually allow you
to do stupid things, because that's needed in order to do
clever things with it. :-)



> Do spreadsheet macros count as programming? I've seen complete
> business management systems written in Excel macros.
> Unmaintainable and flaky, but I'm in awe that anyone did it.

You can write good and bad code basically in any language.
Some languages encourage bad ideas, bad style, errors, or
"put everything into one place", other languages demand
a certain education and experience to be a good tool (other
than the "shoot your foot" kind of tool).



> And if I get too sniffy about the use of structured "proper"
> languages, I think back to the days of assembler and even
> machine code. Do the primitive building blocks of assembler
> count as programming? It's hard to argue otherwise, so
> therefore the primitive building blocks of sh have to count
> too.

They _are_ building blocks, and using them to solve an
actual program can validly be called programming. I don't
see any problem here.



> That said, I was really happy when I could start using 'C'
> in the early 1980's. The perfect blend of convenience and
> control of the CPU.

No matter which new programming language I learned during
my "career", I always come back to C as my favorite language.
I'm not stupid enough to claim "one size fits all" for C,
as certain tasks can be easier be solved with different
tools. But if you wanted, there would be no problem writing
a feature-rich LOB CRUD bullshit application in C. However,
the language doesn't deserve such a treatment. :-)



> You do need to invest the time to learn a compiled language
> like 'C'. Friendly interpreted languages are considered
> cheaper to use  because the staff need less training - or
> assumed to be. I'm not so sure.

The costs you save on proper training will later return as
costs for maintenance, bugfixes, and expensive consultants
to save your ass in case of fire. The common "business thinking"
is short-term costs vs. long-term costs. Build something for
cheap that partially works - make money. Bugs? Deal with them
later on, or just leave it. It's a hackathon project anyway
so some venture capitalist will pay $100M for "the next big
thing"... :-)



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...