6 ms·

It's a bit different with compiled code though right? If you stop supporting the previous C revision, it means the person compiling your code need to upgrade th

It's a bit different with compiled code though right? If you stop supporting the previous C revision, it means the person compiling your code need to upgrade their compiler, the executable will work for everyone on that platform once built. Whereas in JS-land, the support for upgrades is even more trailing because it's the end-users who need to upgrade, not just the individual/organization doing the packaging.

root_axis 7y ago
Huh? The compiled JS will continue to work just fine for the end-user. Not sure what you're getting at.
- semigroupoid 7y ago
  Sure, but JavaScript isn't compiled but typically interpreted (or JITed).
  - root_axis 7y ago
    Sure, but this is a distinction without a difference from the perspective of the end-user.
- syntheticcdo 7y ago
  If your C code is upgraded from C n to to use C n+1 features, then it breaks compilers that do not support c n+1. This is not a problem for end-users, because most people do not compile the code themselves, but use pre-built binaries. So, it is a problem for the package maintainer to deal with, the package maintainer upgrades their compiler and the new binaries just work for the end user, because once compiled it doesn't matter if the source was C n or C n+1. If you JS code is upgraded from ES n to ES n+1, you need to polyfill and transpile in perpetuity, otherwise end users with access to only ES n browsers will not be able to run your code at all. Comparing C spec updates and JS spec updates is comparing apples to oranges.
  - root_axis 7y ago
    > If you JS code is upgraded from ES n to ES n+1, you need to polyfill and transpile in perpetuity, otherwise end users with access to only ES n browsers will not be able to run your code at all. I'm still not seeing the difference. End users of JS applications don't compile their code the same way end users of a C binary don't compile the code.
    - chadlavi 7y ago
      If you ship an app with ES6 js and a user with a browser that doesn't support ES6 features tries to access it, then it won't work for them. The user doesn't manually compile anything, but their choice (sometimes lack of choice) of browser determines which version of the spec they can run. So you end up polyfilling forever because some significant chunk of your user base is tied to IE8 or worse. All the original commenter meant is that the people making the software can't ever guarantee what version of JS the end user's browser can handle.
      - root_axis 7y ago
        > If you ship an app with ES6 js and a user with a browser that doesn't support ES6 features tries to access it, then it won't work for them. Right, but if the developer transpiles their source code and distributes it then the JS end-user is in the same situation as the C binary user. Distributing ES6 code without transpiling it is akin to distributing C source code without compiling: the end-user would need to have an up to date compiler/runtime to execute the code.
Crinus 7y ago
> If you stop supporting the previous C revision, it means the person compiling your code need to upgrade their compiler FYI, this doesn't happen in C, all C versions are backwards compatible - you can compile C89 code on any compiler supporting C99, C11 or C18.
- partomniscient 7y ago
  Where C11 > C99. Talk about naming problems / sorting problems. They've adopted Microsofts versioning system where Windows 8 is newer than both Windows 98 and Windows 2000. Does anyone remember the Y2K problem. Anyone????? They worked out naming things properly (where computers are involved) was a big problem in the 1960's. But we still only allocated 3 bytes for the version of C or something...?
- MikeSchurman 7y ago
  parent means if code starts using C99 features that won't work in C89, then the person with a C89 compiler needs to upgrade their compiler.
WalterSear 7y ago
Different, yes, but the difference is quantitative, not qualitative. Once a transpile step is required, it doesn't make as much of a difference what is on the other side.
WorldMaker 7y ago
C to a lesser extent does have the same trailing problem with end users as well in libc / VCRUNTIME and other standard lib bundles. On Windows VCRUNTIME installs are mostly painless, easily backgrounded, and people don't realize they sometimes have as many as 100s of different versions installed side-by-side because every game installed wants a slightly different version. But on Linux, it's often as much as like three-fourths of the reason that code needs to be rebuilt so often for every possible different Linux distribution because most distributions lock to only a single libc and prefer every app dynamically link that specific libc. Apps get held back by distributions slow to adopt libc updates all the time in Linux, and app devs try to stick to common libc versions based on distribution popularity (user preference), which isn't dissimilar to the lagging browser problem. (Then there are arguments about statically bundling libc / VCRUNTIME, etc.) It's not as bad as JS land on average, but that doesn't mean that C is immune to the same problem. As soon as you are dealing with shared libraries / platforms / runtimes, you run into having to deal with what users are willing to install (and practically no platform is immune, depending on trade-offs one is willing to take).

