Time-Traveling to 1979: Advice for Designing 'C with Classes

The best advice is probably "don't", as it usually is to most people setting out to design a programming language, and even more so for people setting out to do a mostly backwards compatible extension to a language that isn't suited for what you want it to do.

The second best advice is probably, do just c with classes. Allow defining your own allocator to make objects of those classes. It's fine if objects built with one allocator can only refer to objects built by the same one.

Don't do templates, just do the minimum needed for a container type to know what type it contains, for compile time type checking. If you want to build a function that works on all numbers regardless if they are floats or complex or whatever, don't, or make it work on those classes and interfaces you just invented. A Float is a Number, as is an Integer. Put all that cleverness you'd waste on templates into making the compiler somewhat OK at turning that into machine types.

Very specifically don't make the most prominent use of operator overloading a hack to repurpose the binary left shift operator to mean `write to stream`. People will see that and do the worst things imaginable, and feel good about themselves for being so clever.

I have no doubt that had this happened nothing would have changed. C++'s legacy is that every positive incremental change is implemented at the last possible moment and in the most frustrating and caveat-laden manner.

The individual merits of language features hold relatively little value compared to the sausage making machine that is the C++ language evolution process.

I really am curious why the article goes with just implementing Templates early. If the question is going back from today (or even 2013 as the year for Bjarne giving the question to his class) why would someone recommend templates when typed polymorphic datatypes constructors are a more sound method for implementing ‘generics’ (also easier to produce sensible error messages)?

Also, why go with constexpr as a replacement (which is not as expressive unless I have badly misunderstood how they work) for pre-processor macros. There have been type-safe and sound implementations of macros, along with explicitly staged computations, since the early 2000’s, why would that not be more preferable?

I think the article is a fun thought exercise, but i think it attempts to stick too closely to what C++ has become in our timeline and ignored better alternatives that if explained and implemented at the outset would result in a language that retained the performance and abstraction characteristics of C++ as it is today but would place it on sound foundation for further evolution as the language adapts to changes in the industry at large.

What'd I tell to Bjarne:

- In the future, you'll carry in your pocket a computer more powerful than the sum of all computers currently present at the university

- The unchecked flat memory model of C will cause numerous security issues with sometimes grave consequences in the "real world"

- Follow the design of Standard ML (SML) and adapt it to systems programming (yeah, it appeared in 1983, but surely papers have been published before that)

- Do not even think about using unsigned types for sizes and get rid of implicit numeric conversions: if (v.size() - 1 < 0) fails on empty vector in today's C++

- Deterministic resource management is still important and is _the_ feature that C++ gets praised for.

- Lack of standard ABI will cause a lot of headaches and lost time.

- I would tell him about LLVM IR, .NET assemblies, metadata and encourage him to first standardize an intermediate format which the compiler could read and write. That'd ensure seamless interoperability between compilers and even other languages.

- Related to the above point: the header/source split will become a burden.

In 1979 the “standard practice in C of passing a large struct to a function” wasn’t just not standard practice, it didn’t exist!

All you could pass as a parameter to a function were pointers to structs. In fact, with one exception, all parameters to functions were basically a machine word. Either a pointer or a full size int. Exception were doubles (and all floating point args were passed as doubles).

Hmm..maybe two exceptions? Not sure about long.

The treatment of structs as full values that could be assigned and passed to or returned from functions was only introduced in ANSI C, 1989.

And of course the correct recommendation to Bjarne would be: just look at what Brad is doing and copy that.

I can't see this title without recommending the move Time After Time, starring Malcolm McDowell and Mary Steenburgen.

The plot is based on the premise that H.G. Wells actually invents a time machine, and it's used by Jack the Ripper to travel to 1979 San Francisco.

It's super weird to say that we need rvalue references. rvalues with their odd semantics are only needed so that they don't break compatibility with the current reference/temporary rules. Instead passing object by move should be built into the language - each class should be moveable by default with proper support in the language

In 1979, the industry needed ‘C with Classes’. It did not need whatever is required today. Hence the only viable path is the one we’re on. Counter point - who is using Pony (the programming language) today? No one.