Hacker News Reader

Comment by pavlov | Hacker News Reader

The is/as pair seems like a tremendous improvement to the dismal C++ type inspection and casting status quo.

However I'm a bit suspect of language syntax that superficially appeals to plain-English meaning of contrasting words, but adds a cognitive overload. I'm thinking of how JavaScript has both `for...in` and `for...of` — the everyday usage of the "in" and "of" prepositions provides no guidance to what these words mean in JavaScript iteration.

View on HN

> The is/as pair seems like a tremendous improvement to the dismal C++ type inspection and casting status quo.

No, unfortunately, it further complicates C++, because the original ways of expressing the same thing will not be removed. You'll just need to remember another level of sugar, but must not forget the lower levels -- e.g., if you want to extend your own type to work with this, you'll need to provide the right plugin definitions. I was especially appalled by the 'x.get()' and 'x.value()' equivalences -- this is just a layer of obfuscation.

That table Herb provides will be added to C++ -- but nothing will be removed.

> No, unfortunately, it further complicates C++, because the original ways of expressing the same thing will not be removed.

This is a very unwise and shortsighted take. Not deprecating features right away means everyone's life is made easier as you can upgrade manage full/partial project upgrades to newer C++ standards without having to resort to tickets blocking your critical path with all-or-nothing upgrades.

And this does not stop at your projects. Dependencies are also covered. Do you believe it's in your best interests that you lose your ability to up point releases to your

Lastly, why does it bother you that backwards compatibility is a Hallmark of C++, and deprecation is a multi-standard process? You're free to stick to a subset if that's what you want. What's the point of getting all bothered with being able to continue using features without seeing them break under your nose for no reason other than a version bump?

Not GP, but what bothers me is that this attitude does not take into account what most cpp programmers actually end up doing: Unless there's somebody at the top of the organization that can set the "right" rules at the start of the project, a novice won't know to use the "right" feature. And neither will somebody who comes from other cpp projects that only had the old way of doing things. The result: a codebase with every possible way of doing a thing, which is strictly worse than one where only one way is used, even if it's not the prettiest. Now if you want to work on it you need to know about everything. Every new feature just increases the need for overhead knowledge. It's almost unavoidable.

So, complaining about this would be an unwise shortsighted take in other languages maybe, that don't have the proven track record of just leaving 10 different ways of doing the same thing on the standard. In cpp it's just the voice of somebody who has been burned one too many times by that kind of feature optimism.

> Not GP, but what bothers me is that this attitude does not take into account what most cpp programmers actually end up doing: Unless there's somebody at the top of the organization that can set the "right" rules at the start of the project, a novice won't know to use the "right" feature.

Unless we're discussing single-developer projects, you'd be hard-pressed to find a single project that does not employ any sort of code reviews,where more seasoned developers have a say in each and every change that's proposed.

If a project is manned by inexperienced novices, the language is not to blame for the developer's regrettable choices.

> The result: a codebase with every possible way of doing a thing, which is strictly worse than one where only one way is used, even if it's not the prettiest.

This is outright incompetence, as it violates basic software engineering principles like the principle of least surprise.

If a project repeatedly surprised developers with multiple fancy ways of doing the same thing and developers don't put time aside to fix that, the tech stack in use is not a factor in this problem.

I bounce between languages for different projects (work, home) and I have to look up examples for how to those JavaScript ones all the time.

A great way to remember: Objects have keys -> foreign keys -> `for .. in`

The mnemonic I use is "for index", as in for keys you can use to index things. One gotcha to remember here is that officially all property names are strings [0], and that includes array indexes. To exemplify, `for (let x in { a: 40, b: 41, c: 42 }) { console.log(x); }` would give you "a", "b", "c" as that's what you can use as an index to key into that object to get the values. And `for (let x in [40, 41, 42]) { console.log(x); }` would give you "0", "1", "2" as that what's you can use as an index to key into that object. I always remember `for..of` as just the other one.

[0] https://stackoverflow.com/q/27537677/1470607

The trick is to remember that “for in” is the obvious one, meaning it’s the older one, meaning it’s the one that’s next to useless and should almost never be used.

In "The C++ Programming Language", casting is described as a tool of last resort. Bjarne says he likes long winded cast operators because they stand out as an easily greppable marker of complex code. I wonder if this perception is changing.

Personally I like the explicit names, even if I can appreciate the argument that the proposed mechanism makes the templating system more generic.

In general, you should know what objects you are sending and receiving, and it shouldn’t be a mystery that requires reinterpreting

> In general, you should know what objects you are sending and receiving, and it shouldn’t be a mystery that requires reinterpreting

