Mihai Bojin
2 min readJan 24, 2019

--

Broken shell (free for reuse on Pixabay)

Wow! As long as I can remember I was fascinated with coincidences and the probability of an idea being born in two different people, without them ever having any contact with each other! One such example is, Orwell writing 1984 without any record of him having read Foucault’s Discipline and Punish (The Panopticon).

I too feel the same way about bash (POSIX-compliant shells, really), how antiquated they are and how we all keep going with the flow, using hard to reason syntax that was invented over 30 years ago, got standardized, and then became part of our daily lives (though probably few of us really know why and how POSIX came to be)!

Much like the five monkey experiment, we (people in tech) are blindly following along, writing hard to read, convoluted code, finding ways to make our shell experience better, putting lipstick on the gorilla while trying to forget just how awful (by today’s standards) POSIX-compliant shell scripting really is! To add insult to injury, a large number of “helper” libraries have cropped up, each promising solutions and simplifications of the core problem; we are trying to fix the symptoms, but are ignoring the root cause!

To be clear, I am not trying to cast a shadow on all these wonderful people who have put in tremendous effort to write libraries that make our day to day lives better! I’m merely challenging where the focus was spent!

Around November/December last year I said to myself, enough is enough and started compiling a list of features that a modern shell should have. I also started looking into how to write an interpreter and, funnily enough, bought Thorsten Ball’s Writing an Interpreter in Go book. I started reading it and realized I had to learn Go first…

Christmas got in the way, and while I managed to get to a basic level of Go, I haven’t made any progress towards writing any code for a next-gen shell (the codename for my project.)

After reading this post, I’m glad I didn’t!

I try to keep myself honest and resist all urges to fall into the trap of the Not Invented Here Syndrome! We, inventor types (a group I believe developers fall into), tend to think that only us and us alone can adequately solve a problem. We end up working alone or in small isolated groups, all the while duplicating effort without managing to have any measurable impact or industry traction!

It is much better to work in teams, bouncing ideas off each other (also getting new ones in the process), and combining our energy to reach a shared goal!

I will put in some time over the next few weeks to finalize the specifications document I’ve been working on, and then reach out to Alex to see what makes sense for ABS’s future!

Mihai.

--

--

Mihai Bojin
Mihai Bojin

Written by Mihai Bojin

Software Engineer at heart, Manager by day, Indie Hacker at night. Writing about DevOps, Software engineering, and Cloud computing. Opinions my own.

Responses (2)