Being a bash developer in the twenty-first century

Programming is a drug. A successful program run is not unlike getting a good careless drag of a menthol cigarette after sweaty workout session, still riding the crest of runners' high endorphin rush.

And just like any drug, you build a tolerance to it and start chasing new highs.

I got hooked on bash as soon as I learned there are proper conditionals and loops on it. Thankfully PHP came along and doomed me to decades of writing systems of questionable reputation and quality with short interludes in a corporate self-indulgence that is .NET; but when I came back from that interlude, to my astonishment PHP had improved to a point where it could be considered by optically challenged to be an almost first-class programming language, with package management, mature frameworks, proper OOP, unit tests and bells. The whistles had been missing and were well within the roadmap PHP 8, or whatever.

However, I had been cursed with knowledge of PHP prior to 5.2 and versed in procedural-style (or, to be honest, goto-style) programming from the old days, when you could just

10 PRINT "HELLO WORLD!"
20 GOTO 10

and reach for the reset button because ^C had not been invented yet on an all-metal Z80 clone with 256k of RAM running a clone of CP/M called SCP.

Where was I? Oh, right; so when other people looked at the framework automagically collect and inject relevant services by tags with fascination and were content with accepting an explanation of how it works as magic and would respectfully whisper "have you heard? He optimizes container bootstrap by hand!" about their colleagues, I would have already peered into the bowels of the beast and seen that the newest PHP emperor still has the same shameful PHP bod under the fancy robes hiding the same shame it had when it used to be a Personal HomePage.

It so coincided that at the moment, following the cybersecurity laws being passed with great haste and little oversight, with wake of ACTA fresh on my mind, I was pretty involved in a hobby project that would maximise the bandwidth using multiple VPN connections. Since I was doing system programming of sorts and had not yet tasted the forbidden fruit of go, of course I chose bash for the job (as a part of good opsec practices, I of course created a separate gh account for that).

If you had followed that link and took a look at that monstrosity, you probably see that it was approaching unmaintainability at relativistic speeds. This, combined with knowledge that people managed to cover up PHPs' vicious innards, brought me to the next logical step: my own bash framework with blackjack^H^H^H^H^H^H^H^H^H components and tests. I threw in a dependency downloader and "OOP" support just for fun and named it "Bash With Nails".

Anyway, it was all good fun and I still use it for some hobby projects that have a tendency to run off, feature wise.

I can trace back the moment when I broke to when I tried to make a lightweight site running on XML+XSLT1.0, and I had to wade through metric tons of crap just to output XML to stdout. In our infinite wisdom, we have exchanged writing boilerplate code for writing configurations and having, like, three types of applications. Using frameworks indiscriminately has left us with a "Any colour you like, as long as it's black" type situation.

But I digress.

The moment of breakage was when I finally had enough of all the crap and simply put an "index.php" on webroot that contained all the stuff i needed for my semi-static application (5 functions and 10 lines of glue code, all fitting within 100 lines) and none of the thousands of thousands of code lines of "lightweight framework" I never needed and would need to maintain as of course in these ~200kb of code there are bound to be bugs and security issues, and probably going forward something would change architecturally, so I'd have to adapt my code for the new and improved framework or get stuck with the old version and all the deities forbid I would change the language version, that would probably warrant a major version change that would definitely make it a work effort directly proportional to my application size and complexity.

AAAAAAAAAAAAAARGH!

There are people who revel in this dynamic environment as it's always exciting and you're on the top of things happening and it probably gives a good job security going forward and you can brag on hackernews how you made a modern website in 2021.

I see this kind of complexity as something that is undesirable, and this is the reason that I can actually go to my storage, take a hard disk from 2006, take code that is on it, and run it on PHP8. It's stupid, but it works.

But I'm off on a tangent again.

One of the few things I loved about the old and unrefined PHP was that you could play with it. As Alan Watts put it so eloquently: "You don't work the piano, you play the piano". You would just drop the "index.php" file, point the browser to it and, voila, your app is online. Framework being a framework puts you in some, for the lack of better word, frame. And it's not frameplay, it's framework. You work it and get rewarded for not stepping outside the frames.

Consider the difference between this and the joy of terminal: where you take stdin, pipe it through, and write into stdout (or stderr). Where your cause and effect are instantaneous. A tool that you're so used to using that when you open up a bash shell, you suddenly feel at home. After all, it's what welcomes you on every server you own and any system you don't play games on.

Considering how rich the toolset of a typical unix-like operating system is, it is only logical to use the tools at hand. Of course the tools have their own quirks and require a different mode of thinking and it's probably difficult to consider the shell outside the bridge solution scope, but it is possible to write functional programs using bash and they still contain a third of code of "lightweight framework" that can only output "Hello World!". Sure, you'll have to take HTTP headers from environment variables and parse the HTTP body yourself, but the framework doesn't actually do that - PHP does. And you'll never forget how things work.

So now my go-to language is bash. Boiler on/off control? bash via cgi-bin. Temperature readings and putting them in grafana? bash. Online radio control using icecast? bash. GUI for said radio? bash. Http server? bash.

I guess it's true what they say: bash truly is a cursed hammer, which, when wielded, makes everything look like a nail. Especially your thumbs.

But no other hammer can scratch that itch.