Kranar

That's a misinterpretation of what the article says. There is no actual bound in principle to what can be computed. There is a fairly practical bound which is likely BB(10) for all intents and purposes, but in principle there is no finite value of n for which BB(n) is somehow mathematically unknowable.

ZFC is not some God given axiomatic system, it just happens to be one that mathematicians in a very niche domain have settled on because almost all problems under investigation can be captured by it. Most working mathematicians don't really concern themselves with it one way or another, almost no mathematical proofs actually reference ZFC, and with respect to busy beavers, it's not at all uncommon to extend ZFC with even more powerful axioms such as large cardinality axioms in order to investigate them.

Anyhow, just want to dispel a common misconception that comes up that somehow there is a limit in principle to what the largest BB(n) is that can be computed. There are practical limits for sure, but there is no limit in principle.

This is true in general for every mathematical proof in ZFC (and even in more powerful theories). The decision problem "Given a formula F and an integer n, is there a ZFC proof of F of length <= n?" is NP complete, meaning that verifying the proof can be done in polynomial time while deriving the proof can require an exponential amount of time.

Plenty of companies have gone bankrupt or lost a great deal of credibility due to a single bug or single failure. I don't see why CrowdStrike would be any different in this regard.

The number of bugs/failures is not a meaningful metric, it's the significance of that failure that matters, and in the case of CrowdStrike that single failure was such a catastrophe that any claims they make should be scrutinized.

The fact that we can not scrutinize their claim in this instance since the details are not public makes this allegation very weak and worth being very skeptical over.

Being granted a patent does not make it enforceable. Prior art is a defense against patent litigation.

Clang modules are nothing like what got standardized. Clang modules are basically a cleaned up and standardized form of precompiled headers and they absolutely speed up builds, in fact that is primarily their function.

Visas can come with a bunch of rules attached to them about what you can or can't do in the host country, and those rules can get kind of tricky to properly interpret.

New virtual methods, yes.

It's not a problem here as it has nothing to do with this to begin with. I am pointing out a limitation in a feature that the author has presented, but that feature does not resolve anything about the topic being discussed.

The goal isn't to allow a new type to work for an existing implementation of a function nor is it to take an existing type and write a new function that works with it. In the proposed solution you have `some_function` and the author claims that this solves the expression problem because you can take a new type C and pass it into some_function. Pretty much every language has a way to define new types and pass them into existing functions.

The goal is to allow for that new type, C, to have its own implementation of `some_function` that is particular to C, as well as the ability to write new functions that can be specialized for existing types. In particular we want calls to `some_function` through an interface to call C's specific implementation when the runtime type of an object resolves to C, and calls whatever other implementations exist when called through another interface.

The author's solution doesn't do that, it literally does nothing that you can't do in pretty much any other language.

Virtual methods and overloading are not the same thing.

You are likely mixing up the term overload with the term override.

And what exactly do you think traits apply to types exactly?

If your answer doesn't start with an "m" and end with a "ethod", then you may need to re-read the Rust book found here:

https://doc.rust-lang.org/book/ch10-02-traits.html

While this has nothing to do with the expression problem, it's worth noting that in any case your solution does not work in general.

Rust does let you impl traits for types or traits that are inside of your crate, so your example strictly speaking works, but it does not let you impl traits if both the type and the trait are not inside of your crate. This is known as the orphan rule:

https://doc.rust-lang.org/reference/items/implementations.ht...

As the article points out, the expression problem itself is pretty simple to solve for code that you control, it's when writing modular software that can vary independently that gives rise to issues.

C++ lets you inherit from multiple classes as well. I don't see how this has anything to do with being able to add new methods to existing types.

Classes in C++ have methods too.

The problem is that you can't add new methods to an existing class.

>I don't understand what problem the author is trying to solve here - maybe it's language specific? More related to dynamic typing and efficient dispatch?

The expression problem only arises in statically typed programming languages, it does not exist in dynamically typed programming languages.

Operating overloading has nothing to do with the problem and can not be used to resolve it. Operators are nothing more than a one-off syntax so we can use familiar childhood notation like a + b, etc... they are not particularly meaningful. The ability to overload operators or functions in general is also irrelevant since such overloads are resolved statically at compile time.

Nothing you mention is related to this article and neither Rust or C# solve the expression problem.

The expression problem is about being able to extend both data types (new cases) and operations (new functions) without modifying existing code while preserving static type safety.

C#'s extension methods can't be virtual, so you can't use them to actually add any new operations which can be dispatched on. They're just syntactic sugar for adding static methods which in non-OOP languages can be accomplished by declaring a free function.

Rust traits let you add new types (just impl the Trait), but it doesn't let you add new functions, so it doesn't do anything to solve the problem.

The committee very politely showed him the door.

>For example if you have a nested class that you want to use in an unordered_set in its parent class then you just can’t do it because you can’t put the std::hash specialization anywhere legal.

