Disqus - Latest Comments for zverok

Re: That useless Ruby syntax sugar that emerged in new versions

zverok — Sat, 21 Jun 2025 05:51:29 -0000

It is not "new" by any measure.

IIRC, this was always in Ruby, like since the language beginning. This is kind of bow to Perl, which has qw[Rome Milan Venice] syntax (which has different semantics though: [Rome Milan Venice] is a string literal here, and qw is split operator; but it is a very widespread for defining word arrays).

I was always fond of it, like one of those "humane" language irregularities that make many small code fragments look lighter, even if you can't objectively explain why do you need that.

"The Hague" case can be solved by \ BTW, though it is a confusing style (but if it is just one instance in a big bunch of homogenous data, might be acceptable): %w[Amsterdam Rotterdam The\ Hague Utrecht].

But one way or another, the "irregularity" in this case nicely underlines irregularity of the data ("most cities are one-word, but notice, there is this special case"), so I prefer to think about it this way.

Re: That useless Ruby syntax sugar that emerged in new versions

zverok — Sat, 07 Jun 2025 07:10:01 -0000

Well, the change is simply old enough so I didn't see a point in trying to explain "how I look at it, and what thinking have caused it". Everybody have made their minds a long time ago about that.

As for my opinion on it: I recognize the change was disruptive, but it opened a further road for many modern features (like "true" keyword arguments and pattern matching). I understand the "theoretical" reasons for disliking it, but never had emotional connection with those reasons.

And "literally impossible to explain" seems a bit of exaggeration to me. It is, like, two phrases?.. "Generic shape of Ruby's Hash literal is key => value. For symbol keys, which are extremely widespread, there is a syntax sugar: foo: bar is the same as :foo => bar." That's it.

I believe the linked post overcomplicates it by not starting with the "right" mental model (showcasing 'A': as the main syntax for symbol keys, and then drawing conclusions that it "converts" a string 'A' to a Symbol).

Re: Seven things I know after 25 years of development

zverok — Fri, 31 Jan 2025 01:08:52 -0000

