Actually setting up a robust system for perf regression tests is tricky though...

Outside of coding, the top models still fall flat on their face when faced with relatively simple knowledge work. I got completely bogus info on a fairly simple tax question just a few days ago for example, and anyone using AI regularly with any discernment runs into simple failures like this all the time. It's still useful but the idea that we're on some trajectory to exceeding top human performance across all domains seems completely unrealistic when I look at my experience of how things have actually been progressing.

Minor correction though, I think this is not quite correct:

> The compiler computes the required size at compile time by summing the sizes of all locals (accounting for alignment).

In optimized C++ builds, compilers can reuse stack storage for locals whose live ranges don’t overlap, so the required stack frame size is not necessarily the sum of all locals. Some locals may never have stack storage at all (e.g. living entirely in registers or being optimized away).

For objects with non-trivial destructors, storage reuse is constrained by object lifetime and destruction semantics, but the same stack slot may still be reused after the destructor has run.

The semantics of pass by const reference are also not exactly the same as pass by value in C++. The compiler can't in general assume a const reference doesn't alias other arguments or global variables and so has to be more conservative with certain optimizations than with pass by value.

F# in the visual studio debugger does a pretty good job of this in recent versions.

The SPEs were a different instruction set with a different compiler tool chain running separate binaries. You didn't have access to an OS or much of a standard library, you only had 256K of memory shared between code and data. You had to set up DMA transfers to access data from main memory. There was no concept of memory protection so you could easily stomp over code with a write to a bad pointer (addressing wrapped so any pointer value including 0 was valid to write to). Most systems would have to be more or less completely rewritten to take advantage of them.

Multiplayer games too.

- Pattern matching (arguably a more flexible and general way to do the type of thing you have in your number 4 if syntax)

It seems like this is actually an elegant typed functional language but the Python syntax looks ugly and verbose and like it's trying to hide that compared to something more ML/F# or Haskell inspired.

I'll try and get past that though as it does look like there's something pretty interesting here.

Transitioning existing code to use modules is also not entirely straightforward, though probably no more problematic than introducing unity builds.

The equivalent code in C++ has different semantics but a function that takes a non const reference in C++ cannot change what the reference refers to (references are immutable in that sense in C++, they can only ever refer to one object). What a non const reference allows in C++ is for the called function to change the value of the object referred to and since strings are not immutable in C++ that means that the value of string s could change, not the object identity.

With pointers to pointers, or references to pointers in C++ you can further change the object pointed to / referred to but not with references (there's no such thing as a reference to a reference in C++).

In C++ passing a pointer by value is effectively the same as passing a reference, the only real difference being that the syntax for accessing the underlying value is more implicit for a reference.

I still see even relatively experienced programmers who don't understand this, particularly working with Unity where a lot of programmers came from C++ to C# and don't realise for example that a C# function that takes a List 'by value' and modifies it is actually modifying the same instance that was passed in by the caller.

Examples are usually something like having a base entity, a player that inherits from entity and an enemy that inherits from entity. Then you have a magic user and a barbarian inherit from enemy but now you also want your player to be able to use magic. Traditional OOP doesn't make it easy to share the implementation.

Even with composition and interfaces you still have problems with most traditional OOP languages when you want to do things like change the set of components of an entity dynamically at runtime (player gains or loses the ability to use magic during the game).

"Is a" is often not the relationship you want to model. A player and an NPC both have the "has a" relationship to an inventory, not the "is a" for example.