Your attitude about not being able to imagine any reason why you'd ever need to use floating point reminds me of the HP technical support person that Steve Strassmann quoted in his email to the Unix-Haters mailing list on Apr 10, 1991:
https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
>My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?”
And no, the kind of stuff you need to fork sed or awk to do is not "complex". It's simple. It only seems complex because you're writing a shell script, and the backflips you have to do to escape the parameters and fork the processes to do that simple string manipulation is complex, not the string manipulation itself.
More seriously I can't imagine what "points" you're trying to score. Yes the shell is good at launching external processes, and yes the built-in facilities for other things are lacking in some ways. On the whole people work around them by using perl, python, and other tools.
It might be, as you say, that people resort to using such external scripts/languages because their shells suck. But I have to ask: So what? They get the job done. A "super-shell" doesn't need to be present, even if people do things the "hard-way".
Why would I waste my time trying to fix something that's fundamentally flawed, and that nobody would use because it wasn't "standard"?
We already have Python, JavaScript, Perl, etc. Even PHP is overwhelmingly better and more modular than bash! Why try to put lipstick on a pig like bash?
My point (which I already stated) is that the "Unix Philosophy" in intellectually bankrupt, not that the shell should be extended with string manipulation and floating point to make it unnecessary to fork "sed", "awk" and "bc".
https://fishshell.com/docs/current/commands.html#math
I have already proposed an extremely practical, totally open, standards compliant, easily predictable, inevitable solution. What is your response to my posts about pushing something like Electron down to the bare metal?
It's not as if there aren't already thousands of extremely talented people across hundreds of different companies and organizations, all working towards towards making that possible and efficient. It's not as if the tooling doesn't already exist and isn't widely supported and rapidly evolving.
There is no need for X-Windows, and no need for Wayland, because a web browser running on bare metal could do everything they do, and so much more, in a vastly more flexible, standards compliant, modular, powerful, efficient way.
And it would be a much better platform for implementing a shell, user agent, desktop, window manager, and even a visual programming environment than the half-assed mish-mash Turing Tarpit of shell scripting languages Unix has suffered with for so many decades, which themselves don't even adhere to the so-called "Unix Philosophy".
AND it would be truly extensible (even capable of gasp multiplying floating point numbers and doing non-trivial string manipulation without forking heavy weight processes), which X-Windows and Wayland are not, which means it can be fundamentally much more efficient, by downloading code to implement application specific protocols and local interaction, like NeWS did decades ago, but X-Windows and Wayland foolishly and stubbornly refused to do by design. (It's not like the ideas behind NeWS were unknown to the designers of X-Windows and Wayland -- they just chose to ignore them. And now here we are.)
You've got JavaScript and WebAssembly for programming, WebGL and <canvas> and <video> and DHTML and CSS for drawing (including low latency rendering with desynchronized canvases), JSON and XML and ArrayBuffer for data representation, HTTP and WebSockets and WebRTC for networking. What is it missing?
https://developers.google.com/web/updates/2019/05/desynchron...
That design has been well proven and is widely used throughout the industry. It's not a new idea, but kids these days refer to it as "AJAX". There's no need for a bunch of useless layers underneath the web browser any more. It's time for X-Windows and Wayland to fade away into the depths of history.
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.
(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?
Google Chrome Developer Tools Crash Course
https://www.youtube.com/watch?v=x4q86IjJFag
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:
https://web.mit.edu/~simsong/www/ugh.pdf
“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
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.
So, what's the problem with that? I read it almost like "that doesn't mean that you never need to retrieve data, it just means you need to switch to SQL". People develop DSLs for a reason.
The rest of your post appears to be about shell (presumably Bourne) script, leaving this claim unsupported. "UNIX philosophy" != "writing shell scripts".
> You shouldn't have to fork a process from the shell to multiply two floating point numbers
I can't remember a single time in the >25 years I've been writing Bourne shell (or bash) scripts where I've wanted to "multiply two floating point numbers". I've sent large lists of floating point numbers to various programs for processing, but other languages are far more appropriate for problems that requires any amount of actual calculation (especially floating point calculations). If I did need to multiply two floats for some reason, it would be such a rare event that the few hundred milliseconds "wasted" in spawning bc is utterly irrelevant.
You seem to be complaining about shell by selecting a feature that is not actually needed in common use. What, specifically, were you doing that you needed fast floating point match but needed to use Bourne shell instead of C/Python/whatever?
> fork a process ... do simple string manipulation.
For many types of string manipulation, you don't. Manipulating strings (command lines) is what the shell was designed to do! Sometimes sed/awk/etc is useful for complex tasks, but the shell's variable expansion and other builtins are generally enough for most simple needs.
And if your needs actually are complex, the cost to start another process (which is probably much smaller than you think) is insignificant.