default-kramer

I realize no one is claiming otherwise, but this writer almost certainly did it intentionally for humorous effect. ("Aubergine wyrm" is just too good to be accidental.) It's like "the lick" in jazz.

"How can I change the background color of the selected item in a WPF ListView? It must work whether or not the ListView has focus."

I only tried ChatGPT which gives me 5 incorrect answers in a row.

I highly recommend Dragon Quest Builders to anyone who enjoys (or might enjoy) Minecraft even a little bit. It can reliably make me feel like a kid with a new Lego set for hundreds of consecutive hours.

Killer Feature #1 is the room system, which can be a great source of inspiration if you don't know what you want to build. Killer Feature #2 is the overall charm you would expect from a modern Dragon Quest game, especially the NPCs. DQB1 has the better story mode (in my opinion), while DQB2 gives you much more freedom to build.

I'm very surprised we don't see more people using a level 5 language to generate Terraform (as level 3 JSON) for this exact reason. It would seem to be the best of both worlds -- use the powerful language to enforce consistency and correctness while still being able to read and diff the simple output to gain understanding. In this hypothetical workflow, Terraform constructs like variables and modules would not be used; they would be replaced by their counterparts in the level 5 language.

https://developer.hashicorp.com/terraform/language/syntax/js...

Yeah, automated tests are great when they are good. But when they are bad, they can be worse than no tests at all.

Multiple times in my career I've taken ownership of a codebase written by someone else. Some of the most pleasant ones had very little test coverage, but the code quality was high enough to make the lack of tests not really matter. On the other hand, some code is so bad covering it with tests adds nothing of value; it's just one more thing I have to analyze and decide what to do with.

I agree with most of the author's points in general, but I think that most programmers who are capable of writing good tests are also capable of recognizing situations when it's not worth the trouble.

> Kind of disagree with this article, when you add a "noun" (aka type), you're often introducing a new abstraction.

The article is talking about simple "bundle of values" types; the example is the CreateSubscriptionRequest. This is not an abstraction. It is simply a declaration of all the fields that must be provided if you want to create a subscription. And it is usually superior to passing those N fields around individually.

> Pass 5 variables individually, the only difference will be in verbosity.

Which can be an extremely significant difference. If you're already using a single object and add a 6th field, you only need to update the places where the object is constructed and where the new field is consumed. If you're using individual variables, you also need to update all the code that those 5, now 6, variables simply pass through.

> When you have one engineer who is empowered to write SQL specifically crafted to pull the exact columns required to SSR a web view (which they are also responsible for), you don't need to spend a single second thinking about APIs or ORMs or whatever. You just need to know SQL and modern vanilla HTML/CSS/JS.

A million times yes!

> I think the end game is doing SSR of web content inside the RDBMS

That feels like one step too far for me. I think things like authorization and HTML rendering belong in a separate layer.

But I do believe that more than 90% of today's "server side code" actually belongs in the RDBMS, and I blame the weakness of SQL as the reason no one wants to do this.

A good DBA would restrict the account so that it can't access the information schema. It's easy to imagine an environment with a vigilant DBA and less vigilant web developers.

> I can't imagine how the schema would reveal SQL injection holes.

It wouldn't. I'm just assuming that the thrust of the hypothetical negligence accusation was "The schema is useless unless you have SQL injection holes. So give us the schema or admit you are negligent!" But you're correct that there are other justifications one could make to keep the schema secret.

Maybe I'm ignorant, but if the account the app is using doesn't have access to the information_schema how do you do this?

"Defense in depth" is an easy argument to make. I sure hope I don't have any SQL injection holes, but I can't prove it with 100% certainty.

Right, and that's what you use to find the vulnerability. But imagine you've found the vulnerability and now you want to use it to update all of your parking tickets as paid. Without the schema, this is going to be quite tricky and will generate a lot of failed SQL. With the schema, you might be able to do it on your first try.

> How does knowledge of a column name make it easier for me to discern whether a SQL injection vulnerability exists?

It doesn't. It just means that as soon as you find one, you can immediately begin crafting valid queries instead of randomly guessing table names and columns, therefore not setting off the "DB query failed" alert.

EDIT: I guess this is the part I missed:

> To have a meaningful chance of blind-one-shotting a query, getting a TRUE/FALSE answer about susceptibility without ever generating a SQL syntax error, I would need to see the queries themselves.

