7 ms·

Your stance reminds me of this post: C++ Modules - a chance to clean up the language? https://www.reddit.com/r/cpp/comments/agcw7d/c_modules_a_chance_to_clean_

by htfy96 8y ago

Your stance reminds me of this post: C++ Modules - a chance to clean up the language? https://www.reddit.com/r/cpp/comments/agcw7d/c_modules_a_chance_to_clean_up_the_language/ https://www.reddit.com/r/cpp/comments/agcw7d/c_modules_a_cha... In short, C++ is a company-driven language instead of a community-driven one like Python and Rust. Some C practices are maintained because voters from the committee agree that these practices are necessary (for their code) and it's impossible to make a completely backward-incompatible change when they have >1M LOC code base.

glouwbug 8y ago
How many 40 year old projects have we maintained that has broken _some_ backwards compatibility? C++ is a triumph in engineering rivalled by something like a megacity transportation system - it's massive, some of it is dark and scary, but it works really really well. The C++ team is up against huge corporations that actively lobby for and against any of their changes - and to top it all, they do it for free. Some obscure C feature is bound it get trampled on.
- steveklabnik 8y ago
  All of them, really. Both C and C++ have made technically breaking changes. This isn’t to denegrate them, of course! It’s that the reality is that “no breakage” is literally impossible. It’s a spectrum, and about the experience.
  - sli 8y ago
    > This isn’t to denegrate them, of course! I totally understand why you included this, but it's a shame that you felt it to be necessary. Refusing to make any breaking changes is how we end up with... well, PHP. There's nothing inherently wrong with breaking change. Too much of it can annoy developers, sure. And sometimes it has to hurt a little bit so progress can be made (see Python). But doing little to no breaking changes ever will eventually cause problems and/or headaches. That said, I wonder how many people moved to (for example) Rust simply because C++ moves slowly. Probably not that many, but surely it's nonzero.
    - deleted 8y ago
      [deleted]
  - kazinator 8y ago
    "No breakage" is possible in a Lisp dialect. With each rev of the dialect, put all new functions and variables into a new namespace like "std2019:...". Old code that doesn't know about new features doesn't run into them at all. Keep the old namespaces untouched: old code finds everything it expects. There is no bullshit like reserved keywords: all symbols are namespaced in packages. New syntax is just macros named by symbols. The only kind of breakage left is system requirements (new tools don't target old hardware well due to larger footprints; new dev environments don't run on old dev hardware; implementations drop support for unpopular platforms).
    - coldtea 8y ago
      That's only if you make superficial changes, and is already possible in non-Lisp languages. What about changing core semantics though?
      - kazinator 8y ago
        Such as what? Say, change strict evaluation to lazy? Core semantics can be wrapped in an operator that is in some namespace. We develop (lazy ...) and everything in it is lazily evaled. File-level annotations are possible. Emacs Lisp introduced lexical scope instead of dynamic scope as a file-level option.
        lispm 8y ago
        In Symbolics Genera stuff was originally implemented in ZetaLisp with Flavors. Then there is CLtL1, Symbolics Common Lisp (a rather large version of Common Lisp), ANSI CL, ... There is quite a non-trivial difference between ZetaLisp and Symbolics Common Lisp: both a very large Lisp dialects. ZetaLisp is dynamically scoped, has base 8 integers, the old flavors system is widely used, Fexprs, ... All these Lisp dialects are provided in the same system and one switches the reader/printer and the packages when changing the language: on can set the language context in a listener and also per file.
- titzer 8y ago
  > C++ is a triumph in engineering I guffawed and then threw up in my mouth a little bit at this. C++ is riddled with dozens of horrible design flaws and kludges that make me think your definition of engineering is just plain wonky. Build time is one. Because of an inherent O(n^2) build system complexity, many large C++ codebases require massive, massive compile farms to achieve even reasonable turnaround times. They produce huge build artifacts that take practically forever to link and are still only barely debuggable. E.g. a recent audit of the V8 build time revealed that it compiles at an effective overall throughput of 186 lines of code per second. How do we deal with that? Distributed build system and 50+ core workstations. This is a travesty of engineering.
  - einpoklum 8y ago
    The feat of engineering is that these problems are gradually being _solved_ or worked around while maintaining backwards compatibility. For example, C++20 will have modules, which means you won't need to include everything again and again in each translation unit.
  - psyclobe 8y ago
    And still... there are many reasons why you'd chose this language over others. They're probably doing _something_ right.