For me, it is not as much about features as about preferred style. At some point in history, RSpec seems to have implied the style from my second example: implicit subject (defining subject once and then use it { is_expected.to ...), one example per test, using rich matchers to better explain what is tested. BetterSpec.org (which promoted this style) was universally recommended resource.

Then, something changed: "tired" from "magic", the community started to require "not smart code", and approach to tests was especially affected. BetterSpec was proclaimed "not endorsed approach", its(:attr) syntax got evicted from RSpec core (though is still maintained as plugin and even evolves), and IIRC, rspec-rubocop's default settings currently prohibit implicit subjects.

My second example doesn't have as much "new custom helpers" as it may seem: create_record and respond_with are matchers (which RSpec recommends to define for richer tests), subject is standard RSpec syntax, using it implicitly is standard RSpec feature; only its_block { is_expected is custom thing, but it follows the old spirit of rspec ( it { is_expected syntax is still there)—and, I'd say, if RSpec would evolved in the direction it once was, this would long ago became part of the core.

As for "to much magic, hard to debug" statement—what can I say. My experience begs to differ (I used this approach to specs in many large production codebases through years, taught big teams to do it, and I have my anecdata about efficiency/problems, which not quite matches the common knee-jerk response).

Re: How it became like this? Ruby Range class

zverok — Sat, 21 Sep 2024 12:52:08 -0000

Oh, thank you for noticing!
It is definitely a (small yet nasty) bug after implementing new step behavior and then supporting “legacy” behavior for strings/symbols.

I’ll fix it soon.

Re: Language, perception, and empathy: Ukrainian's gaze (Notes to the talk rejected by RubyConf)

zverok — Thu, 23 Nov 2023 12:26:07 -0000

I am honestly sorry for how that dialog went (I geniunely missed the mention in that email, got desperate, wrote to Twitter, got corrected, had immediately apologized: https://twitter.com/zverok/.... A few weeks after that I suddenly understood I am not subscribed to RubyWeekly anymore, tried to resubscribe and found out my email is banned.

If you still believe I acted in "bad faith" (what should it mean in the context?.. That I wanted to harm you personally, and deliberately misrepresented things?..), I am very sad about it, and I can assure you that I was not. I have only respect for you and everything you do for the community.

That also taught me a valuable lesson to not jump to conclusions and after that, I believe, I never demanded anything personally from you or anybody else.

If you think the phrase you are quoting from the blog post is harmful for you (I tried to make the paragraph neutral and somewhat self-indicting, but I might've failed), I can rephrase or remove it.

Re: "Useless syntax sugar": Numbered block parameters

zverok — Thu, 12 Oct 2023 15:41:20 -0000

Well, `_` is tempting, but its use is widespread as an "unused parameter" (and even have language support, you can repeat it as a parameter name several times), so incredible amount of code would've been broken.
Introducing new syntax into a mature language provides pretty narrow design space, unfortunately.
Basically, limiting oneself to only use `_1` (maybe even enforcing with a linter) and perceiving it as a sigil to not think much about is the closest thing.

Re: A few words on Ruby's type annotations state

zverok — Mon, 22 May 2023 06:17:31 -0000

I actually did explore Crystal of course, since its early days. It would be appropriate to mention it in the post, but the process of writing was kinda chaotic, and the post already grew big, so... I just skipped.

But I am not as much interested in a "language like Ruby, but with type declarations" as in "what's the design space and consequences of trying to add types to Ruby." Crystal indeed started as an experiment in this domain, but grew far enough (both as a direct result of adding types, and of lang's authors other design decision) that it is only tangentially related.

But once I'll have time I probably should update the post or write a follow up with a few thoughts I've omitted, including this one, which makes it look I am kinda oblivious.

Re: A few words on Ruby's type annotations state

zverok — Sun, 07 May 2023 02:37:12 -0000

I am actually a part of Ruby core team :) Responsible for a few changes in the language, for better or worse: https://zverok.space/ruby.html

But I feel the idea feels half-brewed at the moment, so I am just dropping it for a public evaluation and discussion 🤷‍♂️

Re: It is not what you expect, but it is what you want: how Data#initialize is designed

zverok — Sun, 12 Feb 2023 07:59:57 -0000

Thanks, fixed! (A bit late indeed :)

Re: Small nice feature that emerged in Ruby 3.1... But has a nasty quirk

zverok — Mon, 13 Dec 2021 04:21:52 -0000

As a block, unfortunately. Only p(a:, b:) will produce a desired effect.

Re: I forgot how to spellcheck

zverok — Wed, 12 May 2021 16:05:51 -0000

Sorry for a late response (Disqus somehow decided they don't need to notify article's author about comments... so I find them just by chance), and thanks for your thoughtful comment!

To address some good points you raised:

Wikidata's lexicographical data (which I would recommend instead of Wiktionary mentioned by you)

Yes, it might be the way (I am following Wikimedia's efforts for open data, but there are so many of them it is not always easy to guess which is the most reliable and maintained), thanks for pointing it out.

the LibreOffice package has an extension .oxt, not .odt which is a normal text document

Oh, thanks, fixed!

On the other hand, I would oppose a bit that this cannot be included into Hunspell. From my – maybe too naive – point of view it would be enough to work with frequencies (if provided) and output probability instead of yes/no; and provide an interface to choose a style needed by user and reflect it in the check (maybe frequencies for different styles could be contained in dictionaries).

Well, it might work, but there are a few questions to ask. I allow that we can imagine adding some "frequency tag" to the dictionary format, and injecting one more loop in Hunspell's algorithm that checks frequency when present and reorders suggestions/provides correctness probability. (Even this task scares me a lot after all the time spent in the depths of the codebase.)

But then again: where are the data? One-list-per-language word frequency lists exist for some languages okay, but once we'll try to factor in all the style changes (I don't believe in short and non-intersecting "list of styles"), all the author differences (I am mentioning that depending on the author's own traits some errors might be more frequent, and some corrections more desirable), and language change with time, how many dictionaries we'll need to have?
Who will prepare them all? Would it be manual, or authomated somehow (which is dangerously close to "machine learning" already: machine takes the input corpora and "learns" word probabilities...)

Another funny thing to note here is however hard we try, Hunspell will never be able to distinguish "you're" from "your" and "that" from "cat"—because it lacks context of surrouding words; and fixing that would require... well, making it into something else.

Also, aren't the current possibilities of text editors to ignore misspellings or to add words to custom dictionary just a primitive variant of how the user teaches the spellchecker to correspond with his vocabulary/language style? Couldn't be this a way?

It definitely could! Once we will have some way to gather these individual corrections (so millions of man-hours wouldn't be wasted by constantly teaching spellcheckers to remember next president's name), to make it more natural for users (so they don't need to click "add to the dictionary" 100 times per day, just correct the word or leave it be if it is considered correct), and the mechanism would understand that user that added "lol" to their dictionary on reddit doesn't want it to be considered correct in their scientific article... But then again, it will be more or less the thing I am writing about in the final words :)

Re: I forgot how to spellcheck

zverok — Wed, 12 May 2021 15:41:28 -0000

Thanks!

Re: Rebuilding the spellchecker: Hunspell and the order of edits

zverok — Mon, 01 Mar 2021 14:48:33 -0000

(Now it notified me, too... Just some 9 hours after your comment :))))

> I intentionally didn't reproduce weird Hunspell's peculiarities (especially confirmed to be bugs by Laszlo Nemeth himself), so, to some extent, you can fix Hunspell.

Oh, you are digging much deeper than me, then :) I wonder which ones were confirmed as bugs, and are you in contact with Laszlo about it, or just gathered his opinion from open sources?

