I saw the Electron mention, but didn’t know what to make of it. What does a “web window system” have to do with unix shell script limitations? I still don’t know.
I find web programming inelegant honestly, with three languages instead of one, a clumsy interpreted programming language that doesn’t multithread. Webasm may help with the last parts, perhaps. What about performance? How to run native code in windows?
At least I’d know how to use it, that’s a big plus. There would need to be some standardization around gui widgets, don’t like how they have to be built from scratch in every project.
Gnome3 uses js and css in its desktop widgets.
Finally Wayland is pretty lean, folks complain it doesn’t do enough already. You’d have to implement a driver and drawing layer anyway, right? So not much is “useless,” perhaps the window manager.
So three languages instead of one is bad for the web, but just fine for bash+awk+sed+expr+bc+grep+egrep+cut+sort+find+etc?
(Plus the other languages you need to switch to and rewrite from scratch once your bash script becomes more than 12 lines long.)
"After a shell script reaches a dozen lines, it's time to port it to Python." -mixmastamyk
Why would anyone in their right mind ever start out with a language that can only handle 11 line scripts?
And are you under the impression that bash is multithreaded? That it has good performance? A just in time compiler? An ahead of time compiler? A module system? A large ecosystem of reusable modules that can plug together and call each other without conflicts? An object oriented programming system? A debugger? An IDE?
Can you compile C++ and other languages into compact BashAssembly code, call it back and forth directly from Bash, and run it really fast across all platforms?
In case you weren't aware, a hell of a lot of people write JavaScript code that runs in node.js, instead of bash scripts, and are very happy with it. And of course Electron can run any code that runs in node.
So yes, running JavaScript in node or Electron is a fine alternative to running bash scripts. It can even handle file names with space in them without shitting itself! What rocket science! And you don't even have to rewrite your scripts in another language once they reach 12 lines -- what a relief!
What I was describing that you didn't understand is implementing a visual programming shell in Electron. And if you prefer a text command line shell with a different syntax than plain JavaScript, then simply implement that syntax and the command line interpreter in JavaScript itself, so you have the complete power of JavaScript and all its libraries to draw from (including extravagant luxuries you're not used to, and couldn't imagine you'll ever need, like floating point math and string manipulation), and you can import and call any JavaScript module. That blows bash out of the water.
You say you're not even aware that there are libraries of user interface widgets for JavaScript, and falsely claim they have to be "built from scratch in every project". But there are many, some of them quite good.
So have you ever even heard of or used the Chrome debugger JavaScript console window, or have any clue what high power integrated convenience and debugging features it supports?
How does that compare to your favorite bash integrated development environment and debugger? Care to tell me which one you use, and link me to a tutorial that shows how much better it is than the Chrome debugger?
Or do you firmly believe that ALL people who write bash scripts NEVER need to debug them, set breakpoints, catch errors, examine stack traces and scopes, single step through code, browse the values of variables and data structures at runtime, just like they never need to use floating point or do non-trivial string manipulation?
I admit that might be the case if you always rewrite your bash scripts in Python once they reach a dozen lines, as you say. But in the real world, most bash scripts are much longer than that, and often suffer from lots of bugs.
You sound like one of those people who complains about hating Lisp because it has too many parenthesis, then goes and writes code in bash or perl with so much punctuation and different kinds of parens and brackets and braces and single letter abbreviations and syntactic syrup of ipecac, that it looks like you lifted the phone out of your 300 baud modem's acoustic coupler and shouted into it.
As I said, you're blind to the problems and limitations of your favorite tools, and hypocritical in your criticisms of better tools.
The preface of the Unix Haters handbook perfectly describes the problem you're suffering from:
“I liken starting one’s computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your
body is covered with lice and flies, you are malnourished and you
suffer from numerous curable diseases. But, as far as young East
Africans can tell, this is simply the natural condition and they live
within it. By the time they find out differently, it is too late. They
already think that the writing of shell scripts is a natural act.”
— Ken Pier, Xerox PARC
My favorite tools are Python and fish, so your insults about the others don't really hurt. I almost never use bash because I don't care for it either. Those other Unix command-line tools are arcane too, but they have a mostly compatible syntax. Don't use many of them besides a grep alternative and an occasional sort perhaps.
There are languages optimized for interactive use, and others for writing batch scripts and programs. Fish is great for interactivity, Python not so much. So they compliment each other quite well. There have been a few attempts to do both (xonsh/iPython), but none have been big hits yet.
Performance is important for long-running and/or computationally expensive apps, which are typically not interactive. When I brought it up, was thinking of Gimp filters, not "ps -ef | grep FOO".
Javascript is probably good enough these days. If you want to create a "jsh" interactive shell with the good parts have at it. Believe it is doable by a single person in a reasonable time. I'd guess a few might already exists and could use contributors.
Re: widgets, meant that few are standardized/built into the browser already and have to be downloaded, not that none exist. A silly situation (as someone who wrote GUI apps in a single language in the 90s), yet could be rectified.
But in thread about GUI Window systems you are going on and on about the limits of bash, which is why your arguments are not well received. It's really neither here nor there regarding Wayland. Shell scripting hasn't held me back since '98 or so, if it ever did. It's like complaining about vi when Sublime Text and VSC exists.
I get that you appreciate good software design, me too. But "worse is better" is the reality we live in. Things get better, eventually.
I find web programming inelegant honestly, with three languages instead of one, a clumsy interpreted programming language that doesn’t multithread. Webasm may help with the last parts, perhaps. What about performance? How to run native code in windows?
At least I’d know how to use it, that’s a big plus. There would need to be some standardization around gui widgets, don’t like how they have to be built from scratch in every project.
Gnome3 uses js and css in its desktop widgets.
Finally Wayland is pretty lean, folks complain it doesn’t do enough already. You’d have to implement a driver and drawing layer anyway, right? So not much is “useless,” perhaps the window manager.