
Glue Languages Make You a Better Coder - joshuacc
http://zachholman.com/posts/glue-languages/
======
lysol
If shell were a brand new language, made in someone's basement, it would be
immediately shat upon. But its ecology and ubiquity make it 'good enough'. But
really, shell programming is awesome in its simplicity. Bash syntax is a bit
clumsy but every commandline application ever written for unix is a new
library, provided it spits out reasonably predictable output. If unix
applications are hunks of oddly-shaped and designed metal, shell programming
is the arc welder. (Yes, I know I'm blurring the line between bash, sh, zsh,
and the like, but they serve the same purpose.)

~~~
bitops
I'm waiting for all the Java-bashing Rubyists out there to discover csh. If
you need to do "real programming" csh is pretty great and has a more
"programmery" syntax than a lot of the others.

But, YMMV.

~~~
jleader
Way back when I was young and first learning shell scripting, I was taught not
to use csh for scripting. Is that no longer true? Have the problems described
here <http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/> been fixed in newer
versions of csh, or in tcsh?

~~~
bitops
Okay, I'll take the bait.

When I ssh into our Solaris server, it drops me into csh by default. That
makes me think someone out there believes it's good enough.

~~~
zdw
That's not the default (/bin/sh is on recent versions of Solaris, which is
fairly primitive), so your sysadmin is probably the person who thinks it's
"good enough".

Nearly all Solaris systems I've worked on and set up have a sun freeware or
CSW system set up on them with all the standard "linuxy" tools installed, so
the change isn't that weird.

~~~
bitops
This was on a Sun Fire X4500 box set up by a sysadmin who I know for sure is
not a csh guy. Could be that it was different for some reason.

------
scott_s
I suppose it's also true that your day-to-day development language may be
someone else's glue language. There's probably hardware people who consider C
their glue language.

I use Python for all of my scripts. The moment that I want to automate some
system related task that requires any logic, I reach for Python. (I'd still
write a bash "script" if the script was just a succession of commands.) I
don't think this is a controversial position since Python is considered a
cousin of Perl, and Perl was heavily inspired by shell scripts, awk and sed. I
think of Perl and TCL as the original glue languages.

If I'm writing a script from scratch, I just don't see any compelling reason
to do it in bash. (Or whatever your shell of choice is.) Yes, I recognize that
"Python may not be available" is a potential reason, but it's not compelling
to me because it's available in the places I'll need to work.

~~~
pnathan
Agreed. I've been up to my armpits in other peoples' SH at times. It has a
long list of defects which will come around and bite you.

I have taken the policy of moving any SH script I write to Perl (or Python)
after it breaks about 45 lines (a page). I get good error checking, type
checking, reliable escaping, and the ability to neatly abstract into modules.

So far, it hasn't hit me in the face yet. :-)

~~~
mturmon
Of course everyone does what works for them.

But I have to say that I think the 45 lines rule is not the best criterion.
Lots of scripts which are of the form "move these files around, run this
command on the files, mangle the output, send it to this command to summarize,
send to another command to pretty-print" can be long in line count, but are
really well-done in shell. Basically, operation sequencing, and/or line-by-
line file processing.

Shell makes it easy to ensure tempfiles are deleted, to catch signals, to
automatically check error status of each and every command.

As you note, sometimes shell is "contraindicated" (as they say in medicine).
Anything needing data structures, or abstraction beyond simple functions, is
not so good for shell.

------
sidman
I think the blogs comments regarding javascript are less true then that
regarding shell as javascript is becoming a core language no longer only
active in the web "glue language" domain.

In the web context within HTML it maybe but in terms of mobile development
using tools such as titanium/appcelerator or developing things in node.js,
this requires javascript not as just a glue language but as the core.

In terms of shell, yeh, I think it still applies cause to this day i havn't
seen anyone write a fully blown program completely in shell (thought that
could just be me).

What i noticed in all the places i have worked at, when the shell
script/program starts to get to large its usually slowly migrated to perl or
<insert persons fav scripting language here>.

------
crazydiamond
I've written stuff in shell over many years (I don't claim to be an expert,
just average) but its not always smooth esp when I upgrade or change OS's.
Most shell programs will make calls to other commands. These commands do not
have standard arguments across unixes. Take the OSX (BSD) date and linux's
date. On one machine I may have installed coreutils with default_names, on
another without.

Sometimes, this forces us to make quick trips into perl or awk (to get
yesterday or tomorrow). However, shell scripting has certainly made me more
__productive __over the years. For most of my initial programming life (90's),
I've generated boilerplate code using shell (often with awk).

------
eddardstark
"Node is just more accessible in JavaScript than if it were written in Ruby."

Why? I don't see anything special in JavaScript's syntax that makes it more
accessible. Node's asynchronous callback style would be a perfect fit for
Ruby's block syntax.

~~~
jcarden
I'm curious about this statement as well. Any leads ?

------
msie
_This is even apparent in shell: rvm, a platform-agnostic Ruby installer, is
substantially written in shell rather than Ruby._

I hope so! :-)

~~~
saraid216
That comment didn't make sense to me. Why would a script that installs Ruby be
written in Ruby? Isn't that the very definition of the chicken-and-egg
problem?

~~~
holman
I think rvm could have a lot more Ruby code in it- Wayne (the author) does a
lot of things in shell that could feasibly be abstracted away in Ruby. I
happen to really like that, although I think it goes against the grain of what
most Rubyists think- others would probably do the bare minimum in shell and
quickly jump into Ruby as soon as it was feasible.