This is not true. From within your parent class you use an explicit hashing callable, and then from outside of the parent class you can go back to using the default std::hash.

The result looks like this:

    struct Foo {
      struct Bar {};
      struct BarHasher {
        std::size_t operator ()(const Bar&) const noexcept;
      };
      std::unordered_set<Bar, BarHasher> bar_set;
    };

    namespace std {
      template<>
      struct hash<Foo::Bar> {
        std::size_t operator()(const Foo::Bar& b) const noexcept {
          return Foo::BarHasher()(b);
        }
      };
    }

The std::hash specialization at the end is legal and allows other users of Foo::Bar to use std::unordered_set<Foo::Bar> without needing the explicit BarHasher.

There is a version of C++ that adds complete memory safety to the language by adding features to the language in a way that preserves complete backwards compatibility with existing C++ source code. That version of C++ is called Circle/Safe C++, it represents a monumental amount of effort that was written by a single individual, and it's a complete disgrace that the C++ committee has informally shut the door on that individual:

https://safecpp.org/draft.html

Safety profiles don't exist and there are so many issues with them that it's unlikely they will ever get added to the language. For example, you mention how it's a method applied to a source file, but C++ doesn't have the concept of a source file, it only knows about translation units.

But then the problem becomes where exactly do you opt-in to this feature? If you do it in a header file then this can result in a function being compiled with the safety profile turned on in one translation unit and then that exact same function is compiled without that safety profile in another translation unit... which ironically results in one of the most dangerous possible outcomes in C++, the so-called ODR violation.

If you don't allow safety-profiles to be turned on in header files, then you've now excluded a significant amount of code in the form of templates, constexpr and inline functions.

Risks for both contact lenses and LASIK are incredibly low, but with that said strictly from a quantitative perspective, contact lenses carry a higher risk of permanent vision loss than LASIK. The issue is that the risk of LASIK is almost entirely front-loaded whereas the risk from contact lenses causing an infection that results in significant to total loss of vision accumulates little by little.

C++ compilers are not required to be deterministic and in practice are not, at least as far as "same source code produces same observable behavior". Things that can introduce non-determinism include the order in which symbols are linked, static variable initialization, floating point operations (unless you use strict mode, which is not mandated by the standard), and this is ignoring the obvious stuff like unspecified behavior which is specifically defined as behavior which can differ between different runs on the same system.

Also correctness guarantees? Hahaha... I'll pretend you didn't just claim C++ has correctness guarantees on par with other languages, LLVM or otherwise. C++ gives you next to nothing with respect to correctness guarantees.

>Then why are they so deserted most of the time?

What general age range are you? I ask because before COVID, The PATH in Toronto was absolutely packed and incredibly busy. Nowadays it's true that the PATH has far fewer pedestrians but that's because of people working from home, a situation which is likely to come to an end by the end of next year with most of the financial district mandating a return to office.

>You can think of it as good or bad, but I see little reason to exaggerate so comically about the deadly dangers of Scary Toronto Winters, and how they necessitate separating oneself from the outdoors at all costs.

There are quantifiable metrics about extreme weather conditions in Toronto that are tracked by the City of Toronto's Public Health Unit, so we don't need to speculate about this issue:

https://www.toronto.ca/city-government/data-research-maps/re...

For various reasons, the number of extreme cold weather alerts, defined as periods where the temperature drops to below 30 degrees Celcius, has increased quite significantly in the past 20 years with 2022 having a record of 49 days. Considering winter is only 90 days a year, having more than half of those days resulting in extreme weather alerts absolutely qualifies as unsuitable for outdoor pedestrian travel.

Concentrated wealth along with a lack of currency circulation results in deflation, not inflation:

https://en.m.wikipedia.org/wiki/Velocity_of_money

Pretty ironic that you'd call out economic chops when this is a very basic and well understood principle. Perhaps be more cautious and less confident in your presuppositions going forward.

The presentation you are making is both incorrect and highly misleading.

There are algorithms whose correctness depends on sequential consistency which can not be implemented in x86 without explicit barriers, for example Dekker's algorithm.

What x86 does provide is TSO semantics, not sequential consistency.

The concept of sequential consistency only exists within the context of a programming language's memory model. It makes no sense to speak about the performance of sequentially consistent operations without respect to the semantics of a programming language.

It's a common misconception to reason about memory models strictly in terms of hardware.

Sequential consistency is a property of a programming language's semantics and can not simply be inferred from hardware. It is possible for hardware operations to all be SC but for the compiler to still provide weaker memory orderings through compiler specific optimizations.

You need it to avoid a use after free.

Yes exactly, imagine a function HH(n) that returns 0 if the Turing machine represented by the integer n halts, and 1 if it doesn't.

Then HH the function itself is not computable, but the numbers 0 and 1, which are the only two outputs of HH are computable.

Integers themselves are always computable, even if they are the output of functions that are themselves uncomputable.

Yes BB(n) is always a natural number which is by definition finite.

What specifically doesn't sound right?