8 ms·

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

by jmull 3y ago

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).

eviks 3y ago
The alternate approach is also popular because there is no success in the typescript model, as in critical deficiencies get unfixed for decades (with some of the same "not fun" challenges )
- misnome 3y ago
  What hasn't gotten fixed in typescript for "decades"?
  - eviks 3y ago
    The 10x complexity and 50x unsafety
    - wsve 3y ago
      [dead]
- wsve 3y ago
  There is no success in the Typescript model...? What on earth are you needing that off of?
  - eviks 3y ago
    what is your list of successes besides TS?
    - munificent 3y ago
      Ironically... C++. C++ was itself the TypeScript model applied to C. And, in fact, many of the things people hate about C++ are the result of exactly the kind of compromises you have to make to apply a TypeScript-like model to language evolution. C backwards compatibility is what made C++ successful originally but is now one of the main things that makes C++ crappy today.
croes 3y ago
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.
- DangitBobby 3y ago
  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.
  - deleted 3y ago
    [deleted]
- solarkraft 3y ago
  That's why incremental adoptability is so powerful. Slightly ironically that's exactly what (AFAIK) made C++ so popular: You can start using it without really giving up anything. And ideally once you see the benefits you'll be hooked and want to (incrementally) use it more and more throughout your code.
  - pjmlp 3y ago
    And exactly what makes C++ codebases so hard to clean up from C idioms, as many developers to this day apparently never went beyond changing the file extension, regardless of how many security advocacy we keep telling them.
    - Aeolos 3y ago
      C++ adds so many additional security footguns over C, that I find this line of reasoning hard to accept. The problem with C++ is not that people are using C constructs with it, the problem is that the language design itself is deficient. Are you aware of any systematic review that shows evidence that C++ is safer than C? The rate of safety defects between major C and C++ projects appears similar at first glance, and both way worse than managed languages or rust.
jmisavage 3y ago
The only problem is you run the risk of implementing a still developing standard that might be vastly different than the finalize version. You then have code and programmers trained in doing something the old "wrong" way. This happened in TypeScript when they added support for an early version of decorators and now the TC39 version (which is still only Stage 3) is just different enough to cause issues.
- moogly 3y ago
  You mean the feature that was gated behind an opt-in switch called `experimentalDecorators' and documented from the start with "Experimental support for decorators is a feature that is subject to change in a future release"? This was only really added to appease Google and Angular 2.0.
  - leptons 3y ago
    People who chase "new, shiny" often get rewarded with stupid prizes.
  - jmisavage 3y ago
    Yeah Microsoft didn’t want AtScript to steal the little thunder TypeScript had at the time, but we’re still left with that one experimental feature all over Angular codebases.
- evilduck 3y ago
  They have been labeled experimental the entire time and off by default. That specific TC39 proposal is also approaching a decade of feet dragging and has been exceptionally slow to make progress. In Typescript if you aren’t opting into using decorators through a library that forces you to use them, they’re entirely avoidable (and some would argue, decorators make code worse and this failure to launch is a good thing). I think the Typescript creators themselves learned a lesson with decorators and enums which is why we haven’t seen other JS language proposals get added until they’re actually in the process of being adopted (e.g. matchers).
  - 3y ago
mike_hock 3y ago
The TS approach is really dumb for C++ and completely unnecessary. Compile times are long enough as it is without another meta compiler on top. You already have a compiler. Just make it emit binary-compatible code for the new dialect. You have modules now so you don't have the problem of supporting mixed-dialect headers.
- IAmLiterallyAB 3y ago
  The TS approach isn't about having a meta compiler. cppfront is just a temporary stepping stone, just like cfront (the original C++ compiler) was a temporary frontend for C++. Eventually the goal would be to add support for the new syntax to GCC, Clang, MSVC
  - wsve 3y ago
    Not just that, but a big part of Herbs feature set are things that can work as proof of concepts and proof of usefulness that could be presented to the C++ committee as actual features that can be added to C++. Many of the features of cppfront have already been proposed to committee.
    - tialaramex 3y ago
      This was dead when I saw it, which is weird because it's factually true. So I vouched for it. Herb Sutter proposes a bunch of stuff to WG21 (the C++ committee) and most of it goes nowhere. We're not talking about two proposals here, maybe a dozen is closer. Most of that stuff from many years is in Cpp2 because it's Herb's language so they can't stop him. The one thing Herb proposed in that time which got into C++ was the spaceship operator <=> which is basically like Rust's PartialOrd trait, you write one operator for your type, and for any pair of values (this & that) you decide whether this was Greater, Equal or Less than that -- or none of the above. As a result the compiler can implement all the obvious comparison operators like <= or == or > using that one piece of code you wrote, and it's easily able to be consistent. This is very nice, and it's in C++ today, but it's also in Cpp2 of course.
  - mike_hock 3y ago

by jmull 3y ago

eviks 3y ago

The alternate approach is also popular because there is no success in the typescript model, as in critical deficiencies get unfixed for decades (with some of the same "not fun" challenges )

misnome 3y ago
What hasn't gotten fixed in typescript for "decades"?
- eviks 3y ago
  The 10x complexity and 50x unsafety
  - wsve 3y ago
    [dead]
wsve 3y ago
There is no success in the Typescript model...? What on earth are you needing that off of?
- eviks 3y ago
  what is your list of successes besides TS?
  - munificent 3y ago
    Ironically... C++. C++ was itself the TypeScript model applied to C. And, in fact, many of the things people hate about C++ are the result of exactly the kind of compromises you have to make to apply a TypeScript-like model to language evolution. C backwards compatibility is what made C++ successful originally but is now one of the main things that makes C++ crappy today.

croes 3y ago

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.

DangitBobby 3y ago
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.
- deleted 3y ago
  [deleted]
solarkraft 3y ago
That's why incremental adoptability is so powerful. Slightly ironically that's exactly what (AFAIK) made C++ so popular: You can start using it without really giving up anything. And ideally once you see the benefits you'll be hooked and want to (incrementally) use it more and more throughout your code.
- pjmlp 3y ago
  And exactly what makes C++ codebases so hard to clean up from C idioms, as many developers to this day apparently never went beyond changing the file extension, regardless of how many security advocacy we keep telling them.
  - Aeolos 3y ago
    C++ adds so many additional security footguns over C, that I find this line of reasoning hard to accept. The problem with C++ is not that people are using C constructs with it, the problem is that the language design itself is deficient. Are you aware of any systematic review that shows evidence that C++ is safer than C? The rate of safety defects between major C and C++ projects appears similar at first glance, and both way worse than managed languages or rust.

jmisavage 3y ago

The only problem is you run the risk of implementing a still developing standard that might be vastly different than the finalize version. You then have code and programmers trained in doing something the old "wrong" way. This happened in TypeScript when they added support for an early version of decorators and now the TC39 version (which is still only Stage 3) is just different enough to cause issues.

moogly 3y ago
You mean the feature that was gated behind an opt-in switch called `experimentalDecorators' and documented from the start with "Experimental support for decorators is a feature that is subject to change in a future release"? This was only really added to appease Google and Angular 2.0.
- leptons 3y ago
  People who chase "new, shiny" often get rewarded with stupid prizes.
