Suggestion: Name the OS-interacting functions semantically, instead of after the POSIX syscall names

[twome]

I'm sure this breaks a lot of people's well-worn habits so apologies in advance - my intentions are pure! Don't hurt me!

The suggestion: Deno & other interpreters should stop using the C syscall names verbatim for the interpreter's exposed API function names (see: Deno.lstat).

We should absolutely still clearly document the underlying system calls being made in each Deno API function, to:

• demystify what the interpreter's doing, and so
• C/Unix veterans can quickly search up the right Deno function corresponding to the functionality they're used to,

but the original names are bad, bad, bad names. They were chosen in an era with totally different considerations, where programs stored as text took up significant space, and weren't being compressed. Text editors didn't autocomplete, let alone suggest function names. The entire POSIX and C landscape is named this way and I'm sure most of us are even fond of the idiosyncratic names, but we need to acknowledge that almost all the names are awful. Even when they're a single valid word they're often not descriptive or intuitive (fork/tee), some are arbitrarily truncated (exec), they have no word delimiters so you sometimes need to guess the intended words (flock), some of them are like weird half-acronyms (chown), and in the context of JS / Deno, they appear to the uninitiated as totally arbitrary exceptions to naming/style conventions (which is bad no matter what you think of the inherent quality of the POSIX names).

Another advantage of abstracting away from the POSIX names is that it makes development more cross-platform in a human/social sense - if a dev's targeting Windows they don't even need to know the Linux or Mac internal names for things to use Deno fully.

To get the ball rolling: stat / lstat / fstat could be rolled into one function and exposed as something like:

fileInfo(file: string, followSymlinks: boolean = true)

This way, you have fileInfo() returning a FileInfo object - pretty straightfoward. We could even go implicit and name it status(), attributes() or properties(), given almost every FS path points to some kind of "file". I think the majority of people would immediately understand "status/attributes/properties" refers to the file the given path refers to, rather than the path string itself.

[ghost]

Fully agreed. When I originally saw Deno introducing them, it seemed foreign, compared to everything else built up thus far.

[zachauten]

C/Unix veterans can quickly search up the right Deno function corresponding to the functionality they're used to

Couldn't you just as easily say people unfamiliar with the Unix terminology can look up the appropriate function calls for what they want? The Unix abstractions have been around for decades, and a lot of people are familiar with them. Often it makes sense to reuse abstractions instead of reinventing the wheel, because they'll pop up in other places too.

Some of the Unix calls do have pretty wacky names if you haven't used them before, but I think Deno does a pretty good job of documenting the api, and node.js (which is what all server side javascript devs have been using for years) uses a very similar api.

[twome]

Couldn't you just as easily say people unfamiliar with the Unix terminology can look up the appropriate function calls for what they want?

No, you couldn't say that, because the Unix pros already know the functionality they want, and just need to search for a single, likely unique, term (or simply infer that e.g. fileInfo probably uses a stat variant under the hood). People who don't know what the libraries are capable of instead need to browse the APIs by name. The entire point of intuitive or semantic names is that you can figure out what different API calls do very quickly, without having to read as much redundant documentation. You can explore in a REPL or with an autocomplete IDE much faster. If all you need is a unique hash table key, you may as well name everything with randomised ASCII characters, or do away with string names entirely and refer to every API function with a number.

The Unix abstractions have been around for decades, and a lot of people are familiar with them.

These are not abstractions we're discussing; these are better names for the exact same abstractions. Different concept entirely.

and a lot of people are familiar with them.

A lot more people are familiar with their own native natural language, which is all you need to understand well-chosen names. Not only is that set of people much larger, but it's also a superset of the Unix-experienced set and the JS-fluent set. So, aim for the bigger set.

Some of the Unix calls do have pretty wacky names if you haven't used them before

The names remain "wacky" (bad) for everyone else no matter how many times you, personally, use them. Deno doesn't document the rationale behind the break from naming conventions, as far as I've read, and that rationale would add to the aformentioned "redundant documentation" instead of just using a descriptive name.

node.js (which is what all server side javascript devs have been using for years)

Deno already introduces massive breaking changes to Node users, and all of them are for the better. That's the entire point of Deno - a better / simpler / more consistent core design means it's faster to learn for everyone (meaning Node vets and everyone else, which vastly outnumbers Node vets), requires less repetition & boilerplate, is more practically useful for end-users, and has tonnes of other extremely worthwhile tangible benefits. You don't break APIs and habits for no reason; you break them to improve the state of the art.

I'm sorry for being rude, but I'd really rather you'd have thought about this rationally, instead of raising points I'd already covered in the OP and wasting everyone's time with a kneejerk response.

[ghost]

The existing APIs cannot be removed, due to backwards compatibility. At best, they can be aliased with better, self-documenting names.

[twome]

The existing APIs cannot be removed, due to backwards compatibility

They can; that's what major versions are for. You deprecate the old names and add the new names (which alias to the old) in a minor version, then when the time comes for the next major version, you fully replace the old names. Obviously this change alone would not be worth breaking compatibility for, which is why you bundle as many breaking changes as possible into a major version. You deprecate now, to give as much time as possible for people to switch existing projects to the future-proof API.

[AnInternetTroll]

https://xkcd.com/927/

[twome]

This is not developing a new standard; your contribution is idiotic

[ghost]

...your contribution is idiotic

😕 please, may you be kinder here?

[vicary]

also, maybe read their username before taking it seriously?