Live data from Hacker News

ZX – A tool for writing better scripts

github.com

121–130 of 143 posts

Re: ZX – A tool for writing better scripts

#121
post #96
post #92

Earlier quoted context omitted.

What’s with all the await-stuff? Couldn’t it be written just straight forward?

That allows other code to run while e.g. files are being moved. It indeed can be somewhat painful ([1] is the classic criticism) and in shell scripts is not as beneficial. I think there are even sync alternatives (i.e. equivalent functions that don't need `await`) for most of them, but again: these are the APIs I'm already familiar with, which is the entire point - and thus the await-stuff comes naturally for me, bec…

Yes and a shell script would do it with one &, while this goop is a mountain of async, nesting, futures management, and boilerplate. No thanks.

Re: ZX – A tool for writing better scripts

#122

Earlier quoted context omitted.

> example is a cat|grep... How can I assume the author is an experienced script writer? Perhaps because they are writing documentation that can be understood be less experienced script writers as well as themselves, using a very common example seen everywhere? I find "cat full | ..." keeps the left-to-right flow of a command nicely, and is better understood by those less familiar with shell work than prepending " Yes…

> I find "cat full | ..." keeps the left-to-right flow of a command nicely Sorry, I don't buy it. You don't read files like this: cat file | less And you don't compile C programs like this: cat hello.c | gcc -xc - Actually using less, grep (and even gcc) as filters is more confusing to "those less familiar with shell work".

For a single command acting on a file, especially with no other parameters, like your less example, you are right and I wouldn't, though I have seen it often. There is practically no "left-to-right" flow to break. Longer examples is where I would use it.

Also not in circumstances where explicitly acting on a file like your GCC example. It is unlikely that GCC will commonly be used as part of a more collect pipeline of commands.

Note that I said "I use it", not "I always use it, without fail, no other option makes sense ever". Different tools, different jobs (this is what the Church of Latter Day Demogifiers usual don't accept in this context).

Re: ZX – A tool for writing better scripts

#123
post #119

Earlier quoted context omitted.

If you need a programming language for you job, but you're not primarily a developer, and two languages would probably be overkill, then your one language is probably python. That's a lot of people.

That’s exactly how I chose Python.

I'm curious, what was the job that needed some code but not a dedicated developer?

I'm taking computational biology courses on the side, so that's the application that comes to mind for me.

Re: ZX – A tool for writing better scripts

#124

Earlier quoted context omitted.

yea same here. I wrote nodejs programs for years. the focus on the eventloop and everything being asynchronous is great for servers and network IO but does NOT make it the perfect choice for scripts. Its a different use case entirely. scripts are supposed to be small simple programs that run in sequence and terminate. I shouldn't need to deal with concurrency primitives at all in that particular situation.

With modern JavaScript (as in last 5-7 years) it's pretty straightforward to write sequential scripts.

There's more to it than writing a simple sequential python, ruby or perl script. You have to write everything using async/await.

Re: ZX – A tool for writing better scripts

#125
post #99

"[For writing complex scripts] JavaScript is a perfect choice". Not sold on that. Why should I choose it over Python, PHP or others?

Modern js is not what it was. Ergonomics of nodejs v20 are not in the same ballpark as node v6. A lot has happened since v12 even. Js definitely has become a pleasant language to script in. And it's sooooo much faster that python and Ruby.

Still the same footguns for the sake of backwards compatibility. Things like:

  typeof '' == 'string'
  false
And many others that I'm are too depressing to mention. This is the latest one that I got surprised with.

Yes, it's fast but so is Lua, Dart or even Racket.

Re: ZX – A tool for writing better scripts

#126
post #125
post #99

Earlier quoted context omitted.

Modern js is not what it was. Ergonomics of nodejs v20 are not in the same ballpark as node v6. A lot has happened since v12 even. Js definitely has become a pleasant language to script in. And it's sooooo much faster that python and Ruby.

Still the same footguns for the sake of backwards compatibility. Things like: typeof '' == 'string' false And many others that I'm are too depressing to mention. This is the latest one that I got surprised with. Yes, it's fast but so is Lua, Dart or even Racket.

Can I qoute my comment verbatim back at you?

Seriously. Just don't use ==. Use ===. Et voila you're using a modern pleasant scripting language.

Modern guides on js won't ever mention ==. As a noob today you won't ever learn it. In a big project there will be a linter to stop you

Re: ZX – A tool for writing better scripts

#127

Earlier quoted context omitted.

Likewise! I use TypeScript everywhere possible, and zx is a godsend. Unfortunately, I've recently dealt with gobs of Python for ML software. After years of writing TypeScript, it's been a...sobering reminder of many painful coding issues that I'd forgotten even existed. Made me deeply appreciate what TS gives us haha.

I worked at a Python shop for a bit. I spent more time than I wish to admit trying to make all of my Python behave like TypeScript (adding typings, etc.).

Ditto. Python(3.13) types are so crudimentary that it becomes a Sisyphian struggle. Library type support is patchy at best. **kwargs is an abomination. Python is incredibly slow. Async code and anonymous functions are awkward and verbose. Hell, Python is verbose.[1] I could complain endlessly, but I'm mainly just disappointed in how little has changed since I last professionally wrote Python. The biggest benefits were basically a) familiarity, and b) powerful stats/ML libs.

I hadn't seen analogs of `AttributeError`s and `TypeError`s for years, until revisiting Python and remembering that those are still unsolved issues outside of TypeScript. Ugh.

[1] https://news.ycombinator.com/item?id=36407112

Re: ZX – A tool for writing better scripts

#129
post #125
post #99

Earlier quoted context omitted.

Modern js is not what it was. Ergonomics of nodejs v20 are not in the same ballpark as node v6. A lot has happened since v12 even. Js definitely has become a pleasant language to script in. And it's sooooo much faster that python and Ruby.

Still the same footguns for the sake of backwards compatibility. Things like: typeof '' == 'string' false And many others that I'm are too depressing to mention. This is the latest one that I got surprised with. Yes, it's fast but so is Lua, Dart or even Racket.

wha?

    Welcome to Node.js v19.9.0.
    Type ".help" for more information.
    > typeof '' == 'string'
    true
???

Re: ZX – A tool for writing better scripts

#130
post #124

Earlier quoted context omitted.

With modern JavaScript (as in last 5-7 years) it's pretty straightforward to write sequential scripts.

There's more to it than writing a simple sequential python, ruby or perl script. You have to write everything using async/await.

async/await are dead simple. And many Node libs have synchronous versions. It's pretty straightforward if you are familiar with the language. If you aren't, well that isn't really the fault of JS nor any different from bash or python, which can both be just as painful for those unfamiliar.
Post reply on HN