"This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."

Douglas McIlroy

Bash (and its derivatives) have been present in the history of computing for more than 30 years and although it has never been considered a pivotal language for innovation, it has helped many developers to make their work less monotonous.

It is both a command line interpreter (Unix shell) and a scripting language for (in principle) unix-based environments. Like most Unix shells, it supports wildcard matching on filenames, pipes, command substitution, variables, and control structures for condition and iteration tests. Keywords, syntax, dynamically scoped variables, and other basic language features are copied from sh. Other functions, for example history, are copied from csh and ksh. Bash is a POSIX-compliant shell, but with various extensions.

The shell’s name is an acronym for Bourne Again Shell, a pun on the name of the Bourne shell it replaces and the notion of being “born again”.

This is a small introduction to a project that I have been working on privately for some time, in order to organize functions, aliases and environment variables in a way that makes sense and can be scaled.

Motivation

I’ve been using the bash terminal for a number of years to shorten the time I regularly do with a GUI, but as the projects I work on grow in complexity, the number of commands I have to use to compile, package and uploading code to test devices (I work in networking) increases as well. I think that, as I have described in a previous article, it takes a lot of creative energy to work on software development, and every time we spend 10 seconds trying to type or remember some complex command in the terminal, we lose some of that energy that helps us to make decisions that are relevant.

Time management is crucial to being a successful developer, not only to deliver work on time, but to ensure quality and optimization when a problem is fixed.

Mathematics does not fail in that sense, if I lose about 8-10 seconds every time I have to test a change, assuming that it takes me about 10-15 minutes to write a significant amount of code, I would be losing between 20-29 hours a year just doing work mechanic and on projects like the one I work on these numbers can be doubled or tripled.

Yes, it seems obsessive-compulsive to count this time, but the time lost in mechanical work is not what is relevant, it is the time lost in truly creative work.

The idea

It was very simple, being able to have a project that met the following characteristics:

• Be scalable, allowing the separation of interests (having functions for networking is not the same as having aliases for git).
• Be easily exportable to other platforms (operating systems, servers, raspberry pis, etc.), so its processing has to end in a single exportable file (envrc)
• That its adaptability was simple, that when you need to add a new command or configuration, its place makes sense from the beginning.

File organization

Choosing the organization of the files was not so difficult when I had a clear idea, the result was the following:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

/
  config        # Directory to add all the configurations that go in the ~/.config
    jrnl        # Example: My default settings for jrnl.sh
  env           # Directory in which the scripts are stored separately
    git.sh 
    global.sh
    media.sh
    network.sh
    personal.sh
  rc            # Specific settings for rc files (from bc, the calculator, for example)
    .vim
    .bc
    .vimrc
  Makefile      # File that helps build the .envrc in installing the environment using the make tool
  deploy        # Script that helps to upload the development environment to an external host (rpi, server, etc.)

Scripts

Scripts are internally organized into: environment variables, aliases, and functions. For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

#!/bin/bash

###############################################################################################
#                                                                                             #
#                                        PERSONAL ENV                                         #
#                                                                                             #
###############################################################################################

HUGO_SUPPORTED_LANGUAGES=("en" "es")
EMOTIONS_TEMPLATE=/home/jpgarcia/journals/templates/emotion.txt

###############################################################################################
#                                                                                             #
#                                        PERSONAL ALIASES                                     #
#                                                                                             #
###############################################################################################

alias hpost="hcontent posts"
alias hproject="hcontent projects"
alias emotion="jrnl emotions < $EMOTIONS_TEMPLATE && jrnl emotions -1 --edit"

###############################################################################################
#                                                                                             #
#                                        PERSONAL FUNCTIONS                                   #
#                                                                                             #
###############################################################################################

function hcontent() {
    if [ ! -d content/$1 ]; then
        echo "You must be on a HUGO project directory. Or create a base directory for content/$1."
    else
        if [ -z "$2" ]
        then
            echo "You have to provide a valid $1 slug (e.g: first-post)"
        else
            for VARIABLE in $HUGO_SUPPORTED_LANGUAGES
            do
                hugo new $1/$2/index.$VARIABLE.md
            done
        fi
        
    fi
}

function jrnl() {
    if [ $MACHINE = "Mac" ]; then
        /usr/local/bin/jrnl $@
    elif [ $MACHINE = "Linux" ]; then
        ~/.local/bin/jrnl $@
    else
        echo "jrnl.sh not found for $MACHINE"
    fi

    if [ -d ~/journals ]; then
        cd ~/journals
        if ! git diff-index --quiet HEAD --; then
            git add --all
            git commit -m "Log $(date)"
            git push origin master
        fi
        cd -
    fi
}

The special touch

What makes this an interesting project is that no matter how many files, functions and environment variables are added, with the use of the Makefile, all these files are converted into one with a ‘merge’ function:

1
2
3
4
5
6
7
8
9

