MaxBarraclough

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.

From https://openjdk.org/jeps/483 :

> 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++.

[0] https://stackoverflow.com/a/58841107

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.

https://en.wikipedia.org/wiki/Modules_(C%2B%2B)

> 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.)

> Concise since you have to review a lot more code

Isn't readability what matters here? Conciseness isn't the same thing.

> OSS licensing. Free Software was designed to avoid this

This is pretty much a distinction without a difference. There are licences that qualify as one but not the other (per the FSF and OSI's determinations), but none are in widespread use.

> When you fork Free Software, your fork is also Free Software.

That would be copyleft. [0] Not all Free Software licences are copyleft licences.

[0] https://en.wikipedia.org/wiki/Copyleft

> Fingerprints are derived from the certificates/private keys

SSH fingerprints are derived from the public key. https://superuser.com/a/453022

The improved register count must make it much less claustrophobic for students. It's not just the same ISA but with wider words.

Looks like I'm mistaken on terminology though. x86 includes the 16-bit, 32-bit, and 64-bit ISAs of that family, and doesn't refer specifically to the 32-bit generation.

Can't imagine anyone teaching x86 assembly these days, did you mean x86-64?

Agreed, it's subtle but it's definitely a form of clickbait-style writing.

Don't forget the Intel floating-point division bug from the 90s.

https://en.wikipedia.org/wiki/Pentium_FDIV_bug

Seems unlikely, migrating away from an entrenched codec like H264 isn't like a routine software update. It has widespread hardware support, and there's an enormous body of H264 video out there.

As fhn points out, there are now truly open video codecs available (open specification, royalty free, unencumbered by patent terms) that are able to compete with the patent-encumbered ones on technical merit. Seems curious that the patent-holders would want to hike prices in this way and validate the motivation behind the truly open codecs.

Also, the article mentions the licensing fees for H265 were also increased recently. It doesn't seem to give a figure, a quick web search turns up 25% [0] or perhaps 20% [1]. Perhaps I'm missing something obvious but I'm not clear on how the change in price relates to the patent dispute between Nokia and certain laptop manufacturers.

(It seems the H264 fee increase affects streaming providers only, whereas the H265 fee increase did not, as it affected laptop manufacturers.)

[0] https://news.ycombinator.com/item?id=46004129

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

> Either way no, that can't work.

Kotlin has explicit nullable types. Rust has no null, but has option types. Both languages work fine.

I think your point was that neither approach could reasonably be retrofitted to C++, do I have that right?

I think it's more than just an echo chamber, it's the community wanting drama more than it wants to help people.

Jonathan Blow's own unreleased Jai programming language has a feature to make it trivial to switch between array-of-structs and struct-of-arrays.

From a quick search, it seems HackerNews's own jcelerier has put together a C++ library for doing this. https://github.com/celtera/ahsohtoa

That's no different from previous developments. If you refuse to work with modern programming languages, or with the web, or with a task-tracker, you're narrowing your opportunities for employment considerably.

That's a rule-of-thumb to help beginners in making judgement calls. It doesn't mean inheritance should never be used.

> That is, after all, what sets "object-oriented" apart from having objects alone.

I wouldn't say so, most object-oriented languages don't work like Objective-C/Smalltalk. Today, I think most programmers would agree that inheritance is the defining feature of object-orientation.

> I’ve been here for a years under different usernames

The guidelines ask that you don't do this. From https://news.ycombinator.com/newsguidelines.html :

> Throwaway accounts are ok for sensitive information, but please don't create accounts routinely. HN is a community—users should have an identity that others can relate to.

I see my phrasing was ambiguous, for what it's worth I'm afraid mike_hearn had it right, I was saying the replication crisis largely just affects research in psychology. I see this was too narrow, but I think it's fair to say psychology is likely the most affected field.

In terms of solutions, the practice of 'preregistration' seems like a move in the right direction.

I've read of a few cases like this on Hacker News. There's often that assumption, sometimes unstated: if a junior scientist discovers clear evidence of academic misconduct by a senior scientist, it would be career suicide for the junior scientist to make their discovery public.

The replication crisis is largely particular to psychology, but I wonder about the scope of the don't rock the boat issue.

That's the point though, it doesn't reflect human usage of the word. If delve were so commonly used by humans too, we wouldn't be discussing how it's overused by LLMs.

Technically correct, but not an issue in practice. If you want a licence that's approved by the OSI but not the FSF, or vice versa, you have to go looking for it. If memory serves there are no licences in the latter category, and the few in the former category are very obscure.

Sounds like the Jevons paradox. From https://en.wiktionary.org/wiki/Jevons_paradox :

> The proposition that technological progress that increases the efficiency with which a resource is used tends to increase (rather than decrease) the rate of consumption of that resource.

See also Wikipedia: https://en.wikipedia.org/wiki/Jevons_paradox

> A programming language is a formal specification language that we know how to compile

Plenty of real programming languages are ambiguous in ways that surely disqualify them as formal specification languages. A trivial example in C: decrementing an unsigned int variable that holds 0. The subtraction is guaranteed to wrap around, but the value you get depends on the platform, per the C standard.

> There are plenty of formal specifications that cannot be compiled, even not by an AI. If you use AI, how do you make sure that the AI compiler compiles correctly?

By proving that the code satisfies the formal spec. Getting from a formal spec to a program (in an imperative programming language, say) can be broken down into several stages of 'refinement'. A snippet from [0] :

> properties that are proved at the abstract level are maintained through refinement, hence are guaranteed to be satisfied also by later refinements.

[0] https://www.southampton.ac.uk/~tsh2n14/publications/chapters...

> A formal specification language is a programming language that we don't know how to compile.

Not really, on both counts.

Firstly they're not really programming languages in the usual sense, in that they don't describe the sequence of instructions that the computer must follow. Functional programming languages are considered 'declarative', but they're still explicit about the computational work to be done. A formal spec doesn't do this, it just expresses the intended constraints on the correspondence between input and output (very roughly speaking).

Secondly, regarding the we don't know how to compile it aspect: 'constraint programming' and SMT solvers essentially do this, although they're not a practical way to build most software.

> It would only work if there's a sizeable, technically-inclined userbase of the project so that someone is likely to have audited the code.

Not really. There's a long history of seemingly credible closed-source codebases turning out to have concealed malicious functionality, such as smart TVs spying on user activity, or the 'dieselgate' scandal, or the Sony rootkit. This kind of thing is extremely rare in Free and Open Source software. The creators don't want to run the risk of someone stumbling across the plain-as-day source code of malicious functionality. Open source software also generally makes it easy to remove malicious functionality, or even to create an ongoing fork project for this purpose. (The VSCodium project does this, roughly speaking. [0])

Firefox's telemetry is one of the more high-profile examples of unwanted behaviour in Free and Open Source software, and that probably doesn't even really count as malware.

> If you're malicious, you can still release malicious software with an open-source cover (ideally without the source including the malicious part - but even then, you can coast just fine until someone comes along and actually checks said source).

I already acknowledged this is possible, you don't need to spell it out. Again I don't have hard numbers, but it seems to me that in practice this is quite rare compared to malicious closed-source software of the 'ordinary' kind.

A good example of this was SourceForge injecting adware into binaries. [1]

> Remember that the xz-utils backdoor was only discovered because they fucked up and caused a slowdown and not due to an unprompted audit.

Right, that was a supply chain attack. They seem to be increasingly common, unfortunately.

[0] https://vscodium.com/

[1] https://en.wikipedia.org/wiki/SourceForge#Installer_with_adw...

> Open source is not synonymous with the GPL and most businesses try to avoid open source software when implementing their core competency.

What you mean here? Businesses often implement their own core code, but they don't deliberately favour closed-source software.