martinhath

ETH is false! This is one of the big long-standing hypotheses that I actually remember from university, and afaik, it was reasonable to assume it would be true; reasonable enough for a lot of papers and results to assume this for bounds or hardness proofs of common problems in parameterized complexity, anyways.

Also glad to see that one of the authors of the paper stating it is also in the loop here.

2026 is weird.

> Jevons paradox occurs when a more efficient use of a resource leads to an increase in its use

I think these are the same, because efficiency is value over cost. In the original formulation of the paradox, a more efficient steam engine lead to a rise in coal consumption. You can look at this as a "money buys coal, coal drives locomotion" system, where the latter part was improved. Modulo practical issues with coal (transport, storage, etc), dropping the price of coal would (probably?) lead to the same effect, since the end result is that locomotion per money is increased. For an outside observer, it doesn't matter if you get more coal per money or more locomotion per coal.

> standard supply and demand

Standard supply and demand doesn't say anything about increase of spend. If food prices drop, I'm not going to buy more food. I might buy better food for the same budget, but there's no reason why my total food spend should increase.

This is from C.A.R Hoare's "Prospects for a better programming language" (1972) [0]:

> It is on production runs that the security is most required, since it is the results of production runs that will actually be trusted as the basis of actions such as expenditure of money and perhaps even lives. The strategy now recommended to many programmers is equivalent to that of a sailor who wears a lifejacket during his training on dry land but takes it off when he is sailing his boat on the sea. It is small wonder that computers acquire a bad reputation when programmed in accordance with this common policy.

It is also quoted by Donald Knuth in "Structured programming with goto statements" (1974) [1] ( which incidentally is also the source of the quote about premature optimization):

> He [Tony Hoare] points out quite correctly that the current practice of compiling subscript range checks into the machine code while a program is being tested, then suppressing the check during production runs, is like a sailor who wears his life preserver while training on land but leaves it behind when he sails!

[0]: https://ora.ox.ac.uk/objects/uuid:dff9483b-e72f-4599-bf90-76... p. 341

[1]: https://dl.acm.org/doi/pdf/10.1145/356635.356640 p. 269

How would errdefer work in the general union setting?

Having errors as a first class construct in the language allows things like errdefer to be very simple and easy to use. It looks needlessly specialised at first, but I think it’s actually a really good design.

I’m pretty sure it’s intentionally a dark pattern.

Not just in theory, they can, and do, fail in practice.

> Clean code / readable code / whatever you want to call it is often at odds with performance.

I disagree; or rather, I'd put it the other way around by saying that often you can get both clean code (by some metric) and reasonable performance. The patterns in e.g. the book by Robert Martin doesn't give you either, though.

> And for most enterprise projects it just doesn't matter.

It matters for the users. I use software that is slow for no good reason, and I'd like to live in a world where this is not the case.

> At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. "clean code", is a valid goal.

Nobody is arguing against comprehensible code. Caseys video is not about clean code in general, but "Clean Code" as presented e.g. in the book by Robert Martin, which contains a bunch of code I would not classify as "clean" by any metric.

> But as others pointed out, he focus on squeezing every bit of performance in the context of real-time video game logic

He doesn't, though. The "Clean Code, Horrible Performance" video is an excerpt from his course called "Performance-Aware Programming", where he explicitly says many times that the course isn't at all about "optimization", but merely being "performance aware". This isn't highlighted in the video though, so getting the full context is difficult.

OnShape is pretty nice, but their language, FeatureScript, is a disaster.

> Who is the author arguing against?

This is addressed in the third paragraph:

> The problem with this saying is that many people wrongly interpret it as “early optimization is the root of all evil.” In fact, writing fast software from the start can be hugely beneficial.

I sat down and read the original paper a few years back with the same intent as the author here, and afterwards I listed a couple of quotes that I found interesting [0]. It didn't really get any traction [1], but maybe someone here will find it interesting.

[0]: https://mht.wtf/post/structured-programming-quotes/

[1]: https://news.ycombinator.com/item?id=19254310

> This is perhaps too big a burden on a user. Some might say they rather not have the compositionality unless it's guaranteed to be correct.

I think this is it. Or rather, I think to some people, myself included, compositionality should imply correctness. If you /can/ compose things, but the result is wrong, can you really say that you've got composition?

How useful it is really to be able to plug in your own types in other peoples libraries if you have to trace through the execution of that library, figure out which libraries they transitively use, to ensure that all of your instantiations are sound? How do you even test this properly?

It's a really hard problem, and from what I can tell, Julia gives you no tools to deal with this.

[0] is probably relevant here, although I'm not sure I share the positive outlook.

[0]: http://www.jerf.org/iri/post/2954

That's not what this is, and if you'd bothered to look for more than a second, you'd seen that too. All the claims listed are very concrete claims that are possible to falsify, unlike "Thing good!", and the research (which, admittedly isn't directly linked, so it might be hard to find what research they're referring to) shows that this is either not true, or that the research is inconclusive. It is important not to take these statements for granted if they cannot be shown to be true; that's simply cargo-culting.