- jmisavage 3y ago
  Yeah Microsoft didn’t want AtScript to steal the little thunder TypeScript had at the time, but we’re still left with that one experimental feature all over Angular codebases.
evilduck 3y ago
They have been labeled experimental the entire time and off by default. That specific TC39 proposal is also approaching a decade of feet dragging and has been exceptionally slow to make progress. In Typescript if you aren’t opting into using decorators through a library that forces you to use them, they’re entirely avoidable (and some would argue, decorators make code worse and this failure to launch is a good thing). I think the Typescript creators themselves learned a lesson with decorators and enums which is why we haven’t seen other JS language proposals get added until they’re actually in the process of being adopted (e.g. matchers).
- 3y ago

mike_hock 3y ago

The TS approach is really dumb for C++ and completely unnecessary. Compile times are long enough as it is without another meta compiler on top. You already have a compiler. Just make it emit binary-compatible code for the new dialect. You have modules now so you don't have the problem of supporting mixed-dialect headers.

IAmLiterallyAB 3y ago
The TS approach isn't about having a meta compiler. cppfront is just a temporary stepping stone, just like cfront (the original C++ compiler) was a temporary frontend for C++. Eventually the goal would be to add support for the new syntax to GCC, Clang, MSVC
- wsve 3y ago
  Not just that, but a big part of Herbs feature set are things that can work as proof of concepts and proof of usefulness that could be presented to the C++ committee as actual features that can be added to C++. Many of the features of cppfront have already been proposed to committee.
  - tialaramex 3y ago
    This was dead when I saw it, which is weird because it's factually true. So I vouched for it. Herb Sutter proposes a bunch of stuff to WG21 (the C++ committee) and most of it goes nowhere. We're not talking about two proposals here, maybe a dozen is closer. Most of that stuff from many years is in Cpp2 because it's Herb's language so they can't stop him. The one thing Herb proposed in that time which got into C++ was the spaceship operator <=> which is basically like Rust's PartialOrd trait, you write one operator for your type, and for any pair of values (this & that) you decide whether this was Greater, Equal or Less than that -- or none of the above. As a result the compiler can implement all the obvious comparison operators like <= or == or > using that one piece of code you wrote, and it's easily able to be consistent. This is very nice, and it's in C++ today, but it's also in Cpp2 of course.
- mike_hock 3y ago