[HN Gopher] Abbrev: A hidden Ruby gem
___________________________________________________________________
Abbrev: A hidden Ruby gem
Author : software_writer
Score : 75 points
Date : 2023-08-17 14:41 UTC (1 days ago)
(HTM) web link (www.akshaykhot.com)
(TXT) w3m dump (www.akshaykhot.com)
| fsiefken wrote:
| 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.
| digitalsushi wrote:
| The title of this article is using 'gem' as a coveted object and
| not a literal Ruby gem being somehow concealed from you. Whoops.
| ezekg wrote:
| I thought it was punny.
| sodapopcan wrote:
| Ha, I thought the same thing.
| IMTDb wrote:
| 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.
| thedanbob wrote:
| 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.)
| tlonny wrote:
| 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.
| gwern wrote:
| 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.
| thedanbob wrote:
| 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.
| zoky wrote:
| 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.
| hk__2 wrote:
| > 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.
| vulcan01 wrote:
| 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").
| MatmaRex wrote:
| 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).
| digitalsushi wrote:
| 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.
| hernantz wrote:
| I found the example in the post weird too, I thought it would
| be for auto complete, when you enter sta -> start
| gwern wrote:
| 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.
| gjvc wrote:
| _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.
| revskill wrote:
| Sorry, but using Class, implicit global loading in Ruby is worse
| than useEffect.
| schube wrote:
| 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.
| kubectl_h wrote:
| 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.
| wgj wrote:
| 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
| zbentley wrote:
| I'm not sure what "systems code" means; could you elaborate?
| wgj wrote:
| 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
| sethrin wrote:
| Apparently there's a lot of embedded Ruby in Japan
|
| https://engineering.appfolio.com/appfolio-engineering/2017/5...
| [deleted]
| _ZeD_ wrote:
| 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`
| nerdponx wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-18 23:01 UTC)