merge_env:
	if [ ! -f envrc ]; then \
		echo "Generating envrc file"; \
		if [ -f /tmp/envrc ]; then \
			sudo rm /tmp/envrc; \
		fi; \
		touch /tmp/envrc; \
		cat env/*.sh > /tmp/envrc; \
	fi

The envrc file is temporarily generated and then copied to the preferred directory (in my case /etc).

And to finish

With bash you can control virtually any part of the operating system that is running. It is the gateway to it, therefore, having a personal and adaptable development environment will always make your work possible with the least amount of non-creative activities possible.

The complete project is published on github and you can find it at the following link.

It is well known that software development is not usually associated with artistic but technical disciplines; Universities all over the planet are faced with the challenge of teaching software as an “engineering” or a “science” oriented to being exact, something that intelligently already revealed as a contradiction in itself Edsger Dijkstra in his EWD 1036 titled “On the cruelty of really teaching computing science” in 1988.

A number of these phenomena have been bundled under the name “Software Engineering”. As economics is known as “The Miserable Science”, software engineering should be known as “The Doomed Discipline”, doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter “How to program if you cannot.".

Without going into the extensive debate that has already taken place on this topic, I start from this hypothesis that poses as impossible the development of software as a civil engineer would do in a work, or a mechanical engineer with a piece. The software is different, although they can be tools, mathematics, exact sciences and natural engineering practices cannot be applied to the construction of the software. So it is not clear how to define software development, this is what I propose to answer today.

Utilitarian art

It is one that incorporates the ideals of composition and creativity to everyday objects such as a magazine, a lamp or a mug. It is important to note that not all objects created are art in themselves, since it requires that their elements be organized under the same aesthetic sense.

UI/UX - @halacious at unsplash.com

The beauty in coding

Not satisfied with the essential utility of any software product, there exists within the same discipline a tendency to simplify abstraction models, programming languages and even development environments with the sole purpose of making the job more “pleasant” for the software developer.

This trend begins to be important after the creation of the BCPL language designed by Martin Richards at the University of Cambridge in the 1960s, trying to simplify the CPL (Combined Programming Language) developed by the Laboratory of Mathematics at the University of Cambridge and the Computing Unit at the University of London making it more elegant, orderly and easy to adapt. This same trend was followed for the creation of the B language and later for the mythical (and still current) C language.

In summary, the history of the development of programming languages goes according to the creation of languages that, not only can extend the complexity of the abstractions proposed in the so-called “computer science” such as memory use, concurrent programming, functional or object orientation, but also facilitate reading and promote their beauty. Two clear examples of this are the programming languages Ruby and Python to which their developers wrote a series of rules called “The zen of python” in which they stand out:

• Beautiful is better than ugly.
• Explicit is better than implicit.
• Simple is better than complex.
• Complex is better than complicated.
• Flat is better than nested.

And in the case of Ruby, its reflexive and simplicity-oriented design allows the creation of code not only understandable, but with all the aesthetic components:

1
2
3
4
5
6

#Fibonacci sequence in Ruby 
def fibonacci( n )
  return  n  if ( 0..1 ).include? n
  ( fibonacci( n - 1 ) + fibonacci( n - 2 ) )
end
puts fibonacci( 5 )

Ontology as a starting point

Ontology is a branch of philosophy that aims to study what exists, as well as the relationships between existing entities, it is also called “general metaphysics”.

There is a great ontological component in the development of software, coming from being a profession in principle marginalized, not relevant and relegated to women evidently despised in their time (who at the time were just beginning to be included as part of the academy and forces labor), it was one of them (Ada Lovelace) that formally created the first computer program.

It is no coincidence that a discipline that was started and dominated by women in its early stages was subject to endless influences from all branches of existence, from aesthetics to science. Women, being the gender most associated with the social sciences ¹ , had a positive and definitive impact on the subsequent ontological evolution of software development.

Grace Hopper, known to her friends as "Amazing Grace"

The influence of women in this sense is invaluable, examples of this are abundant, such as Grace Hopper being the creator of the first compiler in history or Margaret Hamilton who develops the “on-board” navigation software for the Apollo Space Program.

Another nice example of ontology applied to programming is written by Randall B. Smith and David Ungar in a paper entitled “Programming as Experience: The Inspiration for Self” specifically in a section dedicated to their motivation for writing it:

Programmers are human beings, embedded in a world of sensory experience, acting and responding to morethan just rational thought. Of course to be effective, programmers need logical language semantics, but theyalso need things like confidence, comfort, and satisfaction — aspects of experience which are beyond the do-main of pure logic.

A look to the future

In all areas of humanity, history tends to repeat itself, as we saw in the plastic arts, going from cave paintings to the intensity and precision of Renaissance art, then to the depth of Baroque to reach the maximum expression of simplification with conceptual art likewise we can reduce the history of software development from incipience to intensity and depth ending in maximum simplification.

Contrary to popular thinking, which expresses that software development has a tendency to disappear with the advance of artificial intelligence, just as it happened in the plastic arts, I believe that the future of the trade is destined for us to work on concepts rather than on implementations. There are several examples of what this means, the most recent and famous Github Copilot.

Humans advance because we are the only animals that can think of concepts, myths and we can express it through language. All these abstractions and motivations will continue to exist despite the development of tools that help us improve ourselves.

Conclusion

Software development is a profession oriented towards artistic expression, the best representation of this being video games, but also from a non-contemplative but utilitarian point of view, programming focuses its efforts on creating more and better abstractions for more beautiful results.

"It made the mysterious become diaphanous"

Daniel Molina