TL;DR – because for me there is no good programming language.
I’m doing mostly systems engineering tasks. I manage resources in Cloud and on Linux machines mostly. I can almost hear your neurons firing half a dozen names of programming languages. I do realize that they are used by many people for systems engineering tasks:
The purpose of this post is not to diminish the value of these languages; the purpose is to share why I don’t want to use any of the languages above when I write one of my systems-engineering-task scripts. My hope is that if my points resonate with you, the reader, you might want to help spread the word about or even help with my suggested solution described towards the end.
So let’s go over and see why I don’t pick one of the languages:
Why not language X?
- Missing smart handling of exit codes of external processes. Example in bash:
if test -f my_file(file is not there, exit code 1) vs
if test --f my_file(syntax error, exit code 2). If you don’t spot the syntax error with your eyes, everything behaves as if the file does not exist.
- Missing declarative primitives libraries (for Cloud resources and local resources such as files and users). Correction: maybe found one, in Perl – (R)?ex ; unfortunately it’s not clear from the documentation how close it is to my ideas.
All languages except bash
- Inconvenient/verbose work with files and processes. Yes, there are libraries for that but there is no syntax for that, which would be much more convenient. Never seen something that could compare to
my_process > my_fileor
echo my_flag > my_file.
- Error handling is a must. When I write a small script, it’s more important for me for it to be concise than to handle all possible failures; in many cases I prefer an exception over twice-the-size script. I do understand how mandatory and explicit error handling can be a good thing for larger programs or programs with greater stability requirements.
- Dependencies problem seem to be unresolved issue
- Functional programming is second level citizen. In particular list/dictionary comprehension is the Pythonic way while I prefer
filter. Yes, that’s probably one of the features that makes Python easier to learn and suggested first language. Not everything that’s optimized for beginners must be good for more experienced users. It’s OK.
- Mixed feelings about
array[slice:syntax]. It’s helpful but
slice:syntaxis only applicable inside
[ ], in other places you must use
slice(...)function to create the same slice object
Ruby and Perl
- The Sigils syntax does not resonate with me.
I can’t put my finger on something specific but Ruby does not feel right for me.
- Maybe it’s the hype residue.
doblocks where I’m never sure what’s the context is and which methods and available along with DSLs utilizing this feature. Oh, just found the reason I’m confused. It’s not me! “Using instance_eval changes the rules for the language in a way that is not obvious when reading a block“. Hello, Chef!
- Maybe it’s the proc/block/lambda instead of one something.
- There is one thing for sure, True and False should have some common superclass, not just Object.
- Special variables with non-word names
- Methods aliases such as
count. Why spend my mental energy deciding?
- Contexts and automatic flattening of lists in some cases make the language more complicated than it should.
- Object orientation is an afterthought.
- Functions that return success status. I prefer exceptions. Not the default behaviour in Perl but an afterthought: autodie.
- Overall syntax feeling (strictly matter of personal taste).
Note that bash was created in a world that was vastly different from the world today: different needs, tasks, languages to take inspiration from.
- Missing data structures (flat arrays and hashes is not nearly enough).
jqis a workaround, not a solution in my eyes.
- Awkward error handling with default of ignoring the errors completely (proved to be bad idea)
- Expansion of undefined variable to empty string (proved to be bad idea)
- -e , -u and other action at a distance options.
- Unchecked facts but my feelings:
- When bash was created, it was not assumed that bash will be used for any complex scripting.
- bash was never “designed” as a language, started with simple commands execution and other features were just bolted on as time goes by while complete redesign and rewrite were off the table, presumably for compatibility.
- No widely used libraries (except few for init scripts) and no central code repository to search for modules (Correct me if I’m wrong here. I haven’t heard of these).
My suggested solution
I would like to fill the gap. We have systems-engineering-tasks oriented language: bash. We have quite a few modern programming languages. What we don’t have is a language that is both modern and systems-engineering-tasks oriented. That’s exactly what I’m working on: Next Generation Shell. NGS is a fully fledged programming language with domain specific syntax and features. NGS tries to avoid the issues listed above.
Expected questions and my answers
People work with existing languages and tools. Why do you need something else?
- I assume I have lower bullshit tolerance than many others. Some people might consider it to be normal to build more and more workarounds (especially around anemic DSLs) where I say “fuck this tool, I would already finish the task without it (preferably using appropriate scripting language)”. I don’t blame other people for understandable desire to work with “standard” tools. I think it’s not worth it when the solutions become too convoluted.
- I am technically able to write a new programming language that solves my problems better than other languages.
Another programming language? Really? We have plenty already.
- I would like to remind you that most of the programming languages were born out of dissatisfaction with existing ones.
- Do you assume that we are at global maximum regarding the languages that we have and no better language can be made?
Update: following feedback roughly of the form “Yes, I get that but many Ops tasks are done using configuration management tools and tools like CloudFormation and Terraform. How NGS compares to these tools” – there will be a blog post comparing NGS to the mentioned tools. Stay tuned!
Have a nice day!