5 ms·

Counterpoint - slowing down the rate of change of a properly designed language makes it stronger. Having a vast amount of bolted-on cruft with inconsistent desi

by harry8 5y ago

Counterpoint - slowing down the rate of change of a properly designed language makes it stronger. Having a vast amount of bolted-on cruft with inconsistent design principles makes a language pretty horrible. Example C++. It's a fun exercise to think about how you would do C++ fresh starting with ansi C, given what you know now based on the actual experiences of C++, Java, D, Rust etc. C++ has had a tendency to attempt to solve the current problem while being tightly coupled to it, problems which may not even exist later. I submit STL allocators as an example of this. What's the best way of enforcing taste? Slow down the changes, put barriers in the way? That's horrible, sure, but is there something better? Benign Dictator maybe? Bjarne's taste has improved considerably (and I'm sure I could have made a bigger hash of it than he did starting out too).

duped 5y ago
C++ is the poster child of cruft and slow moving development, so it doesn't seem that these properties are correlated.
- otabdeveloper4 5y ago
  > slow-moving development > too much feature churn Pick one, please.
  - kgraves 5y ago
    you can have both if you hire more developers on the project.
  - bryanlarsen 5y ago
    The OP said "cruft" not "too much feature churn". Very different things.
  - detaro 5y ago
    Can you point to the comment you quoted the "too much feature churn" from?
  - simias 5y ago
    High-latency but high-bandwidth. C++ features take forever to land, but there's always something big in the pipeline, for better or worse.
- harry8 5y ago
  Yeah at first blush. Then you look at when C++ was new and being standardized it was moving pretty damn fast compared to anything else. They had a whole catchphrase "Remember the Vasa!" In an attempt to justify curbing enthusiasm for at least some of the many and disperate proposals. Now, despite the big changes of C++11 as the watershed it has slowed and is doing better for it. Correlated? Maybe. Good taste should also slow the rate of change of "What do I have to deal with as a programmer in this language?" Also if the original language design that people found good enough to use was done really well then it shouldn't need too much change on top of it? Point taken, you can use C++ as an example for anything. Even opposing points. It really has it all! (Like it or not)
- MaxBarraclough 5y ago
  Compared to C, C++ isn't that slow moving. Not many languages take C's ultra-high-inertia approach. Perhaps Scheme and Forth.
  - DoingIsLearning 5y ago
    Ada, 4 standards in 4 decades (1983, 1987, 1995, 2012). Most people using it will probably also claim it is a feature rather than a handicap. Reminder that Ada already had modules (Packages) almost a decade ago.
    - MaxBarraclough 5y ago
      The frequency of the updates are only part of the story though. C had C89, C99, C11, C17. C++ had C++98, C++03, C++11, C++14, C++17, C++20. C++ is updated more often, but it also makes more significant changes in each version than C does. I don't know Ada as well as I know C and C++, but I believe Ada lands somewhere between C and C++ in terms of how fast-moving it is. Makes sense that Ada is pretty slow moving, given its purpose.
- pklausler 5y ago
  C++ moves at lightspeed compared to Fortran, which might get some kind of templates around 2030.
  - TheRealKing 5y ago
    C++20 added modules to the language more than 3 decades after Fortran had it already in the language.
zarzavat 5y ago
Rust has the best approach. Stable and unstable branches, so that language changes can be trialed on real projects and modified or backed out as required. Getting more eyeballs on a language change and getting language users involved in its development leads to more strength than simply spending more time on each change.
throwaway894345 5y ago
> Counterpoint - slowing down the rate of change of a properly designed language makes it stronger. Having a vast amount of bolted-on cruft with inconsistent design principles makes a language pretty horrible. Example C++ Isn't C++ an example of a language that moves slowly and still has lots of bolted on features? Having used it a bit, I would use Rust as an example of a language whose features are very thoughtfully considered and not "bolted on" at all. If we're just looking at C++ and Rust and drawing conclusions, I would expect the conclusion would be "moving super slowly correlates with more bolted on features, not fewer".
- bregma 5y ago
  C++ is an example of a language whose features were very thoughtfully considered and not bolted on at all when it was as young and untried as Rust is now.
  - N1H1L 5y ago
    Yes. Let's see how much cruft Rust has in 10-15 years as usage accelerates? For example Rust's GPU support is not great right now - and it may very well feel bolted on a few years down the line.
  - throwaway894345 5y ago
    By C++98 the language was already a hot mess, only 13 years after the language debuted. It's been 10 years since Rust first appeared, and its featureset shows no signs of cruft, nor does its trajectory indicate that it's going to acquire a lot of cruft in the next 3 years. I think it's more likely that Rust just benefited from lots of hindsight with respect to C++'s mistakes. Note also that since C++11, the language has been evolving quite quickly and the features released since have been some of the most thoughtful.
    - tialaramex 5y ago
      Either C++98 is 16 years after it debuted, or it has only been 6 years since Rust appeared. You can't tweak both these timelines in opposite directions and claim to be comparing anything. By 1985 C++ has a published book describing the language (which I still own somewhere, it's terrible) and a commercial implementation as well as Stroustrup's code. While in June 2011 Rust isn't even "pre-alpha" and is just learning how to bootstrap.
