4 ms·

> At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized f

by adev_ 7y ago

> At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized for a user to know they're using it correctly." That's a bullshit argument very close to FUD. You don't need to know the 1400 pages of the C++ standard to use safely a subset of it. Specially with proper tooling to help you. Do you really think that every web frontend developer knows every W3C/ECMA standard every time they create a website ? Or that they have even an idea of feature the complexity of the Web browser they use. One tips: no they don't.

shadowgovt 7y ago
Those standards are built to be default-sound. It shouldn't be possible to do wild memory access in JavaScript or via novel application of CSS or DOM structure. Most importantly, if someone does find a way, it's an error in either the spec or the browser implementation. It's not flagged as "undefined behavior" and we go on with the assumption some web pages just break your browser or the OS hosting it. I can tolerate a thousand-page spec for a system that can't crash unsafely; it's a much bigger risk for one with unchecked pointer indirection as a feature.
- adev_ 7y ago
  > It shouldn't be possible to do wild memory access in JavaScript or via novel application of CSS or DOM structure. This is a narrow view where you focus only on memory safety and buffer overflow. Undefined Behaviours goes way wilder than that. Many problems coming by UBs do not goe into any crash, just wrong results and wrong behaviour which is something even worst. And currently, JavaScript is full of that. Almost everything that JS can not handle (or do not know how to handle is undefined) or purely implementation specific.
  - shadowgovt 7y ago
    And for JavaScript, that space doesn't include buffer overruns or memory safety, unless you do something very exotic and implement your own indirected memory access in JavaScript (in which case, you've sort of dug your own grave). because undefined behavior literally means undefined behavior, C++ gets to bring to the table all of the failure modes JavaScript brings to the table in addition to the plethora of ways unchecked memory indirection can go wrong. There are circumstances where you want the features C++ brings to solve a problem. But solving a problem with dynamite is still solving a problem with dynamite; there's a lot more ways it can go wrong than solving the problem with a steam drill, to torture an analogy a bit.
    - adev_ 7y ago
      > But solving a problem with dynamite is still solving a problem with dynamite; there's a lot more ways it can go wrong than solving the problem with a steam drill, to torture an analogy a bit. Excepted that a language is not absolute, is not dynamite or not dynamite. It is what you do of it depending of the subset you use. C++ is not exception.
      - shadowgovt 7y ago
        Agreed. But I won't reach for a language that lets me treat all my program's working memory as an undifferentiated integer-addressable array of bytes if I don't need that to solve the problems I'm trying to solve. ... which goes back to the topic of the HN post; that's only one way to look at the state of a running program, and it's a way that has strengths and weaknesses. The utility of it comes at the cost of the program failing in ways programs in other languages structurally cannot fail (unless you do something truly exotic, like implement a subset of a C++ compiler or interpreter in that language).
        spopejoy 7y ago
        C++ has always been the language that "has a safe subset to use but nobody can agree what that subset is". JS is ... well, JS This is at least for me the first time I've seen them discussed in the same breath, which is revolutionary: C++ the language bringing a blue screen to a desktop near you; JS the language bringing your startup to its knees. I guess I never realized that while they are polar opposites, there are probably some subtle cultural similarities that would make for some hilarious unearthing

by adev_ 7y ago

shadowgovt 7y ago

Those standards are built to be default-sound. It shouldn't be possible to do wild memory access in JavaScript or via novel application of CSS or DOM structure. Most importantly, if someone does find a way, it's an error in either the spec or the browser implementation. It's not flagged as "undefined behavior" and we go on with the assumption some web pages just break your browser or the OS hosting it. I can tolerate a thousand-page spec for a system that can't crash unsafely; it's a much bigger risk for one with unchecked pointer indirection as a feature.

adev_ 7y ago
> It shouldn't be possible to do wild memory access in JavaScript or via novel application of CSS or DOM structure. This is a narrow view where you focus only on memory safety and buffer overflow. Undefined Behaviours goes way wilder than that. Many problems coming by UBs do not goe into any crash, just wrong results and wrong behaviour which is something even worst. And currently, JavaScript is full of that. Almost everything that JS can not handle (or do not know how to handle is undefined) or purely implementation specific.
- shadowgovt 7y ago
  And for JavaScript, that space doesn't include buffer overruns or memory safety, unless you do something very exotic and implement your own indirected memory access in JavaScript (in which case, you've sort of dug your own grave). because undefined behavior literally means undefined behavior, C++ gets to bring to the table all of the failure modes JavaScript brings to the table in addition to the plethora of ways unchecked memory indirection can go wrong. There are circumstances where you want the features C++ brings to solve a problem. But solving a problem with dynamite is still solving a problem with dynamite; there's a lot more ways it can go wrong than solving the problem with a steam drill, to torture an analogy a bit.
  - adev_ 7y ago
    > But solving a problem with dynamite is still solving a problem with dynamite; there's a lot more ways it can go wrong than solving the problem with a steam drill, to torture an analogy a bit. Excepted that a language is not absolute, is not dynamite or not dynamite. It is what you do of it depending of the subset you use. C++ is not exception.
    - shadowgovt 7y ago
      Agreed. But I won't reach for a language that lets me treat all my program's working memory as an undifferentiated integer-addressable array of bytes if I don't need that to solve the problems I'm trying to solve. ... which goes back to the topic of the HN post; that's only one way to look at the state of a running program, and it's a way that has strengths and weaknesses. The utility of it comes at the cost of the program failing in ways programs in other languages structurally cannot fail (unless you do something truly exotic, like implement a subset of a C++ compiler or interpreter in that language).
      - spopejoy 7y ago
        C++ has always been the language that "has a safe subset to use but nobody can agree what that subset is". JS is ... well, JS This is at least for me the first time I've seen them discussed in the same breath, which is revolutionary: C++ the language bringing a blue screen to a desktop near you; JS the language bringing your startup to its knees. I guess I never realized that while they are polar opposites, there are probably some subtle cultural similarities that would make for some hilarious unearthing