If this doesn't happen, are you going to accept that you were wrong, or are you going to ignore it and be off spreading unfounded anger about some other imagined offense?
Readit Newsfeoren commented on Zohran Mamdani wins the New York mayoral race nbcnews.com/politics/elec... · Posted by u/jsheard
feoren commented on Dating: A mysterious constellation of facts dynomight.net/dating/... · Posted by u/tobr
Please don't use HN for ideological battle like this. https://news.ycombinator.com/newsguidelines.html
Anyone can decide a statement is "ideological" just by disagreeing with it. The statement "the government can and should provide services to its people if those services are important to its future and the free market is incapable of providing them" should not, and did not used to be, ideological. The fact that such a statement is far outside of the current Overton Window is the result of a decades-long propaganda campaign to destroy everyone's faith in government so it can be looted, and everyone who parrots "government bad" is (knowingly or not) playing a part in this propaganda campaign. I assume the issue you have with my comment is that I knew 95% of readers would immediately regurgitate "but government bad!", but of course I was right that that happened.
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.
Dead Comment
feoren commented on John Carmack on mutable variables twitter.com/id_aa_carmack... · Posted by u/azhenley
It also doesn't make sense for `process()` to be an attribute of `result`. Why would you instantiate a class and call it result‽
> Why would you instantiate a class and call it result‽
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.
feoren commented on Tinkering is a way to acquire good taste seated.ro/blog/tinkering-... · Posted by u/jxmorris12
I think the author has a point, but his examples are bad. He talks about mouse sensitivity, windows manager, keyboard switches, and vscode. All those things were made to be tweaked. He's not so much exploring as he is playing with a toy the way it was intended. The stickiest learning comes from getting things wrong, and that happens when you're using things the way you're not supposed to. For example disassembling a microwave. Not the keyboard switches.
The world has become so comfy that even tweaking has been packaged and monetized by some company. That's right, I'm gatekeeping tweaking, sue me.
> For example disassembling a microwave
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.
feoren commented on Python 3.14 is here. How fast is it? blog.miguelgrinberg.com/p... · Posted by u/pjmlp
> When mathematical notation evolves, old proofs do not become obsolete! There is no analogy to a "breaking change" in math.
I disagree. The development of non-euclidean geometry broke a lot of theorems that were used for centuries but failed to generalize. All of a sudden, parallels could reach each other.
> 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?
We could, the problem is everyone disagrees on what that core should be. Should it be memory-efficient? Fast? Secure? Simple? Easy to formally prove? Easy for beginners? Work on old architecture? Work on embedded architecture? Depending on who you ask and what your goals are, you'll pick a different set of core features, and thus a different notation for your core language.
That's the difference between math & programming languages. Everyone agrees on math's overall purpose. It's a tool to understand, formalise and reason about abstractions. And mathematical notation should make that easier.
That being said, the most serious candidate for your "core language guaranteed not to change and that you can build onto" would be ANSI C. It's been there more more than 35 years, is a standard, is virtually everywhere, you can even write a conforming compiler for a brand new architecture, even an embedded microchip very easily, and most of not all the popular languages nowadays are build on it (C++ of course, but also C#, java, javascript, python, go, php, perl, haskell, rust, all have a C base), and they all use a C FFI. I'm not sure ANSI C was the best thing that ever happened to our industry, though.
> Should it be memory-efficient? Fast? Secure? Simple? Easy to formally prove? Easy for beginners? Work on old architecture? Work on embedded architecture?
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.
feoren commented on Python 3.14 is here. How fast is it? blog.miguelgrinberg.com/p... · Posted by u/pjmlp
> This is such a breath of fresh air in a world where everything is considered obsolete after like 3 years.
I dunno man, there's an equal amount of bullshit that still exists only because that's how it was before we were born.
> Code is just math.
What?? No. If it was there'd never be any bugs.
> > Code is just math.
> 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.
feoren commented on Python 3.14 is here. How fast is it? blog.miguelgrinberg.com/p... · Posted by u/pjmlp
> There's no reason we can't be writing code that lasts 100 years. Code is just math.
The weather forecast is also “just math”, yet yesterday’s won’t be terribly useful next April.
No, weather forecasting models are "just math". The forecast itself is an output of the model. I sure hope our weather forecasting models are still useful next year!
weather forecasting models <=> code <=> math
weather forecast <=> program output <=> calculation results
feoren commented on Python 3.14 is here. How fast is it? blog.miguelgrinberg.com/p... · Posted by u/pjmlp
> 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.
Not sure this is the best example. Mathematical notation evolved a lot in the last thousand years. We're not using roman numerals anymore, and the invention of 0 or of the equal sign were incredible new features.
> Mathematical notation evolved a lot in the last thousand years
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.
feoren commented on Python 3.14 is here. How fast is it? blog.miguelgrinberg.com/p... · Posted by u/pjmlp
> There's no reason we can't be writing code that lasts 100 years. Code is just math
Math is continually updated, clarified and rewritten. 100 years ago was before the Bourbaki group.
> Math is continually updated, clarified and rewritten
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.