zverok · HackerTrans

zverok

no profile record

Submissions

Andy Hunter on Bookshop.org’s Second Anniversary

publishingperspectives.com

2 pointsby zverok4 anni fa0 comments

In Praise of the Singular “They” in Literary [Ukrainian to English] Translation

lithub.com

2 pointsby zverok5 anni fa0 comments

A Writer from the Future: Who Was Sci Fi Iconoclast Izumi Suzuki?

lithub.com

3 pointsby zverok5 anni fa0 comments

Who Is “Public” Data For?

lithub.com

41 pointsby zverok5 anni fa21 comments

“Embarassing words”– on a relationship between natural and programming languages

code-anth.xyz

1 pointsby zverok5 anni fa0 comments

Meditation on Sale

theitalianreview.com

1 pointsby zverok5 anni fa0 comments

Tales of the Autistic Developer – Myth of the Autistic Jerk

dev.to

1 pointsby zverok5 anni fa0 comments

Presentation on APL Style and approach to coding (2017)

sway.office.com

1 pointsby zverok5 anni fa0 comments

The Second Wave of Instagram Poetry Is Here

bustle.com

1 pointsby zverok5 anni fa0 comments

(ever so slightly) weird facts about the most popular dictionary format

zverok.github.io

1 pointsby zverok5 anni fa0 comments

Rebuilding the Spellchecker: Well, Akchualy

zverok.github.io

1 pointsby zverok5 anni fa0 comments

Rebuilding the spellchecker: Hunspell and the order of edits

zverok.github.io

1 pointsby zverok5 anni fa0 comments

Rebuilding the spellchecker, pt.4: Introduction to suggest algorithm

zverok.github.io

5 pointsby zverok6 anni fa0 comments

Rebuilding the spellchecker

zverok.github.io

151 pointsby zverok6 anni fa24 comments

Rebuilding the spellchecker, pt.2: Just look in the dictionary, they said

zverok.github.io

9 pointsby zverok6 anni fa0 comments

Rebuilding the most popular spellchecker. Part 1 (Groking Hunspell)

zverok.github.io

13 pointsby zverok6 anni fa1 comments

comments

3 anni fadiscuss

(Author here)

I don't think this corresponds to my experience.

I am working as a staff engineer in big production codebases (with all the traits of those: some code is good, some is bad, some is unrecognizable legacy, sometimes we are in a hurry and write awful code, sometimes we have time for refactoring etc.)

And my observations about the logic and perception of the features are drawn from the practice of code reviews, mentoring new people, and discussing ways of solving tasks in this environment. Obviously, I am frequently a driver of new code practices, but I am also trying to be a good person and a good colleague and notice how comfortable people are with various parts of the codebase, various idioms, etc.

One of the main topics of this article series is uncovering the language's logic and intuitions (to stop perceiving it as a "bag of random syntactic features you need to learn or should guess") and using those intuitions for code that is, yes, better for the reader, but the code that can be created in a quickly-changing production environment and rewritten fearlessly.

3 anni fadiscuss

Oh, thanks! Added a footnote to the article.

3 anni fadiscuss

Thanks, that's the highest praise I could possibly hope for :)

It is one of the things I always enjoyed and tried to achieve myself (when the discussion of design decisions in one language would provide food for thought in the context of other languages/domains).

3 anni fadiscuss

(Author here)

Well, unfortunately a lot of new stuff becomes controversial on the pure ground of "no new language changes! it is good enough for me!"

TBH, I thought about a post series like this for a long time, but the last trigger was an announce of a special Rubocop addon to "disable useless syntax sugar"[1], and pattern matching was one of the "useless sugars" in the list. So I felt I need to cover it, too. And in the end of the day, I think it is an interesting excercise to analyse it in the same way as other, less significant and more controversial, features (the most intresting stuff would be in the second part, though).

1: https://www.reddit.com/r/ruby/comments/16slc10/announcing_ru...

3 anni fadiscuss

Ruby didn't always had both. `reduce` as an alias for `inject` was introduced in Ruby 1.8.7; `filter` as late as in Ruby 2.6 (just a few years ago, and most of the codebases I saw are still preferring `select`).

