Hacker News Reader

Comment by gfodor | Hacker News Reader

This reminds me of the arguments made against writing “real” code in JavaScript in the early days of the web, until Crockford came along and wrote “The Good Parts.” There is no reason to think that a few idioms and curating features could go a long way to leading to a much better, less hacky paradigm for bash shell scripting.

View on HN

Bash is much older than JavaScript. If it was going to turn into a real programming language, it would have by now. It hasn't.

Also, JavaScript really is not a very good programming language. We are just stuck with it because it's the only language the browser understands. (Well, until recently: things are going to change with the introduction of wasm).

But for the shell, we're not stuck with any one language. Whatever you want to do can be programmed in your favorite language. You can easily write a python script instead of a bash function.

> things are going to change with the introduction of wasm

people have been saying this for years already and nothing seems to have come of it :(

Yeah. Turns out, having an interpreted runtime in the browser is quite useful and sending bytecode across the wire not as practical.

We've been forgetting and relearning that for the past two decades.

"turns out"? How did it turn out so?

Actually it turns out that having an interpreted runtime causes a stream of endless problem. We keep try to patch them over but new problems keep coming up.

It turns out that a standarized low level byte code is the right way to ship cross platform applications. We already knew that. It just took a long time to go through the standarization process and be implemented by browsers.

If it seems like it's not in use today, it's largely because JavaScript has momentum and the majority of web programmers don't yet know how to take advantage of wasm (or maybe don't think they need it).

> It turns out that a standarized low level byte code is the right way to ship cross platform applications

So why hasn’t it taken over the world with Java and now with wasm?

> If it seems like it's not in use today, it's largely because JavaScript has momentum and the majority of web programmers don't yet know how to take advantage of wasm (or maybe don't think they need it).

There’s another possible reason. I’m sure you can come up with the answer yourself.

Javascript never really had a chance to "take over the world" before Google released Chrome and the V8 engine. Before that it was just too slow.

Java applets really sucked. They took a long time to load and initialize. They all looked ugly (probably because of the default libraries?).

Also Java itself as a language was really bad and the development experience was awful. I want to say that no one wants to program in Java but in reality many people do (I don't understand those people).

The important lesson here is the implementation is more important than the idea.

Good idea with bad implementation -> goes no where.

wasm is not java.

The important quality about wasm is that it's not garbage collected. It's pretty close to just good old assembly.

>Javascript never really had a chance to "take over the world" before Google released Chrome and the V8 engine.

Chrome was released at the end of 2008, JavaScript was thriving way before that. We had Gmail since 2004, jQuery since 2006. WebApps were the “sweet solution” considered for iPhone apps at first in 2007. Chrome exists because of the healthy ecosystem that Firefox and Safari provided, not the other way around.

>It's pretty close to just good old assembly.

Precisely, and it's yet to be proven that's the best solution for the Web. I love it from the computer science perpective, but historically that idea hasn't struck a chord.

Is that true though? Aren’t people using it for in-browser image and video editing? Doesn’t Google use it for drawing to Sheets and crunching numbers?

I thought that was the case but I can’t recall where I read it. If that’s not true then I should probably reconsider my thinking about wasm

Yes, WASM is a good target for CPU bound number crunching. I'm not sure if it's used in Sheets, though.

I've seen some pretty interesting things like the use of Rust for front end development, like yew[1] and Seed[2].

There aren't many languages that are practical for WASM output. Scripting and managed languages need to ship their interpreters and runtimes with their WASM blobs, and can end up relatively large. JavaScript's interpreter and runtime are baked into every browser already.

That leaves only compiled and unmanaged languages for potentially good WASM targets. As mentioned before, Rust is seeing a lot development in that space. If LLVM can compile it, then Emscripten can output it to WASM.

[1] https://github.com/yewstack/yew

[2] https://github.com/seed-rs/seed

Are you sure nothing came of it?

Figma for example seems to be largely powered by WASM and the core of the product seems to be written in C++

https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

https://www.figma.com/blog/building-a-professional-design-to...

I think the majority of web developers are just slow at catching up with this new things.

WASM DOM manipulation will probably come soon, and that will place other languages in the exact same playing field as Javascript. For now, manipulating the DOM still requires calling Javascript.

Wasm isn't really going to change the front-end / browser side of javascript for the better, but it's great for graphics and anything else cpu intensive.

What’s wrong with modern JavaScript as a programming language (although I would maybe point to typescript which adds types to JS instead)?

There's no distinct "modern JavaScript", it's still the same language. It just has bunch of things added to make it more manageable, but it still contains all the footguns and gotchas as it did before.

Its tooling got significantly better in the last decade or so, but you still need to intentionally rely on it in order to work with the language in any sensible way. You can't really hope for any other outcome when maintaining backwards compatibility.

The tooling only got better last year with esbuild.

Everything else is either unmanageably complicated (webpack) or slow (rollup, parcel, babel).

React mainstreamed the idea of using a virtualdom to accelerate UI building (accelerate in the computational sense: by not dealing directly with the slow DOM).

I remember how webdev looked like 15 years ago. The tooling did get better even before esbuild - but I never said it was "good" :)

I responded to the sibling comment asking the same question