> I'm also considering to make suggestion algorithm more tweakable, and maybe even optionally plug in another, faster one.

That was my original intention, too, but now I am kinda disullisioned... So my plans now are as humble as just finish the article series.

> The only problem is, I've no idea yet, which one :)

I had two thoughts about it, not sure whethere they are valuable. (Anyways, they are rather about quality than speed.)

One is, currently Hunspell really lacks pronunciation similarity suggestions: I touched it a bit in the next chapter: https://zverok.github.io/bl.... It is _theoretically implemented_, but not much dictionaries do it (they should define algorithmic PHONE table in aff-file). At the same time, there are already a lot of sound-alike encoding algorithms, including international ones (like, in this Python library: https://abydos.readthedocs.... — I assume there are a lot for Java, too).

Another thought is that—I'm going to it in articles, too—that with some source for word popularity stats the subjective suggestion quality would probably jump up significantly. In Hunspell's conception times obtaining and maintaining such lists would've been impractical, but now...

Re: Rebuilding the spellchecker: Hunspell and the order of edits

zverok — Sat, 27 Feb 2021 11:22:08 -0000

(Damn Disqus haven't notified me of your comment... I am not even sure it will notify you about my answer! But still...)

> I've been reimplementing Hunspell in Java for the last 1.5 months

Oh, cool! Glad to hear I am not alone on this dark and weird path :)))

> For more "completeness", I recommend checking some large text files in whatever languages you can find and verifying that Hunspell and your implementation produce the same results. That's when I found out that Hunspell's tests aren't covering everything.

Yeah... Preparing demonstration example for every chapter, I often find the thing that I overlooked, or edge case which suddenly works weird... Actually, it is easy to notice my Changelog follows the schedule of the posts :)

> For spellchecking, that mostly works, but for suggestions, replicating Hunspell's results exactly proved to be much more difficult and not always worth it.

Oh, one of the harsh truthes of this year-long excersise for me turned out to be you can't "fix" (or "evolve") Hunspell... Every time I tried to "cut the corner, because this edge behavior is weird", it turned out later there actually was some useful behavior that was cut out. It mostly like (and I'll discuss it later in the series) some ML model grown through years, you can't just drop some of the quotients, even if it isn't obvious how it adds up—you need to retrain the whole model from the ground up.

