Hacker News: duesabati

New comment by duesabati in "Chess invariants"

duesabati — Fri, 22 May 2026 13:32:36 +0000

While I think everything written in this post is correct, what really is starting bothering me is this over-focus/attention on data even when what you want to express is behavior, let me explain:

The post talks about "transition invariants" that should be somehow different from "state invariants" yet it describe them as:

> These are predicates over a <> pair ...

i.e. it still is about state, but I find it much more useful to focus on behavior so instead of thinking about how state transition you focus on what the program is allowed to perform, regardless of the underlying data structure.

What I mean is that I'd like the code to tell me why a certain piece can't do such move instead of why it cannot transition it's position to another position and basically dumping its state in my head and there I have to execute the program myself.

New comment by duesabati in "Composition Shouldn't be this Hard"

duesabati — Fri, 24 Apr 2026 09:48:37 +0000

Yeah exactly, came to the comments just for this check

New comment by duesabati in "Lumina – a statically typed web-native language for JavaScript and WASM"

duesabati — Tue, 14 Apr 2026 13:47:23 +0000

I think this project is super interesting and I really like the rust inspiration here. How can one get in touch with you and/or help out the project?

New comment by duesabati in "A sufficiently detailed spec is code"

duesabati — Thu, 19 Mar 2026 09:18:28 +0000

You mean as arguments that proves the author's pov? Yeah definitely

New comment by duesabati in "A sufficiently detailed spec is code"

duesabati — Thu, 19 Mar 2026 09:16:13 +0000

With ALL due respect (seriously), this is just a misconception of yours.

When you write software to solve a problem you start with as little as possible details such that when you read it, it would only talk about the business logic. What I mean by that? That you abstract away any other stuff that does not concern the domain you are in, for example your first piece of code should never mention any kind of database technology, it should not contain any reference to a specific communication layer (HTTP for example), and so on.

When you get to this, you have summarized the "spec", and usually it can be read very easily by a non-techincal person (but obviously is a "domain expert") and can also be very testable.

I hope this helps on why the author is right 100%

New comment by duesabati in "I love the work of the ArchWiki maintainers"

duesabati — Sun, 15 Feb 2026 13:37:18 +0000

I can see that too, this might be a reason for its success, all the articles are very straightforward and full of paths you may encounter

New comment by duesabati in "I love the work of the ArchWiki maintainers"

duesabati — Sun, 15 Feb 2026 13:35:32 +0000

Me too, I started with Debian but after a few weeks, I found myself being more on the Arch wiki than the Debian's one so I did the switch and never used any other distro.

I'm sorry to say this but Debian's documentation sucked a lot some years ago.

New comment by duesabati in "Clean Coder: The Dark Path (2017)"

duesabati — Mon, 09 Feb 2026 10:47:01 +0000

I think you you're missing the point though, he did not say that adding those constraints was a bad idea per se, but they are leading to a bad path. If the path is "just add more guard-rails" then we will get to a point where we lose the "soft" part of "software" and you'll find yourself restarting each time you need to change something because at that point the language you chose was already the first wall of a bad program architecture (ease of change).

New comment by duesabati in "“Stop Designing Languages. Write Libraries Instead” (2016)"

duesabati — Wed, 07 Jan 2026 22:02:38 +0000

Yeah I can see that, but that lisp feature is not exclusive to lisp, if you know what you want and what you are doing you can implement the very same thing in any other language, you may say it is convenient that lisp already has it, but it does not make it more powerful. I don't know list, but there will surely be something that is missing from it that another language has it, now I ask you which is more powerful? See? Everything is relative to what you want to do. The very author of the blog you shared is falling in the same set of programmers he wants to criticize because now he thinks in lisp macro and the very moment he cannot use lisp, he will feel lost but has he stopped and thought that what he needed was something to manipulate code at compile time he could have used any language

New comment by duesabati in "“Stop Designing Languages. Write Libraries Instead” (2016)"

duesabati — Wed, 07 Jan 2026 15:31:10 +0000

I understand and agree, what I was trying to say is that one should not confine ones thinking by the constraints of a tool, would it be a programming language or whole framework, but to express everything as freely as possible without details of implementation only then one can go deeper and add concreteness that brings its set of constraints and all of this should be possible in any programming languages.

I hope I've cleared my standpoint.

New comment by duesabati in "“Stop Designing Languages. Write Libraries Instead” (2016)"

duesabati — Wed, 07 Jan 2026 15:25:21 +0000

No I wasn't, it was a really interesting read thank you, but that blog post seem to me like an argument for me not the OP point of view, because if you refuse to understand how things work by blindly delegating to libraries and frameworks (like RoR) you become a "Blub" programmer that thinks in the way of constructs and decisions that the library/framework authors made.

New comment by duesabati in "“Stop Designing Languages. Write Libraries Instead” (2016)"

duesabati — Wed, 07 Jan 2026 13:55:48 +0000

I completely disagree with the post.

All programming languages are equivalent meaning their level of expressiveness is the same, it's not an opinion it's a fact. Each language comes with its runtime and its peculiarities but potentially you can always make any feature that another language runtime has with any language, even though probably not with the same performance and efficiency has been that feature native to the runtime itself.

So there are no "more powerful languages" just runtimes that allow you to hide away some stuff considered stable enough that they become some kind of primitive for the programmer, now we may have different opinions on what elegant code is, but personally I'd like to avoid code that directly (i.e. no kind of abstraction) relies on runtime features and instead express clearly my intention in code, but I recognize the productivity gains.

New comment by duesabati in "FreeDroidWarn"

duesabati — Tue, 02 Sep 2025 07:24:23 +0000

I was very interested in Graphene, do you have other grounds for your suspicions?

New comment by duesabati in "Bidirectional Signals from the Emitter's Perspective in PHP"

duesabati — Mon, 01 Sep 2025 13:23:11 +0000

Without taking anything away from the author, I think he could have saved a few words by simply defining the point that events should be seen as commands rather than messages or passed-events.

New comment by duesabati in "The United States withdraws from UNESCO"

duesabati — Tue, 22 Jul 2025 14:26:02 +0000

  > America First
  > anti-Israel

American Government became the parody of itself, so sad

New comment by duesabati in "Deno 2.4"

duesabati — Mon, 07 Jul 2025 09:56:16 +0000

I really love where Deno is going, it really is what Node should've been.

My only concern is that they lose patience to their hype-driven competition and start doing hype-driven stuff themselves.