4 ms·

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 me

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.

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.