Really? I guess I have to take your word for it because I've never attempted it, but I would have thought that in some (horribly broken) systems `bobby tables' or 1=1 --` would have a very reasonable chance of detecting SQL injection without alerting anyone.

Why would someone acting in good faith do as much outrageous trolling as Trump and Musk do?

Thanks, I am appreciating reading this discussion.

> Of all the things you listed about Trump, I’d only really take issue with two

So then you agree that he tried to overthrow an election? This is the wild part to me. I don't know whether his actions after losing the 2020 election were technically illegal or not, but in my opinion this was the clearest threat to America's peaceful transition of power I've ever witnessed. I thought "okay, this is at least 50x worse than Watergate, even Trump won't survive this." Then amazingly (to me), he won in 2024. My only hypothesis for how that happened is that 99% of people who voted for him believed his unfounded claims regarding the 2020 election. But you seem to be an interesting counterexample.

I remain unimpressed by KQL. Comparing SQL to KQL is approximately like comparing Java to C#. Yeah it's better in many ways, but at the end of the day it doesn't make a huge difference. I want to go from Java to Lisp.

Consider how many of these complaints are equally valid against KQL: https://www.scattered-thoughts.net/writing/against-sql/

I'm very surprised to learn that PRQL does not natively support `like`, but you can add it yourself: https://github.com/PRQL/prql/issues/1123#issuecomment-135385...

I'm still working on it, but I think a key idea is that 1) The "host" tells you he is going to eliminate one of the two losing options, and then allow you to choose from the two remaining options. 2) The host allows you, if you wish, to "protect" one of the options from being eliminated. If you choose to protect, you may still choose either of the remaining options after elimination occurs.

The correct solution is to protect one of the options and then choose the other option.

The real challenge is coming up with appropriate flavor text for this idea, but I think I'll get it eventually.

> But we do know: it's always on purpose, Monty never opened a door with a car behind it

We only know that if the problem tells us. Sometimes it doesn't.

> There are no ambiguities in the Monty Hall problem

The problem has been written up thousands of times. I'm sure that some writeups are sufficiently unambiguous, but many are not. For example, consider the two "variants" described by this comment https://news.ycombinator.com/item?id=8664550

> The host selects one of the doors with a goat from the remaining two doors, and opens it.

> The host chooses one of the remaining two doors at random and opens it, showing a goat.

This commenter was trying hard for semantic precision, and yet, I think if you encountered the first variant in isolation it would be perfectly reasonable to interpret it as "The host [randomly] selects one of the doors with a goat [although he might have selected the prize]" even though this is clearly not what the commenter was attempting. If you disagree, that only proves my point: this problem is prone to silly and wasteful semantic debate, rather than the interesting probability result it should be focused on.

Not this again... https://duckduckgo.com/?q=monty+hall+site%3Anews.ycombinator...

I need to write a blog post or something convincing everyone we need to stop talking about the Monty Hall problem and replace it with a new problem with all the ambiguities removed. (Unless ambiguity is the point, then Monty Hall is fine.)

> And for this new hash table, the time required for worst-case queries and insertions is proportional to (log x)2 — far faster than x.

> The team’s results may not lead to any immediate applications

I don't understand why it wouldn't lead to immediate applications. Is this a situation where analysis of real-world use cases allows you to tune your hash implementation better than what a purely mathematical approach would get you?

> where is DOGE’s evidence of all of this corruption?

Presumably this was published by DOGE: https://www.whitehouse.gov/fact-sheets/2025/02/at-usaid-wast...

I encourage everyone to follow the links and determine the accuracy of the claims being made.

I hope this is true. Can you name any senior people and/or financial auditors who are overseeing "the youngins"?

And not just the ORM, but the way it's used. If you ensure that lazy-loading is turned off from day 1 and stays off, you might be okay. But if you don't pay attention to this and write a bunch of code for N years until all the "select N+1"s you've been unwittingly doing finally force your DB to a crawl... now you're in trouble.

Hard disagree on the 10kloc limit. At a previous job, I maintained and enhanced a 50kloc monolith (written by someone else), usually by myself. My productivity was very high. At my current job, we've split a codebase that should be about 50kloc into more than 10 separate repositories; everything is still just as coupled but it's much harder to reason about and refactor. My productivity is much lower.

> Either the candidate earns a position fair and square, in which case you don't need "DEI", or you are discriminating against someone else more deserving, and therefore lowering the bar overall.

False dichotomy. It's possible that in some situations DEI could replace cronyism and produce better hires. I have no idea how often that actually happens, but I know that cronyism happens a lot.

I looked at it when it hit HN a while ago. Looks nice, but not exactly what I want because

> Joins and source tables are automatically resolved in Trilogy. You won't ever explicitly specify one in your query; you're declaring what you want, not how to get it. The responsibility of how to get it is delegated to the semantic model.

I don't fully understand how the semantic model is created (is this documented anywhere?), but I don't think I would enjoy a hard separation between the query layer and the semantic layer regardless.

I would prefer a continuum of "how much indirection do I really want" to be available to the user. My own exploration of this topic is https://docs.racket-lang.org/plisqin/index.html and you can compare section 2 (Using define-schema) to section 7.2 (Plisqin Desugared) if you want to know what I mean about a continuum.

Unrelated, the article we are commenting on has inspired me such that I think I have an answer to the big type system questions that eluded me when I decided to put Plisqin on the shelf. Maybe time to pick it up again... but probably not.

> Compose SQL in an actual real programming language that isn't horrible instead of doing any of this.

Got any recommendations? That's a serious question, I've tried many (and built my own) and some are okay but none feel remotely good enough when you consider how much progress we've made basically everywhere else in the wider world of software engineering. Relational databases are so good; they deserve better than SQL!

The goal is that the composable parts get woven into an efficient, planner-friendly query. Stored procedures completely undermine that unless something very exciting has happened since last I checked (SQL Server, but probably applies to all of them). You will likely end up in a "row by agonizing row" situation.

(Okay, maybe you can find a few cases where stored procs work decently, but in general both composability and performance will be much worse than the proposed functors.)