msla 8y ago
I think there's an underlying concept here. C is three things: 1. A mid-level language, by which I mean a language where you do all of the mechanics but you abstract most of the machine-specific details. Memory management is manual, but you don't know or care about how malloc() works behind the scenes, and you can't even ask. You get integers with defined semantics up to things like overflow/wraparound, but you don't know or care if they're implemented in terms of multiple machine words or even if there's such a thing as a carry flag. It's midway between a macro assembler and, say, Python, which does nontrivial magic behind the scenes. 2. An unsafe language, with nontrivial undefined behavior (the overflow/wraparound stuff I mentioned above) with no guide rails like the ones Java provides, where if you overflow the language specifies an error will occur. In C, very little checking code of that type is emitted or specified. 3. A systems programming language, where programmers do unsafe things, like writing values to DMA registers, things the language can't abstract away because... well... you have to write an OS kernel in something, after all. This is unsafe by design, as opposed to the above, where things are unsafe because of a safety/speed trade-off. Rust proponents want to separate 2 from 1 and 3, and make a language where you can do things by hand and do unsafe things on purpose, but the language has more guide rails to prevent you from doing unsafe crap by accident. C++ apparently wants to separate 1 from 2 and 3, to move more high-level and get more "language magic" (templates, iteration stuff... ) without making the language any safer in any respect. That's just an uncomfortable position for a language to be in. My point is, it could move Rust-ward and high-level-ward if it ditched some C-isms from the language... but you gave a good explanation of why it won't.
- pjmlp 8y ago
  > Rust proponents want to separate 2 from 1 and 3, and make a language where you can do things by hand and do unsafe things on purpose, but the language has more guide rails to prevent you from doing unsafe crap by accident. The first systems programming language to introduce this concept was ESPOL , created in 1961, already with the notion of unsafe code blocks. Even better, according to surviving manuals, binaries with unsafe blocks were tainted and required enabling execution by the admin user.
- danra 8y ago
  > C++ apparently wants to separate 1 from 2 and 3, to move more high-level and get more "language magic" (templates, iteration stuff... ) without making the language any safer in any respect. How so? Take std::unique_ptr for example, which exists since C++11. It facilitates using the language in a safer manner, and at a higher level of abstraction (you no longer have to manually malloc and free/new and delete - you just have the concept of scoped ownership), while at the same time not adding any “behind the scenes” magic (e.g. garbage collection) so as not to leave room for any high-level language to be more performant than it is - that’s the real motto of C++, to my understanding.
gumby 8y ago
> n short, C++ is a company-driven language instead of a community-driven one like Python and Rust. Some C practices are maintained because voters from the committee agree that these practices are necessary (for their code) and it's impossible to make a completely backward-incompatible change when they have >1M LOC code base. Well the community has more than 1 MLoC of code and is quite reluctant to break compatibility: look at how hard it has been to get Python to really migrate from v2 to v3. If anything c++ is more willing to make breaking changes (e.g. abandoning the terrible auto_ptr) because of the better tooling (willingness of compiler vendors to put in multi-standard support and appropriate warning flags).
- kazinator 8y ago
  > If anything c++ is more willing to make breaking changes Slept through Python 2 vs 3.
  - gumby 8y ago
    Well you're one of the few. So many packages are still on 2.7, and Dropbox -- even with Guido working there! -- took three years to move to Python 3, just finishing last autumn.
