Hacker News Reader

Comment by harry8 | Hacker News Reader

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).

View on HN

> 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".

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.

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.

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.

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.

Wikipedia says C++ and Rust first appeared in ‘85 and ‘10 respectively. Therefore C++98 is a 13 year old version of C++ and Rust today is about 10 years old. It’s entirely possible that Wikipedia uses “first appeared” to mean different things in either article, but I’m assuming (rightly or wrongly) that they aren’t doing that.

The inception of C++ programming language began in 1979 when Bjarne Stroustrup was working in his Ph.D. thesis.

https://www.stroustrup.com/hopl2.pdf

> whose features are very thoughtfully considered and not "bolted on" at all

Rust has it's dangerous, unsafe warts. As someone learning rust, finding out that string slices can cause panics was utterly shocking to me. string slices should have had character indices not byte indices. This was a feature that was NOT thought of carefully. It completely goes against Rust's philosophy as a "safe", catch-errors-at-compile language.

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

> slow-moving development

> too much feature churn

Pick one, please.

you can have both if you hire more developers on the project.

The OP said "cruft" not "too much feature churn". Very different things.

Can you point to the comment you quoted the "too much feature churn" from?

High-latency but high-bandwidth. C++ features take forever to land, but there's always something big in the pipeline, for better or worse.

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)

Compared to C, C++ isn't that slow moving.

Not many languages take C's ultra-high-inertia approach. Perhaps Scheme and Forth.

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.

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.

C++ moves at lightspeed compared to Fortran, which might get some kind of templates around 2030.

C++20 added modules to the language more than 3 decades after Fortran had it already in the language.

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.

> 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.

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.

Editions can fix syntax level flaws, but many semantic flaws or flaws in the standard library can't be fixed like that.

Why not?

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.

Got it - thanks, I'd never really considered that.

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.

Reply on news.ycombinator.com