https://news.ycombinator.com/item?id=29068066

  > JavaScript really is not a very good programming language.

Since 2015, JavaScript really is a nice language. I never thought that I'd say that.

Go look at ES6 (the javascript version that came out in 2015) and even TypeScript. You'll be pleasantly surprised, no matter if you're coming from C++, Java, C# or even other "scripting" languages such as PHP and Python.

I use typescript almost daily. It's certainly better than Python or Ruby, I'll grant you that. But I don't think Python is a good language either.

Ultimately I want a langauge with value types like structs and arrays that you can use to do computations without allocating things on the heap.

In Go I can write a function that returns two numbers.

In Javascript I can only return two numbers by allocating an array on the heap with two items. These two items themselves are probably pointers to two number objects allocated separately. So that's 5 allocations to return two numbers. It's insane.

This means fundamentally it's impossible to create applications in javascript that are both sophisticated and high performance.

A great example to illustrate this is the tooling around Javascript itself.

There were all kinds of bundlers: webpack, rollup, parcel, etc. Rollup was considered the fastest and lightest. They were all programmed in Javascript itself. They were all slow. But no one really knew how bad it was because there was nothing really better.

Then esbuild comes along, and blows all of them completely out of the water, out performing them by 100 times. And it's written in Go. A language that supports structs and arrays as value types.

It’s not fundamentally impossible to build fast apps in JS. It’s just not possible to do if you don’t do the legwork of writing code that the compiler will optimize for you. It’s not easy, and it’s not natural in a lot of cases, but saying it is fundamentally impossible goes too far: people build high performance applications like games in JS.

For example, you are worried about value types but under the hood the JIT compiler will actually generate efficient representations that are passed by value if you do not mess things up for it. Modern JS compilers are extremely sophisticated.

For returning values without an allocation, you’d create such a “struct” and then use a memory pool. It would still be heap allocated I believe but not totally sure. People who know more than I do could probably tell you a better method to return multiple values from a function efficiently.

> people build high performance applications like games in JS

Yes, and in my experience this kind of applications (and the browser in general) are one of the only things these days that still push me to upgrade my hardware to have better CPUs and more RAM, as it's perfectly sufficient as is for pretty much everything else I do.

You can’t tell from the outside if you are running a well engineered JS app that would have been fast in another platform, or a non-optimized JS app. My point was that it’s not fundamentally impossible to write fast enough JS code for a game, even though you may come across many slow JS apps regularly. (Not surprising, given the wide distribution and low barrier to entry of the web.)

Yes, you can operate strictly on typed arrays and essentially implement something alike a virtual machine inside your JS code to make it handle memory efficiently, so you're right - it's not "fundamentally impossible", but are you still really writing JavaScript at that point? :P

> There is no reason to think that a few idioms and curating features could go a long way to leading to a much better, less hacky paradigm for bash shell scripting.

A couple of years ago, I challenged myself to write some complex scripts and apps using only Bash, and came to this conclusion myself.

You can get pretty far with just Bash alone, especially if you strive to write readable and maintainable code, and not just one off scripts. If you need access to data structures, especially nested ones, you can shell out to another language and then print the results back to stdout so Bash can use them:

    $ get_data | transform_data | python3 ./complex_script.py | consume_results

But once you shell out and require another language, why not just use that other one from the start?

Because the shell is used to do things that are easy in the shell. Examples: file manipulation, sorting, field based processing, pipes. Doing these things in a traditional language is more complex and not necessarily better.

It’s not more complex in Python if you use the sh package. All the power of everything you need with a real language when you need to do more.

Packaging in Python is a bit more of a pain.

That's the other part of the problem. The shell is available everywhere. Python needs to be installed. So, if you need shell-related functionality, it is the easiest route to use.

I have not encountered a system yet where Python isn’t installed out of the box.

Windows, possibly. And as for the *nixes, including Macs, what version is installed? The way Python 2 eol was extended and extended and extended just hurt the whole ecosystem.

Windows doesn't have bash preinstalled so I'm not sure why you're bringing that up. On all OSes I've used in the past 3-4 years all of them have been Python3 by default. The specific version is largely irrelevant as I could ask you the same question about which version of bash is running on a given OS (e.g. it's not available on Mac out of the box as the default shell is zsh due to GPLv3).

  > Windows doesn't have bash preinstalled

I meant Python preinstalled.

  > On all OSes I've used in the past 3-4 years all of them have been Python3 by default.

Windows comes with Python preinstalled now?

Except the shell is bad for those things, except pipes I guess.

I just hate doing things with files in the shell, all those stupid escaping rules, and god forbid you have files with spaces or quotes in the names, or leading or trailing spaces.

It's just spending time learning hacks to get around shell limitations instead of actually getting things done, and at the end it's an ugly mess.

Or maybe I'm just bad at it, but I don't think it's only that.

I did a similar thing a couple of months ago, writing a static site generator for my blog in sh. You can write bigger programs as long as you keep discipline, albeit it is a pain.

Here is the rust library with the “the only good parts” of bash/shell script: https://github.com/rust-shell-script/rust_cmd_lib

"no reason to think ... could"

should read

"no reason to think ... couldn't"

Reply on news.ycombinator.com