Ask HN: Do All Programming Languages Have Features That No One Should Use?
8 comments
Every major language I've used has had features banned by local coding standards. COBOL(!), Modula-2, C, C++, TCL, Python, Java, Javascript, PERL, ...
Little languages too: Makefiles, yacc/lex, etc. They were all a better solution than their forebears, but after years of usage, it's clear they have serious flaws.
In general, over the productive life of a language, experience evolves what is considered good, and features that at the time the language was written were fine, or even considered good, fall from favour as experience grows.
To be fair, some do better than others. C++ has basically become a different language over its lifetime -- C++20 is a _very_ different thing than the C++ I used in the late 80s! Much of what was new and interesting in early C++ is now considered dubious at best.
I think we're approaching a time where C (and C++) will be widely considered to have enough misfeatures that they will fall from use, especially in new applications. That's ok: C is 50 years old -- if we hadn't learned how to do it better in that time, I'd be worried!
Little languages too: Makefiles, yacc/lex, etc. They were all a better solution than their forebears, but after years of usage, it's clear they have serious flaws.
In general, over the productive life of a language, experience evolves what is considered good, and features that at the time the language was written were fine, or even considered good, fall from favour as experience grows.
To be fair, some do better than others. C++ has basically become a different language over its lifetime -- C++20 is a _very_ different thing than the C++ I used in the late 80s! Much of what was new and interesting in early C++ is now considered dubious at best.
I think we're approaching a time where C (and C++) will be widely considered to have enough misfeatures that they will fall from use, especially in new applications. That's ok: C is 50 years old -- if we hadn't learned how to do it better in that time, I'd be worried!
> C is 50 years old -- if we hadn't learned how to do it better in that time, I'd be worried!
The better C would be C++ without the ancient baggage it keeps dragging for backward compatibility. The most recent standards have dropped some of it already.
The better C would be C++ without the ancient baggage it keeps dragging for backward compatibility. The most recent standards have dropped some of it already.
I think this is a terrible, if understandable, mistake: language designers have the problem of knowing when to stop.
Mr Stroustrup and the C++ committee have, over the last 20+ years, continued to "evolve" C++ from being "C with classes" to C++20, in which classes are almost an historical artifact.
C++11 should have been a minimal cleanup of C++03, and C++14 onwards could have been a new language, with all the old baggage removed.
Mr Stroustrup and the C++ committee have, over the last 20+ years, continued to "evolve" C++ from being "C with classes" to C++20, in which classes are almost an historical artifact.
C++11 should have been a minimal cleanup of C++03, and C++14 onwards could have been a new language, with all the old baggage removed.
> language designers have the problem of knowing when to stop
C++ will evolve as long as programming methodology hasn't been perfected. At this point it is immortal and the committee knows it.
> C++11 should have been a minimal cleanup of C++03
C++03 was a very minimal cleanup of C++98 aka ANSI C++. Therefore they were pressed to have much wanted features in the next standard, which was delayed repeatedly to make them ready.
> C++14 onwards could have been a new language, with all the old baggage removed.
The committee seems to gravitate toward first adding the superseding features and removing those rendered obsolete only in the next standard, to provide a clean upgrade path to legacy code. It also leaves time to see which features were really obsoleted.
C++ will evolve as long as programming methodology hasn't been perfected. At this point it is immortal and the committee knows it.
> C++11 should have been a minimal cleanup of C++03
C++03 was a very minimal cleanup of C++98 aka ANSI C++. Therefore they were pressed to have much wanted features in the next standard, which was delayed repeatedly to make them ready.
> C++14 onwards could have been a new language, with all the old baggage removed.
The committee seems to gravitate toward first adding the superseding features and removing those rendered obsolete only in the next standard, to provide a clean upgrade path to legacy code. It also leaves time to see which features were really obsoleted.
>> language designers have the problem of knowing when to stop
> C++ will evolve as long as programming methodology hasn't been perfected. At this point it is immortal and the committee knows it.
I fear you are correct.
>> C++11 should have been a minimal cleanup of C++03
> C++03 was a very minimal cleanup of C++98 aka ANSI C++. Therefore they were pressed to have much wanted features in the next standard, which was delayed repeatedly to make them ready.
Yes. At which point, I think it became clear that there were two languages at play here: one a minor touch-up of C++03, which could have been pushed out once they realized that C++11 was a mutant monster.
And then newC++11, which was the first draft of newC++23, and should've had a more light-weight "agile" development process, allowing what became 14, 17, 20, and 23 to happen without all the pomp and circumstance of the committee process.
>> C++14 onwards could have been a new language, with all the old baggage removed.
> The committee seems to gravitate toward first adding the superseding features and removing those rendered obsolete only in the next standard, to provide a clean upgrade path to legacy code. It also leaves time to see which features were really obsoleted.
Which gives you a constantly moving target, and code that once worked without issue is now in need of major maintenance, and (just like with Python3) the community spends vast amounts of what would otherwise be productive time just keeping application code current.
> C++ will evolve as long as programming methodology hasn't been perfected. At this point it is immortal and the committee knows it.
I fear you are correct.
>> C++11 should have been a minimal cleanup of C++03
> C++03 was a very minimal cleanup of C++98 aka ANSI C++. Therefore they were pressed to have much wanted features in the next standard, which was delayed repeatedly to make them ready.
Yes. At which point, I think it became clear that there were two languages at play here: one a minor touch-up of C++03, which could have been pushed out once they realized that C++11 was a mutant monster.
And then newC++11, which was the first draft of newC++23, and should've had a more light-weight "agile" development process, allowing what became 14, 17, 20, and 23 to happen without all the pomp and circumstance of the committee process.
>> C++14 onwards could have been a new language, with all the old baggage removed.
> The committee seems to gravitate toward first adding the superseding features and removing those rendered obsolete only in the next standard, to provide a clean upgrade path to legacy code. It also leaves time to see which features were really obsoleted.
Which gives you a constantly moving target, and code that once worked without issue is now in need of major maintenance, and (just like with Python3) the community spends vast amounts of what would otherwise be productive time just keeping application code current.
> > The committee seems to gravitate toward first adding the superseding features and removing those rendered obsolete only in the next standard, to provide a clean upgrade path to legacy code.
> Which gives you a constantly moving target, and code that once worked without issue is now in need of major maintenance, and (just like with Python3) the community spends vast amounts of what would otherwise be productive time just keeping application code current.
In practice compilers never remove anything they have had in the past. You may have to re-enable it with a switch though. In the worst case you just stick with the previous standard until code has been updated.
> should've had a more light-weight "agile" development process, allowing what became 14, 17, 20, and 23 to happen without all the pomp and circumstance of the committee process.
To be fair, developing C++ without something like ISO would be impossible. It provides legal protection; so many critical things depend on C++ that the committee would face accusations of collusion without a rigid process and a backing organization.
> C++11 was a mutant monster.
This is true to some extent, but it still was a big improvement on C++03, at least if you wanted to do generic programming and rudimentary metaprogramming.
> > C++ will evolve as long as programming methodology hasn't been perfected. At this point it is immortal and the committee knows it.
> I fear you are correct.
I have for a while suspected that people actually fear it. I wonder why? 20 years ago it may have looked like C++ could kill your favorite language but that's hardly the case today. Now it seems like that it continues to be an expert-friendly language that is used to bridge the gap between human expectations and hardware. I imagine that the future of C++ will look similar to its current symbiosis with Python.
> Which gives you a constantly moving target, and code that once worked without issue is now in need of major maintenance, and (just like with Python3) the community spends vast amounts of what would otherwise be productive time just keeping application code current.
In practice compilers never remove anything they have had in the past. You may have to re-enable it with a switch though. In the worst case you just stick with the previous standard until code has been updated.
> should've had a more light-weight "agile" development process, allowing what became 14, 17, 20, and 23 to happen without all the pomp and circumstance of the committee process.
To be fair, developing C++ without something like ISO would be impossible. It provides legal protection; so many critical things depend on C++ that the committee would face accusations of collusion without a rigid process and a backing organization.
> C++11 was a mutant monster.
This is true to some extent, but it still was a big improvement on C++03, at least if you wanted to do generic programming and rudimentary metaprogramming.
> > C++ will evolve as long as programming methodology hasn't been perfected. At this point it is immortal and the committee knows it.
> I fear you are correct.
I have for a while suspected that people actually fear it. I wonder why? 20 years ago it may have looked like C++ could kill your favorite language but that's hardly the case today. Now it seems like that it continues to be an expert-friendly language that is used to bridge the gap between human expectations and hardware. I imagine that the future of C++ will look similar to its current symbiosis with Python.
I wasn't aware that booleans could be instantiated with a constructor. What would be a reason for using the constructor instead of the literals "true" and "false"?
There really isn’t, and that’s what the OP is saying. But this is worth knowing about:
`true` in Javascript is a primitive, so it doesn’t have any methods on it—it’s just a simple value. But you can do `true.toString()` in JS. How? The engine will automatically convert the primitive to an object so that you get those methods. It’s less useful for booleans, but strings obviously have lots of useful methods that you’d want to use with the actual underlying primitive values.
But yeah, since the language does it automatically for you, you should never do something like `new Boolean(true)`, or `new String(‘hello world’)`. The objects are created when you need them and cleaned up when you don’t.
`true` in Javascript is a primitive, so it doesn’t have any methods on it—it’s just a simple value. But you can do `true.toString()` in JS. How? The engine will automatically convert the primitive to an object so that you get those methods. It’s less useful for booleans, but strings obviously have lots of useful methods that you’d want to use with the actual underlying primitive values.
But yeah, since the language does it automatically for you, you should never do something like `new Boolean(true)`, or `new String(‘hello world’)`. The objects are created when you need them and cleaned up when you don’t.
In JavaScript, no one is supposed to use the Boolean object constructor (new Boolean()). It is singularly unhelpful, and usually does the opposite of what you want. I've never seen a case for it.
Please correct me if there is some arcane reason to use it.
Do other languages have features like this that newbies might try to use once before getting burned and then literally never touch again no matter how advanced they get?
Are there interesting stories for why those features exist?