When the Overton Window shifts to the point where saying "people should be decent to one another" becomes a radical ideological statement, make sure you flag every comment that says that too. We can't have radical ideologues on HN, after all.

Are you suggesting that the results of calculations should always be some sort of primitive value? It's not clear what you're getting hung up on here.

Getting this wrong will not be a learning experience, because it will kill you. This is an incredibly dangerous thing to do and should only be done by people who already know what they're doing.

That's not just a tangential tidbit -- you don't learn well when you are completely out of your depth. You learn well when you are right at the edge of your ability and understanding. That involves risk of failure, but the failure isn't the important part, operating on the boundary is.

What do any of these have to do with guarantees of long-term compatibility? I'm not arguing that there should be One Programming Language To Rule Them All, I'm asking about whether we can design better guarantees about long-term compatibility into new programming languages.

> What?? No. If it was there'd never be any bugs.

Are you claiming there is no incorrect math out there? Go offer to grade some high-school algebra tests if you'd like to see buggy math. Or Google for amateur proofs of the Collatz Conjecture. Math is just extremely high (if not all the way) on the side of "if it compiles, it is correct", with the caveat that compilation only can happen in the brains of other mathematicians.

    weather forecasting models <=> code <=> math

    weather forecast <=> program output <=> calculation results

That is not counter to what I'm saying.

    Mathematical notation <=> Programming Languages.

    Proofs <=> Code.

You are certainly free to use a different set of axioms than ZF(C), but you need to be very careful about which proofs you rely on; just as you are free to use a very different programming language or programming paradigm, but you may be limited in the libraries available to you. But if you wake up one morning and your code no longer compiles, that is the analogy to one day mathematicians waking up and realizing that a previously correct proof is now suddenly incorrect -- not that it was always wrong, but that changes in math forced it into incorrectness. It's rather unthinkable.

Of course programming languages should improve, diversify, and change over time as we learn more. Backward-compatible changes do not violate my principle at all. However, when we are faced with a possible breaking change to a programming language, we should think very hard about whether we're changing the original intent and paradigms of the programming language and whether we're better off basically making a new spinoff language or something similar. I understand why it's annoying that Python 2.7 is around, but I also understand why it'd be so much more annoying if it weren't.

Surely our industry could improve dramatically in this area if it cared to. Can we write a family of nested programming languages where core features are guaranteed not to change in breaking ways, and you take on progressively more risk as you use features more to the "outside" of the language? Can we get better at formalizing which language features we're relying on? Better at isolating and versioning our language changes? Better at time-hardening our code? I promise you there's a ton of fruitful work in this area, and my claim is that that would be very good for the long-term health and maturation of our discipline.

And yet math proofs from decades and centuries ago are still correct. Note that I said we write "code that lasts", not "programming languages that never change". Math notation is to programming languages as proofs are to code. I am not saying programming languages should never change or improve. I am saying that our entire industry would benefit if we stopped to think about how to write code that remains "correct" (compiling, running, correct behavior) for the next 100 years. Programming languages are free to change in backward-compatible ways, as long once-correct code is always-correct. And it doesn't have to be all code, but you know what they say: there is nothing as permanent as a temporary solution.

This is like saying "you haven't read the source code of the first version of Linux". The only reason to do that would be for historical interest. There is still something timeless about it, and I absolutely did learn Euclid's postulates which he laid down in those books, all 5 of which are still foundational to most geometry calculations in the world today, and 4 of which are foundational to even non-Euclidean geometry. The Elements is a perfect example of math that has remained relevant and useful for thousands of years.

While writing "timeless" code is certainly an ideal of mine, it also competes with the ideals of writing useful code that does useful things for my employer or the goals of my hobby project, and I'm not sure "getting actual useful things done" is necessarily LISP's strong suit, although I'm sure I'm ruffling feathers by saying so. I like more modern programming languages for other reasons, but their propensity to make backward-incompatible changes is definitely a point of frustration for me. Languages improving in backward-compatible ways is generally a good thing; your code can still be relatively "timeless" in such an environment. Some languages walk this line better than others.

Are you intentionally leaning into the exact caricature I'm referring to? "Real programmers only use Typstly, because it's the newest!". The website title for Typst when I Googled it literally says "The new foundation for documents". Its entire appeal is that it's new? Thank you for giving me such a perfect example of the symptom I'm talking about.

> TeX and family are stagnant, difficult to use, difficult to integrate into modern workflows, and not written in Rust.

You've listed two real issues (difficult to use, difficult to integrate), and two rooted firmly in recency bias (stagnant, not written in Rust). If you can find a typesetting library that is demonstrably better in the ways you care about, great! That is not an argument that TeX itself should change. Healthy competition is great! Addiction to change and newness is not.

> nobody uses infinitesimals for derivatives anymore, they all use limits now

My point is not that math never changes -- it should, and does. However, math does not simply rot over time, like code seems to (or at least we simply assume it does). Math does not age out. If a math technique becomes obsolete, it's only ever because it was replaced with something better. More often, it forks into multiple different techniques that are useful for different purposes. This is all wonderful, and we can celebrate when this happens in software engineering too.

