You must log in or # to comment.
Less fucked-up than Javascript.
I did not wish to believe… but then I saw.
This diagram is nonsense. JavaScript programmers know to simply never use
==but to use===instead. Half of JavaScript is like this. Oh, there’s a feature, but it behaves in a super weird way so we don’t use it to avoid the weirdness.Where’s the
==operator? Because they also have the exact same problem.As someone trying to learn Javascript, it just makes me mad that at this garbage heap of a language is so widely used.
The problem is that you can’t break compatibility.
Only in some exceptional cases. 🙃
Not with that attitude
Personally, I’d love to break compatibility for better features and consistency. We should be able to declare the version at the top of the file or something. Nothing at the top = legacy crap. 🤷♂️ I dunno.
==has never, ever caused me a single issue. Parsing all server input with type-safe schemas makes sure that where I expect a string, I get a string; where I expect a number, I get a number. Bad data must result in an error before it reaches logic.“I have no problem living in a house of cards as I make sure to never bump against the walls.”
I wonder how many millions of programmer man-hours have been wasted working around JavaScript’s design mistakes that could’ve been saved simply by putting Scheme or Python (which were actually being considered) in the browser instead.
Opposite, living in a house of cards is when you blindly trust data that comes from user. Regardless of the language.
eqeqeqisn’t in the recommended linting presets because if you end up needing it, you’re probably already in big trouble because of insecure software design.Nobody is advocating for blindly trusting data from the user.
Then where do you see the house of cards? What’s the practical difference between == and ===, when your app is type-checked and the inputs are safely parsed?
Because you don’t know whether you’ve actually type-checked everything and that your inputs are safely parsed. Part of defensive programming is to adopt multiple defences to prevent bad data from getting through, including avoiding ==.
IIRC modern linter rulesets generally just outright error if you do anything remotely like this.
When I had to use JS I wrote JS 1.2 because why not. Fun how I had strings of numbers instead of actual numbers in some
forloops, yet it all sort of functioned until something didn’t. I then decided to add Number() to random values just in case.
If anyone is starting to learn C++, make sure to use books or training materials based on C++11 or later.
Even C++11 is pretty old. I would recommend at least C++17
As someone who last touched any C++ books when C++11 was very new and has only written like 20-30 lines of non-tutorial C++ since then, what are some significant changes to the language that I should be aware of if I wanted to give it a try now?
A few examples:
- CTAD: Instead of
std::pair<int, int> myPair{ 1, 2 }, you just writestd::pair myPair{ 1, 2 } - std::optional, std::variant and std::any
- Guaranteed copy elision in some cases, making it more feasible to apply the rule of 5 everywhere
- Attributes like [[nodiscard]] (compiler warning if an object or return value is discarded) and [[fallthrough]] (suppress a switch fallthrough warning)
- Generic lambdas (
[](auto it){ /* do something */ }) - std::string_view, which is much safer as a function parameter than
const char*
Class Template Argument Deduction (CTAD)
For anyone wondering, like I did.
- CTAD: Instead of
Modules
No. I don’t find it a particularly nice language to work with, but there’s no reason to fear it. Just make sure you know what you’re doing if/when you use it.
So yes
No
Superposition is for quantum computing, C++ does not apply.
Of C? No
Of C++? Yes
No, the C++ should fear you!
Your example is just brainfuck but somehow even worse