Hacker News: Dan42

New comment by Dan42 in "It's 2026, Just Use Postgres"

Dan42 — Fri, 06 Feb 2026 01:27:15 +0000

That article was clearly written by AI, based on data from 20 years ago.

New comment by Dan42 in "T-Ruby is Ruby with syntax for types"

Dan42 — Sat, 27 Dec 2025 03:57:20 +0000

Yeah, it doesn't work with keyword arguments. In the playground I tried a simple keyword with default value, and it converted to the wrong thing, as if "someone" was a valid type.

    def greet(name: "someone"): String
      "Hello, #{name}!"
    end

New comment by Dan42 in "Ruby Blocks"

Dan42 — Sat, 18 Oct 2025 12:29:32 +0000

This is really cute and heartwarming.

Back in the day, a lot of people including me reported feeling more comfortable in Ruby after one week than all their other languages with years of experience, as if Ruby just fits your mind like a glove naturally.

I'm glad new people are still having that "Ruby moment"

New comment by Dan42 in "The illegible nature of software development talent"

Dan42 — Sat, 11 Oct 2025 14:34:31 +0000

Wow. You are me.

New comment by Dan42 in "The Theatre of Pull Requests and Code Review"

Dan42 — Thu, 25 Sep 2025 14:15:51 +0000

I see posts like this one pop up from time to time. I love it. Based on my 30y of exp that's also the workflow I converged on. It seems to me like every experienced and skilled developer is converging on this. jujutsu is entirely built to accommodate this workflow.

There are no silver bullets or magical solutions, but this is as close to one as I've ever seen. A true "best practice" distilled from the accumulated experience of our field, not from someone with something to sell.

New comment by Dan42 in "Quicksort explained IKEA-style"

Dan42 — Wed, 24 Sep 2025 20:27:13 +0000

Actually you're right, it is an implementation detail. The original isn’t mistaken, it’s just showing the lo-to-hi partitioning pass rather than the from-both-ends version I had in mind when I implemented quicksort before.

shame, shame, I should have double-checked before posting.

New comment by Dan42 in "Quicksort explained IKEA-style"

Dan42 — Wed, 24 Sep 2025 19:47:45 +0000

I'm pretty sure the swapping is a fundamental part of the quicksort algorithm, not a mere implementation detail. That's the reason quicksort is an in-place algorithm.

New comment by Dan42 in "Quicksort explained IKEA-style"

Dan42 — Wed, 24 Sep 2025 18:22:10 +0000

This is cool, but missing a LOT of details between steps 4 and 5, which is the meat of the quicksort. Actually, the first and last elements of step 4 would be swapped, which means the order depicted in step 5 is incorrect.

New comment by Dan42 in "Look Out for Bugs"

Dan42 — Mon, 08 Sep 2025 15:44:06 +0000

This article really resonated with me. I've been trying to teach this way of thinking to juniors, but with mixed results. They tend to just whack at their code until it stops crashing, while I can often spot logic errors in a minute of reading. I don't think it's that hard, just a different mindset.

There's a well-known quote: "Make the program so simple, there are obviously no errors. Or make it so complicated, there are no obvious errors." A large application may not be considered "simple" but we can minimize errors by making it a sequence of small bug-free commits, each one so simple that there are obviously no errors. I first learned this as "micro-commits", but others call it "stacked diffs" or similar.

I think that's a really crucial part of this "read the code carefully" idea: it works best if the code is made readable first. Small readable diffs. Small self-contained subsystems. Because obviously a million-line pile of spaghetti does not lend itself to "read carefully".

Type systems certainly help, but there is no silver bullet. In this context, I think of type systems a bit like AI: they can improve productivity, but they should not be used as a crutch to avoid reading, reasoning, and building a mental model of the code.

New comment by Dan42 in "How RubyGems.org protects OSS infrastructure"

Dan42 — Mon, 25 Aug 2025 23:50:08 +0000

Reading this, I couldn't help but think these guys really know where their towel is. The opposite of enshittification?

New comment by Dan42 in "I've Had It with Microsoft"

Dan42 — Sun, 27 Jul 2025 11:38:51 +0000

Beautiful. I had that exact computer model 30 years ago.

New comment by Dan42 in "Trusting your own judgement on 'AI' is a risk"

Dan42 — Mon, 09 Jun 2025 18:15:21 +0000

> Don't we have decades of research about the improvements in productivity and correctness brought by static type checking?

Yes, we have decades of such research, and the aggregate result of all those studies is that no productivity gain can be significantly demonstrated for static over dynamic, and vice-versa.

New comment by Dan42 in "Triptych Proposals"

Dan42 — Wed, 08 Jan 2025 15:26:32 +0000

> This is incorrect, according to this comment from the Firefox implementer who delayed the feature. He intended the roll back to be temporary. [0]

I see no such thing in the link you have there. #ref-6 starts with:

> [6] On 01/12/2011, at 9:57 PM, Julian Reschke wrote: "One thing I forgot earlier, and which was the reason

But the link you have there [1] does not contain any such comment. Wrong link?

