The author writes “I've also since learned that the way Japanese developers write Ruby is very different from the Ruby you'll typically see in Rails, or many other popular Ruby gems.”
What would be some examples of “Japanese-style Ruby”? I can find some articles comparing Ruby to Japanese but I’d be interested in full code repositories that would fit this description to go and take a look. I can’t think of good search terms for that.
This is what they're referencing with that comment. I don't know that there's a "Japanese" style of Ruby, as much as there is a style that looks and reads more like systems code.
"The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software which provides services to the user directly (e.g. word processor), whereas systems programming aims to produce software and software platforms which provide services to other software..."
Reasonable, but I'm still not sure what makes code "systems code" or not, by that definition. Is it code that doesn't have a UI/display component mostly, as an observation that lots of Japanese Ruby programmers write code that's distant from the UI layer? Or something else?
I think what the author is interpreting as Japanese style is often just code that was written 10-20+ years ago when conventional ruby just looked a bit different than it does now. Enumerable was less featureful, the use of `and` and `or` was more prevalent. More people wrote in "Seattle style" where they omit parentheses, etc.
Contemporary ruby is less adventuresome and more homogenous in it's style, which I consider a good thing.
uhm... honestly instead of making a tool that supports `sta` instead of `status`, I would much prefer some bash autocomplete that let me write `sta<TAB>` and get `status`
Same. Writing completions for various shells is tedious and sometimes very complicated, so it's always a relief when there's a tool that can generate them from some kind of specification.
Let's assume that in V1 your command has 2 options: start and stop. Thanks to Abbrev, your user take in the habit of calling "$command sta" and "$command sto" respectively. It all works. They start relying on that in scripting.
Then out comes V1.1. This should be a non-breaking release that simply adds the status command. Despite only adding a new command, you break the workflow of your users: "$command sta" does not work anymore because of the ambiguity.
Let's assume that in V1 your command has 2 options: start and stop. Thanks to Abbrev, your user take in the habit of calling "$command sta" and "$command sto" respectively. It all works. They start relying on that in scripting.
This really is a very weak position. More fool them for being so lazy and short-sighted that they can't be bothered to type out the command in a script in full. If I saw that, I would immediately make a change and submit a pull request or whatnot to get it changed for the better, in the cause of keeping the workspace safe, clean, and tidy.
In that case it would be the dev's fault for making a breaking change in a minor release. The correct thing would be to explicitly add 'sta' => 'start' to the Abbrev hash. (Or note in the documentation that the abbreviations are for convenience only, not stable and subject to change.)
Indeed, how could the dev know? Are you assuming the developer is omniscient and knows every abbreviation used worldwide? Realistically, he has not the slightest idea anyone is using 'sta' and so wouldn't know to hardwire an override.
My point was that the dev knows "sta" is currently available as an abbreviation for "start", and when he adds "status" it no longer will be. So if he wants to maintain strict backwards compatibility he should add it back in manually. It's no longer unambiguous, but it does maintain the previous behavior.
Of course I personally would go with option two, where its documented that the abbreviations exist but are subject to change and you shouldn't rely on them.
The dev also "knows" that 'star' is available as an abbreviation. And in a realistic set of options for a real tool like git, there might be combinatorially many possible abbreviations which he now has to "know" and think about every possible intersection or ambiguity.
Yeah, this would be good for tab-completion. It would also work with a time-delay, like git does. It'll print out the guessed command with a second delay, and then if the user doesn't interrupt, execute it.
I mean, okay… but… A lot of command line software already works that way, where you only need to type the minimum number of characters required to disambiguate a command, and as far as I know nobody has died yet as a result.
Abbreviated commands are fine for manual interaction, but a good engineer puts the full commands into source code for discoverability and specificity. If I saw a teammate putting abbreviated commands into source code, I would ask them to change it to the full commands, and I would feel entitled to.
Also, how would we know if no one has died from this? The practice of abbreviating commands literally makes forensics more difficult to accomplish, making it harder to know.
> A lot of command line software already works that way, where you only need to type the minimum number of characters required to disambiguate a command, and as far as I know nobody has died yet as a result.
Do you have an example? None of the command-line tools I use every day work that way. The usual workflow is 1- type a couple characters; 2- press <tab> to complete. The second step is crucial because it ensures you run the right command.
GDB is one software I use a lot that has this feature. You can abbreviate break, print, delete, and others.
For conflicts (does 'd' refer to delete or disable?) the more commonly used command is usually what the abbreviation will expand to (so GDB accepts 'd' for "delete").
No, `npm` has a couple aliases like "i" for "install", but you can’t use "in", "ins", "insta", etc. It has "view" and "version" but "v" is an alias for "view".
`gem` does work like this (#TIL), although it has some hard-coded aliases: while its help page says "Commands may be abbreviated, so long as they are unambiguous", `gem i` works as `gem install` even if there’s a command "info". If you try `gem in`, it does complain that it’s ambiguous.
If you're exposing `command sta` as your official API then you need to test it, so it fails in V1.1 and you fix it before releasing. If it's just a convenience, and you don't promise a stable API, I suppose it doesn't matter as much.
I wondered if this can be used to automatically look for abbreviations of the 10.000 english words except for the most frequent 150 or so. In this way I could construct an english alphabetic shorthand. A while ago someone posted his own shorthand system ‘brev’ in reddit/shorthand, with autohotkey he could autoexpand the abbreviated shorthand and type a bit faster.
What would be some examples of “Japanese-style Ruby”? I can find some articles comparing Ruby to Japanese but I’d be interested in full code repositories that would fit this description to go and take a look. I can’t think of good search terms for that.