Yes, the dictionary is normalized in the last years towards what became industry/mainstream standard names for the concepts, but the statement that initial names were derived from Smalltalk is correct.

3 anni fadiscuss

Yeah, should've mentioned that probably (though a post is already a mess of footnotes, aside notes, and parenthicals).

I do believe though that a lot of modern languages got that from Ruby (or, via Ruby, from "JS that Rubyists wrote" and such), when it was a "hot new thing" for a brief moment in 2000s. Or maybe it is my skewed perspective.

3 anni fadiscuss

Ugh, never thought about that this way!

I believe it is a habit back from my journalistic days, when there were "insets" besides the main text with "things that deserve mentioning here, but kinda out of the main flow... but more related to it than footnotes." I miss the richness of markup of paper magazines!

Does it harm the reading experience significantly?

3 anni fadiscuss

Well, first of all, I was one of those who fought for method references as first-class objects for a few years (the story is told in my blog before[1]), and "let Ruby eventually become more functional" was one of my main arguments!

That being said, there are a few problems on this road, that make it less probable to be followed. First, as Ruby doesn't have first-class Method objects (e.g. object corresponding to `File.method(:read)` doesn't exist until you call `method(:name)` explicitly), this style being popularized will either bring a lot of subtle performance problems, or will require redesign of Ruby's internals.