root_axis 7y ago

Huh? The compiled JS will continue to work just fine for the end-user. Not sure what you're getting at.

semigroupoid 7y ago
Sure, but JavaScript isn't compiled but typically interpreted (or JITed).
- root_axis 7y ago
  Sure, but this is a distinction without a difference from the perspective of the end-user.
syntheticcdo 7y ago
If your C code is upgraded from C n to to use C n+1 features, then it breaks compilers that do not support c n+1. This is not a problem for end-users, because most people do not compile the code themselves, but use pre-built binaries. So, it is a problem for the package maintainer to deal with, the package maintainer upgrades their compiler and the new binaries just work for the end user, because once compiled it doesn't matter if the source was C n or C n+1. If you JS code is upgraded from ES n to ES n+1, you need to polyfill and transpile in perpetuity, otherwise end users with access to only ES n browsers will not be able to run your code at all. Comparing C spec updates and JS spec updates is comparing apples to oranges.
- root_axis 7y ago
  > If you JS code is upgraded from ES n to ES n+1, you need to polyfill and transpile in perpetuity, otherwise end users with access to only ES n browsers will not be able to run your code at all. I'm still not seeing the difference. End users of JS applications don't compile their code the same way end users of a C binary don't compile the code.
  - chadlavi 7y ago
    If you ship an app with ES6 js and a user with a browser that doesn't support ES6 features tries to access it, then it won't work for them. The user doesn't manually compile anything, but their choice (sometimes lack of choice) of browser determines which version of the spec they can run. So you end up polyfilling forever because some significant chunk of your user base is tied to IE8 or worse. All the original commenter meant is that the people making the software can't ever guarantee what version of JS the end user's browser can handle.
    - root_axis 7y ago
      > If you ship an app with ES6 js and a user with a browser that doesn't support ES6 features tries to access it, then it won't work for them. Right, but if the developer transpiles their source code and distributes it then the JS end-user is in the same situation as the C binary user. Distributing ES6 code without transpiling it is akin to distributing C source code without compiling: the end-user would need to have an up to date compiler/runtime to execute the code.

Crinus 7y ago

> If you stop supporting the previous C revision, it means the person compiling your code need to upgrade their compiler FYI, this doesn't happen in C, all C versions are backwards compatible - you can compile C89 code on any compiler supporting C99, C11 or C18.

partomniscient 7y ago
Where C11 > C99. Talk about naming problems / sorting problems. They've adopted Microsofts versioning system where Windows 8 is newer than both Windows 98 and Windows 2000. Does anyone remember the Y2K problem. Anyone????? They worked out naming things properly (where computers are involved) was a big problem in the 1960's. But we still only allocated 3 bytes for the version of C or something...?
MikeSchurman 7y ago
parent means if code starts using C99 features that won't work in C89, then the person with a C89 compiler needs to upgrade their compiler.

WalterSear 7y ago

Different, yes, but the difference is quantitative, not qualitative. Once a transpile step is required, it doesn't make as much of a difference what is on the other side.

WorldMaker 7y ago

C to a lesser extent does have the same trailing problem with end users as well in libc / VCRUNTIME and other standard lib bundles. On Windows VCRUNTIME installs are mostly painless, easily backgrounded, and people don't realize they sometimes have as many as 100s of different versions installed side-by-side because every game installed wants a slightly different version. But on Linux, it's often as much as like three-fourths of the reason that code needs to be rebuilt so often for every possible different Linux distribution because most distributions lock to only a single libc and prefer every app dynamically link that specific libc. Apps get held back by distributions slow to adopt libc updates all the time in Linux, and app devs try to stick to common libc versions based on distribution popularity (user preference), which isn't dissimilar to the lagging browser problem. (Then there are arguments about statically bundling libc / VCRUNTIME, etc.) It's not as bad as JS land on average, but that doesn't mean that C is immune to the same problem. As soon as you are dealing with shared libraries / platforms / runtimes, you run into having to deal with what users are willing to install (and practically no platform is immune, depending on trade-offs one is willing to take).