marcosdumay 5y ago
Hum... I do think the amount of bolted-in features correlates basically to age and unwillignes to fix past mistakes. It also seems to depend a lot on the strength of the initial stable idea. The speed of change before it stabilizes has a strong inverse correlation with the number of features that don't fit well, and after it stabilizes I don't see much of a correlation overall.
Zababa 5y ago
Editions, like for Rust, seems to be a solution. If you add a feature because it's really popular at some point but then decide to remove it, you can. This allows for removing legacy cruft after some time, so newcommers and new codebases don't have to care about it. And it's codified and enforced by the compiler, not "here's a list of what you can use". On the other hand, it creates churn. But you can't have evolution, no cruft and no churn. It's a "pick two out of 3" situation.
- CodesInChaos 5y ago
  Editions can fix syntax level flaws, but many semantic flaws or flaws in the standard library can't be fixed like that.
  - staticassertion 5y ago
    Why not?
    - steveklabnik 5y ago
      Editions can only change the very front-end of the compiler, and the standard library must be able to be used in all editions, so it’s not really possible to change on a per-edition basis. There’s only one copy of it globally unlike other Rust packages.
      - staticassertion 5y ago
        Got it - thanks, I'd never really considered that.
staticassertion 5y ago
> Having a vast amount of bolted-on cruft with inconsistent design principles makes a language pretty horrible. From what I can tell the vast majority of changes to Rust are small things like "Adding a method to Vec". These aren't really the type of things that turn into cruft/ radically change the language, but we also don't have to wait years for them.

by harry8 5y ago

duped 5y ago

C++ is the poster child of cruft and slow moving development, so it doesn't seem that these properties are correlated.

otabdeveloper4 5y ago
> slow-moving development > too much feature churn Pick one, please.
- kgraves 5y ago
  you can have both if you hire more developers on the project.
- bryanlarsen 5y ago
  The OP said "cruft" not "too much feature churn". Very different things.
- detaro 5y ago
  Can you point to the comment you quoted the "too much feature churn" from?
- simias 5y ago
  High-latency but high-bandwidth. C++ features take forever to land, but there's always something big in the pipeline, for better or worse.
harry8 5y ago
Yeah at first blush. Then you look at when C++ was new and being standardized it was moving pretty damn fast compared to anything else. They had a whole catchphrase "Remember the Vasa!" In an attempt to justify curbing enthusiasm for at least some of the many and disperate proposals. Now, despite the big changes of C++11 as the watershed it has slowed and is doing better for it. Correlated? Maybe. Good taste should also slow the rate of change of "What do I have to deal with as a programmer in this language?" Also if the original language design that people found good enough to use was done really well then it shouldn't need too much change on top of it? Point taken, you can use C++ as an example for anything. Even opposing points. It really has it all! (Like it or not)
MaxBarraclough 5y ago
Compared to C, C++ isn't that slow moving. Not many languages take C's ultra-high-inertia approach. Perhaps Scheme and Forth.
- DoingIsLearning 5y ago
  Ada, 4 standards in 4 decades (1983, 1987, 1995, 2012). Most people using it will probably also claim it is a feature rather than a handicap. Reminder that Ada already had modules (Packages) almost a decade ago.
  - MaxBarraclough 5y ago
    The frequency of the updates are only part of the story though. C had C89, C99, C11, C17. C++ had C++98, C++03, C++11, C++14, C++17, C++20. C++ is updated more often, but it also makes more significant changes in each version than C does. I don't know Ada as well as I know C and C++, but I believe Ada lands somewhere between C and C++ in terms of how fast-moving it is. Makes sense that Ada is pretty slow moving, given its purpose.