You should know what's the interface that you're sending/receiving, but if you're planning on making downcasts then either you're doing something very exotic or you should take a step back and reevaluate what you're doing.

I'm seeing a lot of people in this thread complaining about features being added to C++ that improve developer experience, but barely anyone complaining that shooting yourself in the foot requires making intentional choices to get your feet in front of your guns.

In school I learned about inheritance, not composition. The usual: base "shape" class, then subclasses triangle, square, circle, etc. Then you can have a collection of "shape"s that know what they are. What I've read online indicates it's the same for most other people (who learned in a formal context, anyway). This way of doing things necessitates downcasting; at some point you're converting shape into a triangle or whatever, to access some specific method it has.

I'm not saying this is the right way of doing things (I don't think so), but many people expect this to be possible to do easily -- and it isn't. For them this is normal and not "something very exotic". I guess this is the source of the misunderstanding and the complaints.

> In school I learned about inheritance, not composition.

And that's perfectly fine, provided that students learn that trying to do downcasts like casting an animal instance to a dog instance is something that in general never made any sense, and more often than not reflects ignorance.

> This way of doing things necessitates downcasting;

Not true. That way of doing things necessitates ignorance of basic concepts across many domains, including basic OO programming in general and C++ in particular. You can't blame the tool of your choice for problems you create out of ignorance and failing to think things through.

> In "The C++ Programming Language", casting is described as a tool of last resort. Bjarne says he likes long winded cast operators because they stand out as an easily greppable marker of complex code.

The idea makes a lot of sense. Casting shouldn't be necessary at any time as this means you leave the safe space a static type-system gives you. At the point when you cast all bets are off; it's only on you to prevent type errors, the compiler can't help any more (ant this property of casts is frankly "viral", so it can affect code far away).

The problem with C++ is of course that they have a gazilion of ways to do (sometimes in surprising ways almost) exactly the same.

In Scala for example casts are also very explicit. You need to call the `.asInstanceOf[TargetType]` method. But that's the only syntax for this.

It makes really a big difference to have only one obvious way to do something. (Frankly Scala also doesn't always shine everywhere in this regard).

Its a bit like saying glue and nails isn't necessary to build a house. You should be able to do everything with precision joinery! Many times we are doing a renovation where a good portion makes it impossible to do precision joinery.

JavaScript's for in/of were not intended to be like that. `in` is broken so in a world without backwards compatibility to worry about they would have just fixed it to have the behaviour of `of`. But because they had to consider backwards compatibility they had to come up with a new name.

You should basically never use `for in`. I guess part of the problem is that making that clear in most languages is easy - just add a compiler warning. But JavaScript requires users to manually set up and configure ESLint and if you know how to do that you probably already know not to use `for in` anyway.

I guess modern runtimes like Deno might help here.

What is broken about for in? A quick search didn't turn up anything for me. I don't write much Javascript but for the times I do this seems like it could be useful information for me.

You need to up your Google-foo. E.g.: https://stackoverflow.com/questions/500504/why-is-using-for-...

That talks about using for…in with arrays, but not plain objects. IMO it’s fine for iterating over object keys.

Sure, there are bizarre ways to make your objects go nuts in JavaScript through prototypal inheritance, but if you’re doing that then for…in is not your biggest problem.

You shouldn't normally need to iterate over object keys. Doing so is a pretty big indication of bad design. If you do you should use `Object.entries()` which avoids enumerating properties in the prototype chain.

There's really no reason at all to use for-in and its use is usually a mistake.

This is weird advice IMHO. It seems like you’re saying that iterating over dictionary keys is bad in general, not just in JavaScript. Doesn’t make any sense to me.

I'm not at all. If you want a map you should use `Map`. You generally shouldn't use `Object` as a map.

The classic example is the keyword 'else,' when the proper English term in that sotution would be 'otherwise.'

> the highest level--the root--of the [Unix] filesystem is always designated with the single character "/" and it always contains the same set of top-level directories [...] Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three-letter nubbins, like stones smoothed by a river.

-- Neal Stephenson, In The Beginning... Was The Command Line, 1999

But also note that sometimes the people who make these decisions later realise that they went too far:

> Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e."

-- Kernighan & Pike, The UNIX Programming Environment, 1984

'else' is archaic, rather than wrong.

A quote from Shakespeare's Cybeline:

    If Caesar can hide the sun from us with a blanket, or 
    put the moon in his pocket, we will pay him tribute 
    for light; else, sir, no more tribute, pray you now.

If / else is perfectly clear and correct grammar, though we don't use it in modern speech. We've not chosen 'otherwise', else we waste five columns to no end.

Well, JS's for...in/for...of is just a disaster. It's not an example of regular English words being used _well_ in a language.

Reply on news.ycombinator.com