Which programming language do you refuse to learn and why?

As a Linux/Unix expert with about 20 years of professional experience, I refuse to learn shell scripting languages at an advanced level.

Obviously, I know the basics. I can do loops, pipes, if/else conditions, cases and all that; I also know the ins and outs of the usual tools like grep, sed and awk. That’s enough to effectively do ad-hoc tasks in the command prompt. Most people watching me work like this would probably say that I am quite advanced in my use of the shell and associated tools.

In reality, I am not a very good bash/ksh/sh/other programmer, and that is by choice.

Once you stop doing little one-off command line manipulations (where the shell is a very effective tool) and start writing scripts that run consistently in production, you enter the realm of software development.

And from the perspective of software developers, the shell is a totally inadequate tool. In fact, it’s really nothing more than a glorified macro processor with a few control structures thrown in.

Once you start doing advanced programming with shell scripts, much of your code will have to deal with the shortcomings of the language instead of your real problem. It becomes especially bad if you have to deal with variable values (such as filenames) that contain spaces. Instead of dealing with this, many shell programmers choose to ignore the problem by telling everyone that spaces in filenames (or any other string) are not “the Unix way”. But think about it, what century are we living in?

Essential data structures such as associative arrays (or any array for that matter) were not available in the original Unix shell. Of course, they are available in modern variants like bash, but they were added on top of it and it shows. The syntactic clutter required to use them correctly can break your brain. Just to give an example, in ksh, if you have an array called “foo” and you want to pass it to a command called “bla” with proper handling of elements containing spaces, the syntax used is:

bla “$ {foo [@]}"

It’s intuitive, isn’t it? I’m sure you would have figured it out the first time if you were asking yourself “how do I pass an array to a command?”. Similarly, many other features will only be accessible if you memorize the specific combination of special characters you need to use them properly, instead of being able to call them with an obvious, memorable name.

I have seen many examples of shell scripts used inappropriately; scripts exceeding 1500 lines and costing my company money every day. Since they run critical production and fail over and over again, seasoned professionals have to spend hours inspecting the scripts to try to figure out what the code is trying to do and why it’s not going to work.

Besides all that, I manage to write shell scripts from time to time, but only very small ones. For anything that requires more than like 15 lines of code, I choose another language, like Python. Sometimes it’s much more verbose than an equivalent shell script, but it’s also much more readable (that really counts in software development), and it won’t make you fiddle around with “advanced concepts” such as spaces in strings. Python also provides an excellent library for accessing most system-level APIs without having to call external commands and figure out how to interpret their incomprehensible success or failure feedback.

Welcome to the 21st century.