Amen. The syntax just kept getting more and more complicated. I gave up in the late 1990s. Ironically for this post, I now prefer to write everything in Clojure. It seems like my own journey has paralleled Rich’s journey. Maybe that’s why I appreciate so many of the design choices in Clojure. It’s not perfect, but it’s really, really good.

A sentence from the article: "Given the extreme undesirability of any new language features I'd hardly propose bound-pointers now."

It shows that C++ was considered too complex already in the 90s.

I also use C++ as "C with classes," however I will concede that many of the modern C++ additions, particularly around templating, are extremely convenient. If you haven't had a chance to use requires, concepts, "using" aliases, etc I'd recommend giving them a try. I don't reach for those tools often, but when I do, they're way nicer than whatever this article is demonstrating from 1994! Oh yeah, also lambdas, those are awesome.

I dunno, I skimmed the article's 31 year old code examples and immediately thought they would be shorter and simpler in c++11 or later.

But it's important to see the 1994 (and 1998) view of the world to understand how modern c++ features work. Because they start from that worldview and start adding convenient stuff. If you don't understand how c++ used to work, you may be confused with why c++ lambdas look so weird.

>ugly mess

That may be the case, but there are plenty of examples of elegant implementations.

JUCE, for instance:

    #include <juce_core/juce_core.h>

    class MyComponent {
    public:
        void doAsyncOperation(std::function<void(int)> callback) {
            // Simulate async work
            juce::MessageManager::callAsync([callback]() {
                callback(42); // Call the functor with result
            });
        }
    };

    // Usage
    MyComponent comp;
    comp.doAsyncOperation([](int result) {
        juce::Logger::writeToLog("Callback received with: " + juce::String(result));
    });

.. I think that's kind of clean and readable, but ymmv, I guess?

No member function templates, no variadic templates, no std::function, no lambdas, etc. That's certainly not the kind of C++ I would want to write...

You can just use the parts you want though; that's part of its appeal.

> I may use a third party std::function that doesn't have the weird copy semantics though

Note that C++23 brings std::move_only_function if you're storing a callback for later use, as well as std::function_ref if you don't need lifetime extension.

https://en.cppreference.com/w/cpp/utility/functional/move_on...

This paper is about the idea that eventually became std::function.

> Red flags for me when I see nonstandard functors in a c++ codebase

Even if it's 1994???

Can you elaborate on your third point? What would a class need to do to affect debugging info?

Regarding your fourth point, sometimes an architecture can be vastly simplified if the source of information can abstracted away. For example, invoking a callback from a TCP client, batch replay service, unit test, etc. Sometimes object oriented design gets in the way.

To your first point, I think RAII and architecture primarily address this. I'm not sure that I see callback implementation driving this. Although I have seen cancellable callbacks, allowing the receiver to safely cancel a callback when it goes away.

The only "standard" in 1994 was the C++ARM book (filled a similar role to the K&R C book) that served as basis for the ongoing standardization process, to be done in 1998.