Abbrev: A hidden Ruby gem | Hacker News Reader

Abbrev: A hidden Ruby gem

akshaykhot.com

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.

https://github.com/ruby/ruby/tree/master/lib

I'm not sure what "systems code" means; could you elaborate?

This is a pretty good description.

"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..."

https://en.wikipedia.org/wiki/Systems_programming

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?

Apparently there's a lot of embedded Ruby in Japan

https://engineering.appfolio.com/appfolio-engineering/2017/5...

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.

The proposed usage sounds like a dangerous idea.

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.

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.)

Right, but I guess OP's point was that its not immediately obvious that this is a breaking change - and thus why the proposed usage is dangerous.

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.

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").

npm and gem behave like this, although I don't know if they use this exact method to figure out the abbreviations.

git has something similar, although it's disabled by default (help.autocorrect option).

Thanks.

> npm and gem behave like this

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.

I found the example in the post weird too, I thought it would be for auto complete, when you enter sta -> start

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.

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.

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.

The title of this article is using 'gem' as a coveted object and not a literal Ruby gem being somehow concealed from you. Whoops.

Ha, I thought the same thing.

I thought it was punny.

Sorry, but using Class, implicit global loading in Ruby is worse than useEffect.

a ruby developer discovers substrings

Reply on news.ycombinator.com