ZX – A tool for writing better scripts

I've very rarely seen, say, image viewers which can't handle a JPEG with a .png extension or vice versa, but they're badly designed. Most handle this from the file magic automatically. Keying on extension is definitely an antipattern IMO.

I don't see people naming C++ files .c++03, .c++11, .c++17. I don't see people naming Perl files .pl-strict-mode.

Yes, it's normal for people to use file extensions, but having programs impose forced usage and semantics to them is a crutch and a sign of bad design.

How am I supposed to put a script written using this tool in $PATH?

This bad design seems to be a thing in the TS/JS ecosystem now. At least some language ecosystems (Deno? Not sure.) seem to be encouraging people to do 'import ".../Foo.ts"'. Which is abysmal: Firstly these are URLs, yet file extensions are against web principles and good URL design. Secondly they couple a consumer of a module to what language the module was written in and expose this as part of an API, which is terrible design.

"Bash is great, but when it comes to writing more complex scripts, many people prefer a more convenient programming language."

https://google.github.io/zx/getting-started

I read this and think "1. Bash is not great. 2. Why assume that I want to write complex scripts."

I like simple scripts. I am embarassed by any complexity. It is the mark of a cluttered mind.

As it happens, there have been and still are others that dislike complexity, though they may be greatly outnumbered.

Right now there is another submission in /active on HN titled, "A 2024 Plea for Lean Software. Why Bloat is Still Software's Biggest Vulnerability"

"I want to end this post with some observations from Niklaus Wirth's 1995 paper:

"To some, complexity equals power. (...) Increasingly, people seem to misinterpret complexity as sophistication, which is baffling-the incomprehensible should cause suspicion rather than admiration."

I've similarly observed that some people prefer complicated systems. As Tony Hoare noted long ago, "[T]here are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors." If you can't do the first variant, the second way starts looking awfully attractive perhaps."

And scripts are not even systems. The idea of intentionally creating "complex scripts" is indeed baffling.

The HN title could be something like "ZX - A tool for writing complex scripts". Or "ZX - A tool for writing better complex scripts". Instead it's "ZX - A tool for writing better scripts".

Google is trolling us with the useless use of cat right there in the first actual line of the script.

https://porkmail.org/era/unix/award

> I am embarassed by any complexity. It is the mark of a cluttered mind.

It is the mark of a cluttered world.

Sometimes, there is no simple solution. You have to parse this file, you have to use software to do it, and you can't fix up every little quirk in the file's actual grammar versus the grammar you wish the file had. Tag soup HTML is one example, but there are thousands of others, around the world, doing important things for business and education.

Sometimes you get to parse JSON. Sometimes you have to parse SQL.

Extensions are predefined mapping to the executing program. There is no real concept of compatibility there. Useful for media files where you e.g. pick your image-viewer-of-choice, less useful when the script file already has a very strong opinion as to the expected executing binary. Compatibility can be hinted at, but really only determined on the application level.

If the script runtime binary then looks at the filename and does something differently based on it, it's likely not correct, and if it is done, it'd better be because of some necessity. The "we prefer it this way" is not a necessity. Plus it breaks conventions and expectations.

Enforcing file name extensions at execution, because you want to help an editor figure out how to lint or highlight the file, is also, arguably, letting a specific use case affect something it shouldn't.