misnome 8y ago
What made this incredibly clear to me was when await/yield was renamed co_await and co_yield because some extreme minority of companies (farming? from some statement I read somewhere 'yield' was the problem) would have to change variable names. It's like it gets a chance to be cleaner, but is then quickly hammered back into ugly syntax that reminds you that you are writing C++. Almost any actual potential leaps in improvement get watered down and neutered way before they have a chance to get near the language.
- evanpw 8y ago
  > farming? from some statement I read somewhere 'yield' was the problem bond yields in finance

by htfy96 8y ago

glouwbug 8y ago

How many 40 year old projects have we maintained that has broken _some_ backwards compatibility? C++ is a triumph in engineering rivalled by something like a megacity transportation system - it's massive, some of it is dark and scary, but it works really really well. The C++ team is up against huge corporations that actively lobby for and against any of their changes - and to top it all, they do it for free. Some obscure C feature is bound it get trampled on.

steveklabnik 8y ago
All of them, really. Both C and C++ have made technically breaking changes. This isn’t to denegrate them, of course! It’s that the reality is that “no breakage” is literally impossible. It’s a spectrum, and about the experience.
- sli 8y ago
  > This isn’t to denegrate them, of course! I totally understand why you included this, but it's a shame that you felt it to be necessary. Refusing to make any breaking changes is how we end up with... well, PHP. There's nothing inherently wrong with breaking change. Too much of it can annoy developers, sure. And sometimes it has to hurt a little bit so progress can be made (see Python). But doing little to no breaking changes ever will eventually cause problems and/or headaches. That said, I wonder how many people moved to (for example) Rust simply because C++ moves slowly. Probably not that many, but surely it's nonzero.
  - deleted 8y ago
    [deleted]
- kazinator 8y ago
  "No breakage" is possible in a Lisp dialect. With each rev of the dialect, put all new functions and variables into a new namespace like "std2019:...". Old code that doesn't know about new features doesn't run into them at all. Keep the old namespaces untouched: old code finds everything it expects. There is no bullshit like reserved keywords: all symbols are namespaced in packages. New syntax is just macros named by symbols. The only kind of breakage left is system requirements (new tools don't target old hardware well due to larger footprints; new dev environments don't run on old dev hardware; implementations drop support for unpopular platforms).
  - coldtea 8y ago
    That's only if you make superficial changes, and is already possible in non-Lisp languages. What about changing core semantics though?
    - kazinator 8y ago
      Such as what? Say, change strict evaluation to lazy? Core semantics can be wrapped in an operator that is in some namespace. We develop (lazy ...) and everything in it is lazily evaled. File-level annotations are possible. Emacs Lisp introduced lexical scope instead of dynamic scope as a file-level option.
      - lispm 8y ago
        In Symbolics Genera stuff was originally implemented in ZetaLisp with Flavors. Then there is CLtL1, Symbolics Common Lisp (a rather large version of Common Lisp), ANSI CL, ... There is quite a non-trivial difference between ZetaLisp and Symbolics Common Lisp: both a very large Lisp dialects. ZetaLisp is dynamically scoped, has base 8 integers, the old flavors system is widely used, Fexprs, ... All these Lisp dialects are provided in the same system and one switches the reader/printer and the packages when changing the language: on can set the language context in a listener and also per file.
titzer 8y ago
> C++ is a triumph in engineering I guffawed and then threw up in my mouth a little bit at this. C++ is riddled with dozens of horrible design flaws and kludges that make me think your definition of engineering is just plain wonky. Build time is one. Because of an inherent O(n^2) build system complexity, many large C++ codebases require massive, massive compile farms to achieve even reasonable turnaround times. They produce huge build artifacts that take practically forever to link and are still only barely debuggable. E.g. a recent audit of the V8 build time revealed that it compiles at an effective overall throughput of 186 lines of code per second. How do we deal with that? Distributed build system and 50+ core workstations. This is a travesty of engineering.
- einpoklum 8y ago
  The feat of engineering is that these problems are gradually being _solved_ or worked around while maintaining backwards compatibility. For example, C++20 will have modules, which means you won't need to include everything again and again in each translation unit.
