Bash should have been the greatest scripting language of all

The scripting Balkans

You cannot invoke functions contained in a script written in Python in another script written in Node/JS. So, what are we going to do? Are we going to rewrite these functions in Javascript? No, because the idea was to reuse someone else’s work in ours. Therefore, I am usually not going to waste my time porting Python to Javascript or the other way around. The solution is therefore to call the Python script as an external program in my javascript script. Instead of writing:

y = f(x1,x2)

We will write:

y = exec(“/usr/bin/prg -func f -arg1 {x1} -arg2 {x2} “)

(Note that the string interpolation in the exec function should obviously escape the shell arguments correctly.)

External process execution is a solution, not just to the scripting Balkans, but to the entire programming Balkans. It does not matter in which language the program prg was written. Every programmer can use his own preferred programming dialect, while we can still reuse his work. As long as the program executes a meaningful amount of work, process/program chaining is very usable substitute for function chaining.

Therefore, Bash has its fundamentals right, by providing at the heart of the language the process chaining primitives that facilitate code reuse of external programs.

What is wrong with Bash

Its horrible syntax for strings, lists, and tables creates a programming nightmare:

echo ${#stringZ}

Yes, it does something, but I guess that you cannot guess what exactly. It does the same as what the following would do:

echo strlen($stringZ)

echo $stringZ.length()

Now you probably guessed correctly what it does. So, yes, Bash certainly wastes our programming time by forcing us to endlessly Google for what its horrible syntax means. Instead of doing something useful, we are now supposed to look up what its diarrhea of punctuation mess is all about:

for sound in “${!animals[@]}”; do echo “$sound – ${animals[“$sound”]}”; done

The syntax above is truly abnoxious. Close your eyes and try to write down that statement again. When they designed this mess, did they really  believe that people have no better things to do than to remember that kind of trash? This kind of syntax is totally disrespectful of the users and their precious time. Furthermore, there is absolutely no need to do it that way. No other scripting engine forces you into that kind of mess. So, they can’t say that there is a compelling reason for this, can they?

How much punctuation mess do we need before all our needs for punctuation mess have completely been satisfied?

Another problem is that the user-defined functions in Bash cannot return something like a table or a list or even a string. We do this all the time in other scripting languages. Therefore, the excuse cannot be that the user should not want to desire to do this. He does it elsewhere already and successfully so!

Besides that, there is also no way to load native foreign functions (FFI). Users do this all the time in other scripting languages. So, again, they cannot argue that there is no need for this. There is obviously a real need to do so, while Bash does not allow it.

Bash is a GNU project

Like in all other GNU projects, there is no real user community around Bash:

http://www.gnu.org/software/bash

The GNU project does not want to use infrastructure such as github — which is understandable — but they do not use any alternative either. They use a mailing list. That amounts to systematically sending the entire issue list to all users, even if they are interested in just one single issue. Mailing lists generate too much noise. Users do not like them.

The Bash documentation does not contain user comments. There is no user interaction there either. In theory, users would be encouraged to explore the GNU sources, as these sources are supposedly licensed under the GPL, but in practice these sources are also exceedingly difficult to find and manipulate!

The GNU project could impossibly be listening to their users, because with what infrastructure exactly would they be doing that?

Furthermore, if you ever manage to talk with Bash maintainers — just try to get hold of someone and you will see what I mean — you will understand that they are impossibly conservative. They seem to think that the existing Bash implementation is pretty much what it should be. There is surely no need to fundamentally improve it!

Conclusion

In order to tap into the wealth of existing external code, it is necessary to favour process chaining over function chaining in that context. It opens the door to reusing way more source code than just sticking to your own scripting language. In the internal context of our own programs, however, there is no need to do that. There we need first-class functions. Unfortunately, Bash does not have them. Furthermore, Bash suffers from the same self-inflicted source code readability issues as Perl. This problem — understandably — turns Bash into a non-starter for many programmers. All the syntactic noise and punctuation mess could easily be replaced by functions, just like in other scripting languages. In short, we need a shell scripting language that avoids these pitfalls.

Advertisements

Published by

eriksank

I mostly work on an alternative bitcoin marketplace -and exchange applications. I am sometimes available for new commercial projects but rather unlikely right now.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s