I also think your example is a bit more about math pedagogy than research -- infinitesimals are absolutely used all the time in math research (see Nonstandard Analysis), but it's true that Calculus 1 courses have moved toward placing limits as the central idea.

Yes, some programming languages have more landmines and footguns than others (looking at you, JS), and language designers should strive to avoid those as much as possible. But I actually think that C# does avoid those. That is: most of what people complain about are language features that are genuinely important and useful in a narrow scope, but are abused / applied too broadly. It would be impossible to design a language that knows whether you're using Reflection appropriately or not; the question is whether their inclusion of Reflection at all improves the language (it does). C# chose to be a general-purpose, multi-paradigmatic language, and I think they met that goal with flying colors.

> Newcomers won't know many DI framework implicit behaviors & conventions until either they shoot themself in their foot or get RTFM'd

The question is: does the DI framework reduce the overall complexity or not? Good DI frameworks are built on a very small number of (yes, "magic") conventions that are easy to learn. That being said, bad DI frameworks abound.

And can you imagine any other industry where having to read a few pages of documentation before you understood how to do engineering was looked upon with such derision? WTF is wrong with newcomers having to read a few pages of documentation!?

> [Donald Knuth] firmly believes that having an unchanged system that will produce the same output now and in the future is more important than introducing new features

This is such a breath of fresh air in a world where everything is considered obsolete after like 3 years. Our industry has a disease, an insatiable hunger for newness over completeness or correctness.

There's no reason we can't be writing code that lasts 100 years. Code is just math. Imagine having this attitude with math: "LOL loser you still use polynomials!? Weren't those invented like thousands of years ago? LOL dude get with the times, everyone uses Equately for their equations now. It was made by 3 interns at Facebook, so it's pretty much the new hotness." No, I don't think I will use "Equately", I think I'll stick to the tried-and-true idea that has been around for 3000 years.

Forget new versions of everything all the time. The people who can write code that doesn't need to change might be the only people who are really contributing to this industry.

It was a concerted and intentional effort to fake data and falsify research into a pervasive deadly disease, specifically in order to hoard funds going to research they knew was, if not a dead end, at least not nearly as promising as they were claiming, preventing those funds from going to other research groups that might actually make progress, essentially stealing donations from a charity, and using their power and clout to attack the reputations of anyone who challenged them. They directly and knowingly added some X years to how long it will take to cure this disease, with X being at least 2 and possibly as much as 10. When Alzheimer's is finally cured, add up all the people who suffered and died from it in the X years before that point, and this research team is directly and knowingly responsible for all of that suffering. Yes, I think I will call it absolutely fucking evil.

ASP.NET MVC came with T4 templates for scaffolding out the controllers and views, which I also came to view as an anti-pattern. This stuff was in the official Microsoft tutorials. I'm really not sure why you think these weren't around?

    public Optional Name;

    class Optional {
      public T? Value;
      public bool IsSet;
    }

    class Optional {
      public IEnumerable ValueOrEmpty;
      public bool IsExplicitNull;
    }

Why mess with source generators? They're just making it slightly easier to do this in a way that is really painful.

I'd strongly recommend that if you find yourself wanting Null to represent two different ideas, then you actually just want those two different ideas represented explicitly, e.g. with an Enum. Which you can still do with a basic wrapper like this. The user didn't say "Null", they said "Unknown" or "Not Applicable" or something. Record that.

    public OneOf Name

https://github.com/mcintyre321/OneOf

I wrote a JsonConverter for OneOf and just pass those over the wire.

I'm seeing some commenters happily adding 1/3 to the exponent of other algorithms. This insight does not make an O(N^2) algorithm O(N^7/3) or O(N^8/3) or anything else; those are different Ns. It might be O(N^2 + (N*M)^1/3) or O((N * M^(1/3))^2) or almost any other combination, depending on the details of the algorithm.

Early algorithm design was happy to treat "speed of memory access" as one of these constants that you don't worry about until you have a speed benchmark. If my algorithm takes 1 second on 1000 data points, I don't care if that's because of memory access speed, CPU speed, or the speed of light -- unless I have some control over those variables. The whole reason we like O(N) algorithms more than O(N^2) ones is because we can (usually) push them farther without having to buy better hardware.

More modern algorithm design does take memory access into account, often by trying to maximize usage of caches. The abstract model is a series of progressively larger and slower caches, and there are ways of designing algorithms that have provable bounds on their usage of these various caches. It might be useful for these algorithms to assume that the speed of a cache access is O(M^1/3), where M is the size of memory, but that actually lowers their generality: the same idea holds between L2 -> L3 cache as L3 -> RAM and even RAM -> Disk, and certainly RAM -> Disk does not follow the O(M^1/3) law. See https://en.wikipedia.org/wiki/Cache-oblivious_algorithm

So basically this matters for people who want some idea of how much faster (or slower) algorithms might run if they change the amount of memory available to the application, but even that depends so heavily on details that it's not likely to be "8x memory = 2x slower". I'd argue it's perfectly fine to keep M^(1/3) as one of your constants that you ignore in algorithm design, even as you develop algorithms that are more cache- and memory-access-aware. This may justify why cache-aware algorithms are important, but it probably doesn't change their design or analysis at all. It seems mainly just a useful insight for people responsible for provisioning resources who think more hardware is always better.