Agreed. The quality of a software package doesn't change when its last user stops using it. We don't say that the Apollo Guidance Computer software is of low quality these days given that nobody's using it.
Software quality is, roughly speaking, intrinsic to a software product. Its usefulness is not intrinsic, it can depend on any number of external factors. Quality is not the same as usefulness.
I'm not sure about that definition. If your software solves a problem that many users face, that makes it useful and, presumably, valuable, but it doesn't mean it's of higher quality than niche software of relatively little use.
I recommend his recent appearance on the Inside Java podcast, where these topics are explored well. The episode is number 59, titled Java *is* Memory Efficient.
> There is no possible way even in theory for a GC to outperform schedule-aware allocation from a fixed pool.
You mean in the absence of any reference-counting overhead? That doesn't sound like a fair comparison.
> In most cases the GC is just generic C++ code anyway; that indirection is unnecessary.
You can't use the JVM's GCs from C++. C++ heavily relies on RAII, so it doesn't seem like a good fit anyway. I'm not aware of any serious efforts at a high performance GC for C++.
As Herb Sutter points out, moving GCs require non-stable pointers, which C++ isn't suited to. [0]
> the schedulers require predictable execution at ~1µs granularity for throughput optimization purposes, which is difficult to guarantee in Java
Can't say I know much about that kind of issue, how does it work in C++ code?
> all the post-quantum algorithms implemented by OpenSSH are "hybrids" that combine a post-quantum algorithm with a classical algorithm. For example mlkem768x25519-sha256 combines ML-KEM, a post-quantum key agreement scheme, with ECDH/x25519, a classical key agreement algorithm that was formerly OpenSSH's preferred default. This ensures that the combined, hybrid algorithm is no worse than the previous best classical algorithm, even if the post-quantum algorithm turns out to be completely broken by future cryptanalysis.
> DbC is the Policy (i.e. what/why) and Asserts are the Mechanism
The ideal way to do runtime-checked DbC is not with simple asserts, it's with proper first-class preconditions and postconditions at the language level.
It wouldn't be nice to have to manually ensure that both old and new states of variables are in-scope for postcondition checking. I can imagine that being not just tedious, but error-prone.
> An Assert merely validates the state of a program at a particular point during execution.
Some aspect of the program's state, yes, and hopefully that's all it does.
Interesting to think about the edge-cases here though. Depending on the language, it could accidentally side-effect, or even invoke undefined behaviour, and so actively derail the program. Can't blame DbC for that though, that's a question of language safety.
> You use it to steer the program to go through only the correct subset of the state space of the program
I'm not sure I follow here. You don't use asserts to steer flow-control, you use them to check aspects of program state.
> You could do this pre/post every executable statement (i.e. write proof of correctness)
That doesn't constitute a proof of correctness, no more than last time you and I discussed this. [0] Depending on the language, it wouldn't even necessarily prove the correctness of that particular trace, as you haven't proven that you haven't accidentally invoked undefined behaviour.
You hold a minority opinion on this, please stop presenting it as settled fact.
> The point is that when using asserts you think about correctness w.r.t. specifications and nothing else. To think of it as simply validating arguments or in terms of effects on optimization is quite the wrong thing to do.
I'm not sure why you'd think I don't already know that.
> Apparently signed integer overflow UB helps with loop optimizations because it makes it easy to prove the loop always terminates
I tried googling but couldn't find hard numbers on the performance impact of GCC's -fwrapv flag. As you'd imagine, it forces wrapping for overflowing arithmetic on signed integer types. [0]
I also have to wonder how instructive that would be anyway. The GCC devs presumably don't prioritise the performance impact of that flag. If the C language mandated it, they might find other ways to achieve similar optimisation.
This page [1] looks at the related flag for trap-on-signed-overflow, and found an impact of very roughly 6%.
See also: John Regehr's posts on this topic. [2][3] He dislikes Java's implicit wrap behaviour, as it's rarely what the programmer wants to happen. Java programmers almost never use the addExact method, [4] as it's so syntactically clumsy.
> surely it's UB because some systems trapped on overflow, or produced different results due to using 1's complement, and the optimization side of the rule was a happy accident
Per this StackOverflow answer [5] I think you have it right.
> It's worse than that, the behavior of the entire program is unconstrained by the language standard beforehand too. Raymond Chen discusses how things can go wrong once you're going to reach UB even before you get to it
Heh, yes that's exactly what I was thinking when I put roughly speaking.
> where a kind C compiler might just mess with your numbers a bit, an evil C compiler can legally make demons fly out of your nose
Yes, signed integer overflow being another. Presumably it's defined that way as it's simpler than trying to spell out all the behaviours the compiler is permitted to implement, and on top of that there are trap representations to worry about. I doubt modern compilers get much optimization benefit from it though. There's a StackOverflow thread discussing the reasons it's defined this way: https://stackoverflow.com/q/1860461
> The fact that the ordering of those more primitive operations with respect to other operations isn't very tightly constrained is something you'd just have to know about the language, I suppose.
No, that's not right. It's undefined behaviour, not merely an unspecified order of evaluation. Roughly speaking, the behaviour of the entire program is unconstrained by the language standard after execution of that statement. It could crash the whole process, for instance, or go haywire.
That isn't a strong answer, unless the question was about what you think of the code's style. The point is that it's more than just poor style, it's likely to constitute undefined behaviour. Saying different compilers could interpret the expression differently is not equivalent to saying it invokes undefined behaviour.
It's common for interview questions to explore unusual code, perhaps poor quality code, that hinges on edge cases of the language. A candidate with a strong understanding of the language would be expected to take the opportunity to demonstrate it.
You might be interested in OpenJDK's new ability to 'cache' classes to accelerate class loading. JEP 483: Ahead-of-Time Class Loading & Linking. It doesn't persist code generated by the JIT, but can improve startup time appreciably.
> This program runs in 0.031 seconds on JDK 23. After doing the small amount of additional work required to create an AOT cache it runs in in 0.018 seconds on JDK 24 — an improvement of 42%.
> Having an understanding of how the code gets transformed into machine code helps
I'm not sure about that. Knowing assembly is not a substitute for knowing how the language is defined. Sometimes C/C++ programmers with some assembly knowledge reason themselves into thinking that what they're asking of the language must have well-defined behaviour, when in fact it's undefined behaviour. It doesn't really matter whether interleaving order can change the output. (++i)++ is, apparently [0], undefined behaviour in C but has well defined behaviour in C++.
I've not been diligently keeping up with C++ recently but there's a C++20 feature called modules. Per Wikipedia, they're somewhat like precompiled headers.
> If they cheat in classes, they are really just cheating themselves, and this should be no concern to the staff.
This is quite plainly not the case. If curve grading is used, cheating directly harms other students who aren't cheating. If curve grading isn't used, the university may end up handing out high grades like candy, and that's a problem for the university.
Higher grades can translate to better career outcomes even if undeserved. If it were clear that this wasn't the case, nobody would cheat in the first place.
Strong typing is not a synonym for static typing, it refers to a different aspect of type safety.
Static typing is, roughly, where variables and expressions have fixed types that can be determined ahead of execution. Strong typing means the language doesn't offer implicit type conversions. Python is dynamically typed, i.e. not statically typed, and strongly typed. (Ignoring its type annotations feature, of course.)