7 ms·
I find the combination of 1) C++, 2) a goal of "Code that is simple and easy to read, understand, and write", and 3) a non-goal of backwards compatibility, to b
by SiVal 6y ago
I find the combination of 1) C++, 2) a goal of "Code that is simple and easy to read, understand, and write", and 3) a non-goal of backwards compatibility, to be strange.
The reason C++ is the federal tax code of programming languages is that it is the accumulation of decades of ideas that seemed good at the time--some even were--where each better way to program ended up as the lifeblood of some special interest group that can never be removed, only piled on top of.
By subsetting C++, you can customize it into almost anything you want with just a few exceptions. You can't meaningfully simplify it in a backwards compatible way without breaking most subsets.
So these people are saying it should be simplified in a non-BC way, the only real way to do it, that preserves their own favored subset.
That's what most of us call a new programming language. Trying to turn C++ into !C++ guarantees they'll be fighting over this for years. With the resources Google has, I don't understand why they don't just throw off all C++-based constraints and use those years to create exactly what they need. With half the PL PhDs on the planet in their employ, you'd think somebody would be available. (Maybe even enough for multiple, parallel teams req'd to share ideas with each other.) It would take a few years to mature enough to rely on, but they'd be spending those years in the C++ cmte debates anyway. A new language called "non-BC C++" will need new tools, new libs, etc., anyway, and they'll have the current C++ to keep using until their alternative is ready.
Why not just create that simple, easy, customized-for-server apps language from scratch instead of making it by breaking C++?
- hsaliak 6y agoIt’s called Go. The downside of having half the Pl PhDs on the planet in their employ is that they can not come to an agreement.
- krferriter 6y agoOr for systems coding and performance-critical work, Rust.
- Athas 6y agoWhile I agree that Rust has advantages for performance-critical work, I don't think "systems" implies performance criticality. In the Unix tradition, "systems programming" seems to be a slightly blurry term for writing the basic tools that come with the system, not necessarily just the kernel and such. I think the term is supposed to be in contrast to "scripting", but I'm not sure the duality is that strong. For example, USENIX '91 had a paper "Awk As A Major Systems Programming Language", which implies that implementing tools such as 'nroff' (one example used in the paper) counts as "systems programming".
- gumby 6y agoBTW the term “systems programming” predates Unix. While I first encountered it through Multics I believe it’s actually an IBM or Burroughs term from the early 60s.
- jacoblambda 6y agoHmm, interesting. I've only ever heard of systems programming referring to bare metal or close to bare metal programming. i.e. embedded software, kernel-space, or otherwise hardware adjacent programming areas.
- kator 6y agoIn 1991 there was a very distinct job called system administrator and the really high skilled ones wrote all sorts of system administration tools in awk, Perl, Shell, and sometimes in C. This to me was 'systems programming' for the administration, deployment, automation, and management of the 'systems'. This was in contrast to "developers" who wrote application code in numerous languages COBOL, Pascal, Fortran, BASIC, etc. And they in general, did not manage the underlying system. Over the years I think those lines have blurred and the roles are all smashed together sometimes called devops or other terms.
- Athas 6y agoYes, this is close to what I'd also prefer to be my definition. "Systems programming" is about writing the programs that users don't care about. This involves all kinds of infrastructure: certainly the kernel, but also various other bits of critical plumbing. But that doesn't fit the definition from that Usenix paper, as nroff was an important user-visible application program, even if it isn't much anymore. I think it is probably best to avoid using the term "systems programming" except when within a constrained community where the intended meaning is clear. Just look at how much confusion arose from the original announcement that Go was a systems programming language!
- apta 6y agoThe people who designed golang did not have PhDs in PL. They were not even PL designers to begin with, and it shows at how poorly designed it is. (And no, one person who happened to work on C doesn't count, since language design evolved a lot since then). Incidentally, golang did not end up replacing C++ or Java in the slightest, especially at Google. It is in the same space as python.
- platinumrad 6y agoI have criticisms of Go too, but your statement is factually incorrect. Robert Griesemer did a PhD under Niklaus Wirth.
- apta 6y agoThanks for the information, I didn't know that. It just make it weirder how the language turned out. Perhaps he didn't influence the initial design enough?
- jfkebwjsbx 6y agoHaving a PhD on a field does not automatically imply you can produce good results, specially if targeted for widespread consumption. It is actually very rare when that happens. I am not saying that is the case here one way or the other, though.
- danielscrubs 6y agoUnder Niklaus Wirth nonetheless, that's just awesome, the grand dad of performant compilers. Having a PhD means you studied for years to push boundaries, nothing more, nothing less. Lets not forget that the bosses usually decides exactly what should be done with sprints and standup, especially in teams that are not research focused.
- sacado2 6y agoActually I think go is semantically much closer to oberon than to C.
- deleted 6y ago[deleted]
- mehrdadn 6y agoYeah. Literally the only thing I can think of off the top of my head that you can probably remove from C++ without significant damage is virtual base classes, and even that I'm not really sure about. (Curious if anyone here has had much of a use for them.) But anything else seems like it would just fundamentally destroy the language for various slices of its users.
- correct_horse 6y agoDigraphs and Trigraphs seem pretty silly to me. Multiple inheritance is bad, but idk how much code would break if it were removed.
- mehrdadn 6y agoMultiple inheritance is vital to C++. You wouldn't want to remove it any more than you'd remove interfaces from Java. It would break all kinds of things. With you on digraphs and trigraphs, though.
- pkolaczk 6y agoOnly if you write C++ like Java. But there are also coding styles heavily based on templates, and then the use of multiple, or any inheritance is rare. Rust and Go can do without inheritance at all.
- jcelerier 6y ago> Only if you write C++ like Java. But there are also coding styles heavily based on templates, and then the use of multiple, or any inheritance is rare. It's super common to implement mix-ins, which is as based on templates as it's possible to be, with multiple inheritance, e.g. struct featureA { int x; }; struct featureB { const char* foo{}; void print(); }; etc and then template<typename... Args> struct mixin: Args... { template<typename... CtorArgs> mixin(CtorArgs... args) : Args{args}... { } }; using foobar = mixin<featureA, featureB>; void f() { foobar{123, "foo"}.print(); }
- klipt 6y agoFrom the link: > Support maintaining and evolving software written in C++ for decades ... > This requirement should not imply compatibility, but instead some (likely tool-assisted) migratability. I think the idea is you can gradually deprecate outdated features if there's a way of automatically refactoring them out. So you might still be able to compile old code, you might just need to run it through a bunch of migration scripts first.
- joshuamorton 6y agoSpecifically, absl (Google's C++ library already provides this guarantee). In general the idea is that they will provide backwards compatibility for 5 years, and provide tooling to update source code to new constructs. This is covered somewhere in this talk: https://www.youtube.com/watch?v=tISy7EJQPzI https://www.youtube.com/watch?v=tISy7EJQPzI
- dodobirdlord 6y ago> Why not just create that simple, easy, customized-for-server apps language from scratch instead of making it by breaking C++? It's expensive and inefficient to go it alone. It makes it harder to hire and harder to both benefit from and contribute back to the open source community. So they make their pitch and see if anyone else wants to get on board and only if that doesn't pan out will they try to go it alone. The price of going it alone might actually be higher then the benefit.
- flohofwoe 6y ago> Why not just create that simple, easy, customized-for-server apps language from scratch instead of making it by breaking C++? They did that already with Go (one can argue that Go has very different priorities than C++, but Go matches "simple, easy, customized-for-server apps" perfectly).