pklausler 5y ago
C++ moves at lightspeed compared to Fortran, which might get some kind of templates around 2030.
- TheRealKing 5y ago
  C++20 added modules to the language more than 3 decades after Fortran had it already in the language.

zarzavat 5y ago

Rust has the best approach. Stable and unstable branches, so that language changes can be trialed on real projects and modified or backed out as required. Getting more eyeballs on a language change and getting language users involved in its development leads to more strength than simply spending more time on each change.

throwaway894345 5y ago

> Counterpoint - slowing down the rate of change of a properly designed language makes it stronger. Having a vast amount of bolted-on cruft with inconsistent design principles makes a language pretty horrible. Example C++ Isn't C++ an example of a language that moves slowly and still has lots of bolted on features? Having used it a bit, I would use Rust as an example of a language whose features are very thoughtfully considered and not "bolted on" at all. If we're just looking at C++ and Rust and drawing conclusions, I would expect the conclusion would be "moving super slowly correlates with more bolted on features, not fewer".

bregma 5y ago
C++ is an example of a language whose features were very thoughtfully considered and not bolted on at all when it was as young and untried as Rust is now.
- N1H1L 5y ago
  Yes. Let's see how much cruft Rust has in 10-15 years as usage accelerates? For example Rust's GPU support is not great right now - and it may very well feel bolted on a few years down the line.
- throwaway894345 5y ago
  By C++98 the language was already a hot mess, only 13 years after the language debuted. It's been 10 years since Rust first appeared, and its featureset shows no signs of cruft, nor does its trajectory indicate that it's going to acquire a lot of cruft in the next 3 years. I think it's more likely that Rust just benefited from lots of hindsight with respect to C++'s mistakes. Note also that since C++11, the language has been evolving quite quickly and the features released since have been some of the most thoughtful.
  - tialaramex 5y ago
    Either C++98 is 16 years after it debuted, or it has only been 6 years since Rust appeared. You can't tweak both these timelines in opposite directions and claim to be comparing anything. By 1985 C++ has a published book describing the language (which I still own somewhere, it's terrible) and a commercial implementation as well as Stroustrup's code. While in June 2011 Rust isn't even "pre-alpha" and is just learning how to bootstrap.

marcosdumay 5y ago

Hum... I do think the amount of bolted-in features correlates basically to age and unwillignes to fix past mistakes. It also seems to depend a lot on the strength of the initial stable idea. The speed of change before it stabilizes has a strong inverse correlation with the number of features that don't fit well, and after it stabilizes I don't see much of a correlation overall.

Zababa 5y ago

Editions, like for Rust, seems to be a solution. If you add a feature because it's really popular at some point but then decide to remove it, you can. This allows for removing legacy cruft after some time, so newcommers and new codebases don't have to care about it. And it's codified and enforced by the compiler, not "here's a list of what you can use". On the other hand, it creates churn. But you can't have evolution, no cruft and no churn. It's a "pick two out of 3" situation.

CodesInChaos 5y ago
Editions can fix syntax level flaws, but many semantic flaws or flaws in the standard library can't be fixed like that.
- staticassertion 5y ago
  Why not?
  - steveklabnik 5y ago
    Editions can only change the very front-end of the compiler, and the standard library must be able to be used in all editions, so it’s not really possible to change on a per-edition basis. There’s only one copy of it globally unlike other Rust packages.
    - staticassertion 5y ago
      Got it - thanks, I'd never really considered that.

staticassertion 5y ago

> Having a vast amount of bolted-on cruft with inconsistent design principles makes a language pretty horrible. From what I can tell the vast majority of changes to Rust are small things like "Adding a method to Vec". These aren't really the type of things that turn into cruft/ radically change the language, but we also don't have to wait years for them.