Sean Baxter not only wrote his own C++ compiler, but he authored this magnificent vision paper for the future of C++ that it moved me to reconsider my views on the safety of the language and its use future projects.
Seldom a man of my age and opinions can change his mind over something so fundamental.
Enjoy: https://github.com/seanbaxter/circle/blob/master/new-circle/README.md
@glaurent @Migueldeicaza I think the two are self-reinforcing. We almost never use libraries built with, say, Java, from a C++ project. Or consider calling Python from C#. We never do it because it would suck, so it doesn’t feel important.
Imagine a world where there was a stable powerful cross language interop ABI that let you do those things in a nice easy way. In that world people *would* use languages from other libraries a lot, and interop would be critical.
@borland @Migueldeicaza you won’t use a Java lib in a C++ project because if you picked C++ in the first place, it’s for reasons that most likely preclude from using Java.
Are there really that many libs written in a given language that don’t have an equivalent in any other ? And good luck finding a standard for interop’ing things like asynchronous calls for instance.
@glaurent @Migueldeicaza Idk, it kinda boils down whether this (or similar projects) will be successful or not. GTK can quite nicely embrace the current Rust revolution and also integrates surprisingly well with C#, Qt seems to kind of struggling with C++ becoming more of a clutch than GObject was. It's impossible to migrate Qt away from C++ and crazy hard to use it from say Rust.
Their relevance is tied to the progress of C++, while GTK isn't tied to C. The same story may repeat itself in a few decades perhaps, when GTK may be bound to Rust :-p
That being said, Rust tries to be a living language that doesn't need to be replaced by the same virtue and for the same reasons outlined in the document. Most Rustaceans probably philosophically agree with the document, but don't believe that C++ or its committee is ready for such an evolutionary approach.
@Migueldeicaza This looks like it could be a very interesting low-impact & low-cost way to experiment with language extensions.
This resonates with me:
"I don't want people to have to rewrite anything. Instead, enable one feature at a time and keep at your compile/test cycle until you've resolved any conflicts created by these new "bubbles of code.""
As a user of C++ for 30ish years who is more-and-more frustrated with how complicated the language has become, count me intrigued...
@uliwitness @Migueldeicaza mainstream systems programming languages have allowed piecewise migration from the last one, since otherwise large codebases will not transition. You can embed ASM in C, C in C++ or Obj-C.
I think C++ is so large that it won’t be able to be embedded in any other language than C++. This approach seems very pragmatic
@Migueldeicaza It is really easy for people like me to think of C++ as what it was like a quarter century ago. But modern C++ and the kinds of tooling described there and elsewhere show that there is no reason to discard C++.
I still favor #Rust for new projects, but I agree that a great deal of prejudice against C++ is based on outdated assumptions.
@Migueldeicaza that is very cool. I love this quote in particular:
“There is nothing inherent about software. Software does what it does, and with effort, can be made to do something new.”
The article shows that C++ *can* move in a good direction, but unfortunately I’m pretty confident it *won’t* because all the people in charge are afflicted with that thing where you get used to something and become so invested in it to the point you’re blind to it’s faults.
Well, and he's obsessed with 100% backwards compatibility. As long as you have a bunch of stuff you won't touch, that limits the flexibility and plasticity of software.
Software can be made to do something new, but not in places where you said "no new here, it has to do the bad old thing."
@Migueldeicaza Feature with n bits mean 2^n different dialects of C++ to build into our brains, our IDEs, our linting tools, our debuggers, and so forth. It means 2^n different sets of feature interactions to consider as the language evolves. Editions make some sense, but individual flags maybe not.
There are also a lot of C++ problems that can’t be fixed on a file-by-file basis. Let’s say I want to define away UB entirely. Can I?
It's a fun manifesto. Some of it is a bit silly. For instance, in "Will this cause an explosion of features, and will the C++ community crumble like the Tower of Babel?", all his arguments there apply to JS, which takes constant and gigantic penalties because it's so fragmented, for precisely the reasons he mentions.
He *is*, to a significant degree, opting into those same difficulties.
He also seems to be saying that backwards compatibility with weird stuff should never be a problem for app developers, only toolchain developers.
But that's just not true. You can't just change how, say, bit shifts work because a ton of old code depends on bad old behaviour.
I suppose you could declare bit-shift bankruptcy and create a whole new operator. But you have to avoid the old one at a minimum.
Backwards compatibility is *ugly* here.
David Meikle
Miguel de Icaza ᯅ🍉
Tor Lillqvist
Guillaume Laurent
Orion Edwards
LisPi
lj·rk
./orta therox
Benno
Pxtl
Andy 🌎
Nick Lockwood
Kevin Granade has moved
Carlos Guerreiro
Uli Kusterer (Not a kitteh)
Tom Finnigan
David Mooney
Adam Roach
Roy Triesscheijn
Jeffrey Goldberg
Captain Snowball
plinth
HJVT
Craig
spikebike
Eric Scouten
damageboy
Federico Mena Quintero
Lucas Werkmeister
JLab8
Paul Cantrell
Noah Gibbs
David Jaša
Patrick Reynolds
Martin Du4
Chip Collier
Julia REPL stan 