[1] https://lists.w3.org/Archives/Public/public-html-comments/20...

(will reply to other points as time allows, but I wanted to point out this first)

New comment by Dan42 in "Triptych Proposals"

Dan42 — Wed, 08 Jan 2025 01:21:51 +0000

No, please, just no.

The idea of using PUT, DELETE, or PATCH here is entirely misguided. Maybe it was a good idea, but history has gone in a different direction so now it's irrelevant. About 20 years ago, Firefox attempted to add PUT and DELETE support to the

element, only to roll it back. Why? Because the semantics of PUT and DELETE are not consistently implemented across all layers of the HTTP infrastructure—proxies, caches, and intermediary systems. This inconsistency led to unpredictable failures, varying by website, network, and the specific proxy or caching software in use.

The reality we live in, shaped by decades of organic evolution, is that only GET and POST are universally supported across all layers of internet infrastructure.

Take a cue from the WHATWG HTML5 approach: create your RFC based on what is already the de facto standard: GET is for reading, and POST is for writing. The entire internet infrastructure operates on these semantics, with little to no consideration for other HTTP verbs. Trying to push a theoretically "correct" standard ignores this reality and, as people jump into the hype train, will consume significant time and resources across the industry without delivering proportional value. It's going to be XHTML all over again, it's going to be IPv6 all over again.

Please let's just use what already works. GET for reading, POST for writing. That’s all we need to define transport behavior. Any further differentiation—like what kind of read or write—is application-specific and should be decided by the endpoints themselves.

Even the element’s "action" attribute is built for this simplicity. For example, if your resource is /tea/genmaicha/, you could use . Voilà, relative URLs in action! This approach is powerful, practical, and aligned with the infrastructure we already rely on.

Let’s not overcomplicate things for the sake of theoretical perfection. KISS.

New comment by Dan42 in "Why pipes sometimes get "stuck": buffering"

Dan42 — Sat, 30 Nov 2024 03:57:00 +0000

grep has a --line-buffered option that does the job fine in most cases. Just set in your aliases grep='grep --line-buffered', that way you get the correct behavior when you tail logs piped to a sequence of greps, and you avoid the performance penalty in scripts.

New comment by Dan42 in "Testing for gender differences in Python programming style and quality on GitHub"

Dan42 — Thu, 31 Oct 2024 02:46:58 +0000

I'm 47 and I also have never heard this in my life. So I don't think it's just a matter of younger generations.

New comment by Dan42 in "I love programming but I hate the programming industry"

Dan42 — Sun, 21 Apr 2024 14:00:07 +0000

An order of magnitude is a bit much. I'd say quick and dirty gets you 3 shots, while slow and beautiful gets you 1. And if you succeed, it means the result is dirty/ugly code that must be maintained forever.

New comment by Dan42 in "A Plea for More Mikado"

Dan42 — Thu, 01 Feb 2024 16:22:52 +0000

It's the first time I hear "Mikado" but it's pretty much the commit policy I established for work, and we call it micro-commits.

http://lucasr.org/2011/01/29/micro-commits/

https://mrcote.info/blog/2017/12/04/more-lessons-from-mozrev...

https://dev.to/rpalo/plan-your-commits

The article focuses on refactoring and migrations, but it works also for regular development. One rule of thumb is: write a one-line commit message, and then write the code described by the commit, and just that. Another rule of thumb is that refactors should go into their own commit. So while you are coding according to your one-line commit message, if there are small refactors needed along the way, commit them separately. Fix whitespace? One commit. Extract a method so you can re-use it? One commit to extract, then use the extracted method in your next commit.

Having small atomic commits makes code that is much easier to review, and much easier to test. I think it's similar to unit testing: we change how we write code in order to make it unit-testable. This is for code review: we write code with micro-commits in order to make it code-reviewable.

This method is pretty much incompatible with squash-and-rebase. Squashing throws away all the useful information of micro-commits. Instead, just merge, and the merge commit itself is equivalent to the squashed-rebased version.

> Obviously, the Mikado Method cannot work if you don’t have a good and highly reliable automated test suite.

I disagree. Of course it's always better to have an automated test suite. But in the absence of one, the only thing you can rely on is thorough code review. And with micro-commits you have a much better chance of spotting problems if the code-diff you review contains only a small self-contained atomic change. Code-reviewing a large squashed commit is all but impossible.

New comment by Dan42 in "Email addresses are not good 'permanent' identifiers for accounts"

Dan42 — Sun, 31 Dec 2023 15:12:15 +0000

I can't believe such satirical gold is getting downvoted.

New comment by Dan42 in "It's time to put REST to rest"

Dan42 — Thu, 28 Dec 2023 21:57:16 +0000

Yep, this is pretty much what I've settled on myself.

GET for read, POST for write. And a url made of a slash-terminated "resource" followed by an "action" verb. user 123 + edit = "/user/123/edit" ; user 123 + default(show) = "/user/123/" ; list of users = "/user/list" ; etc.

When applied to web pages, it means you can have and the "action" attribute of the form directly matches the "action" of the backend/router/API. I like that, it makes me feel warm and fuzzy. :-)