4 ms·

Ask HN: Do All Programming Languages Have Features That No One Should Use?

I'm a Typescript Developer these days. I've used Java, Python, and PHP professionally as well, but Javascript/Typescript is by far my most well understood. 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?

informationally 5y ago
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"?
- baron816 5y ago
  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.
__d 5y ago
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!
- TheMonarchist 5y ago
  > 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.
  - __d 5y ago
    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.
    - TheMonarchist 5y ago
      > 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.
      - __d 5y ago
        >> 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.

informationally 5y ago

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

baron816 5y ago
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.

__d 5y ago

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!

TheMonarchist 5y ago
> 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.
- __d 5y ago
  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.
  - TheMonarchist 5y ago
    > 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.
    - __d 5y ago
      >> 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.