Second, if we'll make an example _a bit_ more complicated, say:

  ENV.fetch('CONFIG_PATH')
    .then { File.read(_1, encoding: 'KOI8-U')
    .then { JSON.parse(_1, symbolize_names: true) }
    .dig('metadata', 'created_at')
    .then { Time.new(_1, in: CURRENT_TIMEZONE) }

...it would be impossible to rewrite with `method`, until currying would be signficantly improved (currently it can only be applied to first arguments, not tail ones, and even then looks horrible). So it is not impossible, and it is a turn of the language I'd like to see in the future, but it is not as straightforward as I once imagined.

1: https://zverok.space/blog/2022-01-13-it-evolves.html#taking-...

3 anni fadiscuss

> I don't find the hypothetical Ruby syntax ["hello","goodbye"].map(&reverse) to be offensive or wildly inconsistent.

This syntax wouldn't work in Ruby, because bare `reverse` is already a method call, not a reference to a method by name. Allowing method calls without parentheses is crucial to Ruby's design, where all objects are fully opaque, and every `obj.attr` looking like a getter, is just a call to an instance method `attr`. (This is, as far as I understand, the opposite to similar languages like Python/JS, where the object is a dictionary of attributes, and `obj.method` reference the attribute of type "method", while `obj.method()` is an invokation.)

This design became a huge drawback in the age of functional(ish) programming, because the simplest way for refer to a method in Ruby is `method(:its_name)` (which is also inefficient, because it creates wrapping object of class Method on the fly, there is no pre-existing first-class object), and any attempt of passing/combining methods would be cumbersome due to it.

FWIW, you can do that in Ruby:

  (JSON.method(:parse) >> method(:puts)).call("[1, 2, 3]")

...which is semantically cool, but looks ridiculous.

Another important trait of Ruby's design is that most of the important methods belong to their first argument, so it is not `reverse(string)` but `string.reverse`, so even to obtain a reference to a method, you need to have an object it belongs to! So you can't do that:

   method(:>).call(a, b)

...because all operators are called on their first operands, so you need this this:

   a.method(:>).call(b)

...which will require to refer to at least a first argument of the operator, so you can't produce "argument-less comparison operation to call later".

3 anni fadiscuss

I made a small nod towards Haskell's way of doing things in the last paragraph of "How others do it" section:

> We might also start look into the concept of the “tacit programming”, which, from some point of view, is also about “not repeating the arguments,” but this would be a much longer post—while it is obscenely long already.

Note though that my analysis was mostly about "how you would do that in an established language," not "how would I design a language from scratch." And Ruby is very different from Haskell in its syntax, semantics, and typical intuitions of the language writer and reader.

So designing a solution for clearer representation of "default parameters" is quite different in a language which is built around an `object.method(argument) { block }` as its atomic phrase, and one built around `function(arguments)`. (This can turn into a discussion of which phrase structure is more elegant in general... But I believe it was already done quite a few times in a history of programming languages evolution!)

3 anni fadiscuss

Well, I expected that, but slighlty hoped that ironical quotes will help (which is also part of the name of the series, started with explanatory intro[1]).

But I am afraid it is hard to do something to prevent people communicating with article title on its own. Happens all the time with me, whatever I write about! (I tried boring over-explanatory titles, people still argue with _that_.)

1: https://zverok.space/blog/2023-10-02-syntax-sugar.html

3 anni fadiscuss

Thanks, that's insightful!

3 anni fadiscuss

Yes, that's what I referred to. Before 2.7, object&.:method was almost merged (or rather merged and reverted) because Matz had second thoughts about its uglyness... Which is not completely untrue, but not having a concise way for referring to a method is irritating.

That still wouldn't have solved passing additional args, so maybe { object.method_name(_1, args)} is the next best thing. Though it perceives non-atomic due to wrapping block.

3 anni fadiscuss

Ruby-idiomatic pipe operator is Object#then. After a lot of design proposals and discussions it is more or less evident no solution other than method would integrate naturally with the rest of the code. So it is just `arg.then{ third(_1)}.then{ second(_1)}.then{ first(_1)}`

Would've been a bit more concise with method references, almost introduced in 2.7, but alas.

(But, well, people tend to want "something that looks like operator, preferably something that looks exactly like |>" and reject every other possibility)

5 anni fadiscuss

In rewritten code: https://zverok.github.io/advent2021/day11.html — I'd say it is relatively probable (grep for this line):

   if_(stories == 1, ()=> chance(2/3, ()=> [1, "Pizza Hut"]))

E.g. with 1-storey building of this type, chance is good! OTOH, the building of this type will 1 story with probability 1/4: https://github.com/zverok/grok-shan-shui/blob/main/grok.html...

...and how many of these buildings will be in the picture is more complicated. Anyway, just opened the online picture and scrolled it for a few iterations and met it almost immediately https://www.dropbox.com/s/mr1f0gpjr5zvrsq/pizza_hut.jpg?dl=0

5 anni fadiscuss

The `times` solution was overhtought, and later I get rid of it. In the end, the code of cycle like this are handled with `range`, for example:

    var points = range(resolution).map(
      i => ({x, y: y - (i * height) / resolution})
    )

The point of the rewriting `for()` cycles is not some abstract "making them new and shiny", but expose _meaning_ (in a way that would be obvious for _my reading habits_). Generally speaking, `for()` is "how we do" instead of "what we are doing". It might mean a lot of things; porting it into `map`, or `filter`, or `zip`, etc. allows to review and rethink what was the point of iteration.

As you might see in the final code[1] the initial "cycle of noise generation" you are pointint to was gone at all (because several iterations of "making it one phrase" made it obvious that it has no context of its own, and should just be embedded in a points generation).

With that being said, I explicitly stated many times throughout the diary I don't expect the approach to be for everyones liking.

[1] https://github.com/zverok/grok-shan-shui/blob/main/grok.html...

5 anni fadiscuss

Wow. Now THAT is impressive!

5 anni fadiscuss

Yeah, I am mentioning it at Day 11, while debugging the singular house logic: https://zverok.github.io/advent2021/day11.html :)

5 anni fadiscuss

I actually hope the WikipediaQL, when it will become a bit more mature, to be helpful in parsing Wikipedia data _into_ Wikidata. As of now, Wikidata lacks a lot of knowledge yet (the article talks about that, too).

5 anni fadiscuss

I am (slightly) contemplating this (see also Reddit discussion: https://www.reddit.com/r/programming/comments/oe9oia/wikiped...). But currently I am mostly focused on deducing atomic selectors that would be useful and choosing their interaction. The particular syntax is kind of afterthought.

Though, I should say that I am still not sure GraphQL's mental model would work here (WikipediaQL for now structured around "which part of the document to choose and how to transform it", with "where to put it" being the final statement just of some branches; with GraphQL, as far as I can understand, each node is "where to put it"-first, and it _may_ lead to clumsy and repetitive queries).