4 ms·

It's perfectly reasonable to say "I'll take fewer capabilities in specific areas, if there is far less complexity". Those "missing" capabilities can be hard blo

It's perfectly reasonable to say "I'll take fewer capabilities in specific areas, if there is far less complexity". Those "missing" capabilities can be hard blockers for you, and that's fine as well. I also don't think much of your argument about shell is particularly strong, as it provides plenty of good facilities for dealing with errors (exiting subshell on first error, `trap`, etc.). The only reason I might expect an implementation in another language to be at least more correct in the ways you describe, is because the barrier to entry of those languages is higher, so the programmers may be more professional (in the good way, not in the meaningless way). Given there's just one developer here, we can skip rules of thumb like that and just assess that person and their modestly sized code.

hsn915 4y ago
In many ways, a lot of the complexities in computing are born from the lack of capabilities. C is a simple language. It's so simple it has no concept of modules/packages. So as a hack you can 'include' header files. But this simple hack creates all sorts of complexities. Things would be simpler if the compiler had a concept of modules or packages. Ruby is so simple you don't need a compiler! You just need packages to exist in your system which you can install using the command line. Except now to ship a program you have to ship the entire environment with it, so you create Docker. But things would be simpler if the language had a compiler that can produce a self contained packaging of the program. Supporting only English makes things simple until people from other countires come along and they independently try adding support each for their own language, and you end up with tons of encodings and code pages and all the mess that was there before unicode. Regarding shell, actually the shell language has a quite a high barrier to entry, but only because it's cryptic. That's not my problem though. My problem is even if you add error checking and all that, you don't know if it actually works. There's no compiler that will report errors for you. It's very easy to write incorrect code and get absolutely no feedback about it. There's really nothing to gain from doing this.
- dundarious 4y ago
  That reads like an argument for static type checking languages and against runtime dynamic languages, and I'm generally in the same camp as you, but obviously it's not impossible to use either to write a good program if it's only 1000 lines (they also state they use shellcheck, which is not nothing). There's absolutely something to gain from their approach. And shell is not particularly cryptic, it's just taught awfully -- the main problem being that lazy tutorials just don't mention how quoting/tokenizing works. Using shellcheck almost always pushes you in the right direction.

hsn915 4y ago

In many ways, a lot of the complexities in computing are born from the lack of capabilities. C is a simple language. It's so simple it has no concept of modules/packages. So as a hack you can 'include' header files. But this simple hack creates all sorts of complexities. Things would be simpler if the compiler had a concept of modules or packages. Ruby is so simple you don't need a compiler! You just need packages to exist in your system which you can install using the command line. Except now to ship a program you have to ship the entire environment with it, so you create Docker. But things would be simpler if the language had a compiler that can produce a self contained packaging of the program. Supporting only English makes things simple until people from other countires come along and they independently try adding support each for their own language, and you end up with tons of encodings and code pages and all the mess that was there before unicode. Regarding shell, actually the shell language has a quite a high barrier to entry, but only because it's cryptic. That's not my problem though. My problem is even if you add error checking and all that, you don't know if it actually works. There's no compiler that will report errors for you. It's very easy to write incorrect code and get absolutely no feedback about it. There's really nothing to gain from doing this.

dundarious 4y ago
That reads like an argument for static type checking languages and against runtime dynamic languages, and I'm generally in the same camp as you, but obviously it's not impossible to use either to write a good program if it's only 1000 lines (they also state they use shellcheck, which is not nothing). There's absolutely something to gain from their approach. And shell is not particularly cryptic, it's just taught awfully -- the main problem being that lazy tutorials just don't mention how quoting/tokenizing works. Using shellcheck almost always pushes you in the right direction.