Live data from Hacker News

Cooperative C++ Evolution – Toward a TypeScript for C++

herbsutter.com

51–60 of 209 posts

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#51
The article assumes that the reader is familiar with what is meant by the “Dart plan” and the “TypeScript plan”. I only have cursory knowledge of Typescript and know nothing about Dart.

Others in this thread already went into more details about this, but it doesn't help me much as long as I don't have an idea what the basic difference between both approaches is.

Can someone ELI5 the gist of both approaches?

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#54

Earlier quoted context omitted.

Why is TypeScript a "bad web technology"? It's not really a "web technology" at all. It's a language which transpiles to standard JavaScript. The only real web-geared parts of TypeScript are the included (optional) DOM typings.

Type annotations for dynamically-typed languages is just a bad idea. JavaScript's only reason for existence is web browsers. If you're not doing web stuff do yourself a favour and use something else.

“C++’s only reason for existence is legacy GUI apps. If you’re not doing embedded stuff do yourself a favor and use something else.”

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#55
I'm heartened by the success of the Typescript model of improving things when there's a deficiency/problem.

The alternate approach (which is extremely popular unfortunately), is to throw it all out and rebuild everything from scratch. I guess it's fun and exciting, which attracts developers, but it takes a long time to achieve any level of maturity and are hard to sustain (the people who are in it for the fun and excitement will move on before too long).

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#57

The article assumes that the reader is familiar with what is meant by the “Dart plan” and the “TypeScript plan”. I only have cursory knowledge of Typescript and know nothing about Dart. Others in this thread already went into more details about this, but it doesn't help me much as long as I don't have an idea what the basic difference between both approaches is. Can someone ELI5 the gist of both approaches?

Someone already wrote up a comment on that:

https://news.ycombinator.com/item?id=38141390

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#58
post #55

I'm heartened by the success of the Typescript model of improving things when there's a deficiency/problem. The alternate approach (which is extremely popular unfortunately), is to throw it all out and rebuild everything from scratch. I guess it's fun and exciting, which attracts developers, but it takes a long time to achieve any level of maturity and are hard to sustain (the people who are in it for the fun and exc…

The people who are in for the fun won't use the typescript model for long either.

If it's optional it will be omitted in the hard parts, for instance if your favorite library doesn't support it.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#60
post #58
post #55

I'm heartened by the success of the Typescript model of improving things when there's a deficiency/problem. The alternate approach (which is extremely popular unfortunately), is to throw it all out and rebuild everything from scratch. I guess it's fun and exciting, which attracts developers, but it takes a long time to achieve any level of maturity and are hard to sustain (the people who are in it for the fun and exc…

The people who are in for the fun won't use the typescript model for long either. If it's optional it will be omitted in the hard parts, for instance if your favorite library doesn't support it.

It's still worthwhile even if you have to fudge module boundaries or skip the hard parts. Kind of like having "safe" Rust wrapping "unsafe" C boundaries doesn't make the rest of Rust not worth it. Lying about the type internals of your function is still preferable to the wild-wild west of JS.
Post reply on HN