So, it is a sad excercise, actually... But I still don't know what's the alternative.

Re: Weird Ruby: Invoking Lambdas

zverok — Wed, 18 Dec 2019 05:48:55 -0000

The last one (===) is more justified than [] or yield because it is not just "you can write this", but can be used in case:

case foo when 1..20 when /\d+/ when String when -(x) { x.respond_to?(:to_s) }

One may think whatever they want about this way of structuring (I personally find it extremely useful), but at least it explains "why Proc should have ===".

Re: Fun with each_with_object and other Enumerator adventures

zverok — Mon, 21 Oct 2019 14:16:49 -0000

What's confusing? If what confuses you is File.:write, it is Ruby 2.7's method reference. Ruby 2.6 equivalent would be each_tuple(&File.method(:write))

Re: Fun with each_with_object and other Enumerator adventures

zverok — Fri, 18 Oct 2019 06:48:19 -0000

It is not a bug. each_with_object/each_with_index/reduce produce enumerators which yield two parameters into a block. All the rest of standard enumerators yield one (even if this one is an array). But one could make custom enumerator yielding any number of arguments.

It is indeed subtle behavior related to Ruby's "non-lambda" procs, but it is absolutely consistent.

Re: yield_stelf is more awesome than you could think

zverok — Wed, 26 Dec 2018 06:12:28 -0000

Well, if you look at who proposed the new name... https://bugs.ruby-lang.org/... ;)

Re: The Missing Ruby Reference

zverok — Sat, 08 Dec 2018 15:53:19 -0000

Thanks! I'll definitely take a look.

Re: yield_stelf is more awesome than you could think

zverok — Sat, 02 Jun 2018 08:14:10 -0000

This is array unpacking, not sure if it specified somewhere in particular, but it always worked (like natural part of the language, same as a, b = [1,2,3]). It is particularly convenient in blocks:

{a: 1, b: 2}.each_with_index { |kv, i| k, v = kv ... → separate unpacking statement, ugly
{a: 1, b: 2}.each_with_index { |(k, v), i| → it is unpacked in block declaration.

So, being able to say "unpack parameters on method passing" is a logical consequence. I tend not to use it (unlike unpacking in blocks) in code because people get confused, but... well, it is neat nevertheless. You can do this, for example:

def fetcher(len, (first, *));
"#{len} char words example: #{first})"
end

%w[test me please Ruby is cool].group_by(&:length).map(&method(:fetcher))
# => ["4 char words example: test)", "2 char words example: me)", "6 char words example: please)"]

Re: The Missing Ruby Reference

zverok — Sat, 07 Apr 2018 17:15:28 -0000

Thanks for the feedback!
As the project's source is on GitHub (https://github.com/rubyrefe..., I believe that GitHub issues/PRs is the most flexible and convenient communication channel for opensource project.

Re: More yield_self awesomeness. Also, the new name proposed.

zverok — Sat, 07 Apr 2018 04:23:55 -0000

Suit yourself. ¯\_(ツ)_/¯

Re: More yield_self awesomeness. Also, the new name proposed.

zverok — Fri, 06 Apr 2018 03:10:29 -0000

Well, Rust doesn't hesitate to use .then either ;) https://doc.rust-lang.org/s...

Re: More yield_self awesomeness. Also, the new name proposed.

zverok — Fri, 30 Mar 2018 04:48:48 -0000

There is a huge Reddit discussion of whether .then is appropriate metaphor: https://www.reddit.com/r/ru...
That has some good points, in fact, but I decided to step back now from "deciding" further, the important thing was to raise the naming problem, and now it is up to Ruby core team to decide.

About #map: it is not a good choice, because this way you can't yield_self-ing collections anymore, which is totally legitimate case.

Re: You should not implement #to_a for your classes

zverok — Fri, 16 Feb 2018 05:38:21 -0000

Of course, as usual, feel free to :)
In fact, there is no need to ask every time, you can just translate what you find interesting, I am always for spreading the information and ideas.