- psyclobe 8y ago
  And still... there are many reasons why you'd chose this language over others. They're probably doing _something_ right.

msla 8y ago

I think there's an underlying concept here. C is three things: 1. A mid-level language, by which I mean a language where you do all of the mechanics but you abstract most of the machine-specific details. Memory management is manual, but you don't know or care about how malloc() works behind the scenes, and you can't even ask. You get integers with defined semantics up to things like overflow/wraparound, but you don't know or care if they're implemented in terms of multiple machine words or even if there's such a thing as a carry flag. It's midway between a macro assembler and, say, Python, which does nontrivial magic behind the scenes. 2. An unsafe language, with nontrivial undefined behavior (the overflow/wraparound stuff I mentioned above) with no guide rails like the ones Java provides, where if you overflow the language specifies an error will occur. In C, very little checking code of that type is emitted or specified. 3. A systems programming language, where programmers do unsafe things, like writing values to DMA registers, things the language can't abstract away because... well... you have to write an OS kernel in something, after all. This is unsafe by design, as opposed to the above, where things are unsafe because of a safety/speed trade-off. Rust proponents want to separate 2 from 1 and 3, and make a language where you can do things by hand and do unsafe things on purpose, but the language has more guide rails to prevent you from doing unsafe crap by accident. C++ apparently wants to separate 1 from 2 and 3, to move more high-level and get more "language magic" (templates, iteration stuff... ) without making the language any safer in any respect. That's just an uncomfortable position for a language to be in. My point is, it could move Rust-ward and high-level-ward if it ditched some C-isms from the language... but you gave a good explanation of why it won't.

pjmlp 8y ago
> Rust proponents want to separate 2 from 1 and 3, and make a language where you can do things by hand and do unsafe things on purpose, but the language has more guide rails to prevent you from doing unsafe crap by accident. The first systems programming language to introduce this concept was ESPOL , created in 1961, already with the notion of unsafe code blocks. Even better, according to surviving manuals, binaries with unsafe blocks were tainted and required enabling execution by the admin user.
danra 8y ago
> C++ apparently wants to separate 1 from 2 and 3, to move more high-level and get more "language magic" (templates, iteration stuff... ) without making the language any safer in any respect. How so? Take std::unique_ptr for example, which exists since C++11. It facilitates using the language in a safer manner, and at a higher level of abstraction (you no longer have to manually malloc and free/new and delete - you just have the concept of scoped ownership), while at the same time not adding any “behind the scenes” magic (e.g. garbage collection) so as not to leave room for any high-level language to be more performant than it is - that’s the real motto of C++, to my understanding.

gumby 8y ago

> n short, C++ is a company-driven language instead of a community-driven one like Python and Rust. Some C practices are maintained because voters from the committee agree that these practices are necessary (for their code) and it's impossible to make a completely backward-incompatible change when they have >1M LOC code base. Well the community has more than 1 MLoC of code and is quite reluctant to break compatibility: look at how hard it has been to get Python to really migrate from v2 to v3. If anything c++ is more willing to make breaking changes (e.g. abandoning the terrible auto_ptr) because of the better tooling (willingness of compiler vendors to put in multi-standard support and appropriate warning flags).

kazinator 8y ago
> If anything c++ is more willing to make breaking changes Slept through Python 2 vs 3.
- gumby 8y ago
  Well you're one of the few. So many packages are still on 2.7, and Dropbox -- even with Guido working there! -- took three years to move to Python 3, just finishing last autumn.

misnome 8y ago

What made this incredibly clear to me was when await/yield was renamed co_await and co_yield because some extreme minority of companies (farming? from some statement I read somewhere 'yield' was the problem) would have to change variable names. It's like it gets a chance to be cleaner, but is then quickly hammered back into ugly syntax that reminds you that you are writing C++. Almost any actual potential leaps in improvement get watered down and neutered way before they have a chance to get near the language.

evanpw 8y ago
> farming? from some statement I read somewhere 'yield' was the problem bond yields in finance