4 ms·

That sounds like the hallmark of a defective language to me.

by thfuran 3y ago

gpderetta 3y ago
most languages don't even have a specification.
- pizlonator 3y ago
  Yes! This is much under appreciated. Usually, it’s just some core calculus of the language that is rigorously specified and the rest is hand waving. There are some exceptions like JS. But even Java has the problem that if you just implement what’s in the spec, you won’t be able to run anything meaningful unless you also do things exactly how the JDK would. You can find out what the JDK does by reading its code and writing test cases and I think that’s what folks do, if they want to be compatible. UB and memory safety are orthogonal. If we specified formally and super rigorously that a pointer is an integer and that memory is an array of bytes, we could have a UB-free language but memory safety would still be on fire.
  - gpderetta 3y ago
    Everything is memory safe if your only datatype is uint8_t /s
    - pizlonator 3y ago
      Yup :-)
  - tialaramex 3y ago
    > If we specified formally and super rigorously that a pointer is an integer and that memory is an array of bytes, we could have a UB-free language That's PVI (Provenance Via Integers) and it's a performance disaster. If anything in memory might be pointed to, almost all the nice modern optimisations aren't correct. It is really popular with a certain kind of "Portable assembler" programmer, who typically has no idea how the machine actually works, nor how their language is defined but is very confident the nonsense they're writing ought to do what they wanted it to do. So, the "bad" news is that you can't have this, your compiler vendor won't make it, and the "good" news is that you'd have hated it anyway which is why they won't make it.
    - lifthrasiir 3y ago
      I don't think it is same as PVI, because i) there are a lot of possible non-determinisms still allowed and thus to be exploited, and ii) the specification will have to require only the observational equivalence anyway because every optimization will be invalid otherwise. It should be definitely possible to define a very precise machine without actually mandating PVI.
- thfuran 3y ago
  That is an even more grievous deficiency than an inadequate spec, but it hardly means that a bad spec is good.
- vlovich123 3y ago
  The issue isn't that C++'s specification has an issue. The issue is that the same issue resulted in no CVE for any C++ vendor. And most languages tend to have 1 reference de facto implementation whereas C and C++ are quite unique in having 2-4 mainstream ones in regular use (& the C++ frontend is ridiculously complex). Java, Python and C# are the only other mainstream languages with a formal spec and only Python that I know of maybe has alternate frontends (there are multiple runtime implementations for C# and Java but I don't believe the language -> bytecode part is different). JS is maybe closer on this front but it's also quite old & JS is also a mess & a lot of development has shifted to TS as the language for those reasons & TS only has 1 frontend & no formal spec.
  - Sindisil 3y ago
    There are at least two Java bytecode compilers. Though javac is obviously the "reference", there is also egc. It's used primarily by IDEs and editor plugins (like Eclipse, from whence it came, and the RedHat Java plugin for VS Code). Still, if memory serves there have been a handful of cases where egc's implementation of the spec differed from javac's with resulting fixes in javac itself (though I don't have sources at hand, so perhaps I misremember).
paulddraper 3y ago
Loads of very popular languages don't have formal specifications at all: * Rust * Python * Ruby * PHP * TypeScript
- steveklabnik 3y ago
  Ruby is weirder than that: it has an ISO standard, but that standard is 100% irrelevant.
  - paulddraper 3y ago
    Similar to TypeScript, which has a standard. [1] Last updated Jan 2016. [1] https://javascript.xgqfrms.xyz/pdfs/TypeScript%20Language%20Specification.pdf https://javascript.xgqfrms.xyz/pdfs/TypeScript%20Language%20...
  - syockit 3y ago
    Funny, Matz mentioned about it in RubyKaigi 2023 keynote, that it was made with the hope that it gets wider adoption in the industry, maybe even used in technical exams. It didn't get the expected result and he felt like it was a waste of time and effort.
    - steveklabnik 3y ago
      I'll have to track that down! This is a bit of a spicy take, but I do think of the Ruby ISO spec whenever people say that Rust needs to have one or else it won't get real adoption...
      - tialaramex 3y ago
        ISO - and more specifically SC22 of JTC1 which is where a programming language ISO committee would live - is a terrible place to develop anything like this. It's almost designed to be unsuitable, and the insane thing is that JTC1 wasn't even created until 1987. If you told me it was from the 1960s I'd say maybe they didn't know any better, but in 1987 the IETF is already running. WG21 (the C++ Standards Committee, in JTC1/SC22) took until the pandemic forced them to to stop insisting on 100% in-person meetings to make decisions. Here's my line in the sand: After the Mother of All Demos, if you're trying to agree things internationally and you are physically moving people to a location to do that you're doing it wrong, but maybe you don't know that yet. After JIPS ceases to be a pilot project, not knowing you're doing it wrong means you're grossly incompetent. Those two dates are somewhat arbitrary, I picked them deliberately but I can entertain other nearby events for the same purpose. In particular if you're in Asia or Africa the JIPS date seems very arbitrary, I pick it because in my opinion this outcome (The United Kingdom's tertiary education will use IP not X.series standards) firmly means the Third Network will be the Internet not the X.25 standard. X.25 can win if only the Americans do IP, but it can't once IP spreads and that's what JIPS is. I'm far from convinced Rust should have standardization via some SDO, but if it did need that then I'm sure ISO is the last place to go. ETSI isn't great, but it's already better than JTC1. If some corporates insist on an ISO document, mint the document somewhere else and just get ISO to put their stamp on it, have the corp. pay for that - but tell anybody who cares to ignore the stupid ISO document. You (Steve) undoubtedly know that C++ 23 is a thing, they signed off on it mostly in 2022 and a little bit of 2023, but because ISO is awful actually ISO/IEC 14882:2023 doesn't exist, they are still working through the tedious process of agreeing to publish a document everybody settled on twelve months or more ago. This process was fine for, I dunno, standardising how the plastic joints fit together on a water pipeline. Maybe it takes a few years to nail down exactly the text, you standardise it, nobody needs to revisit for decades at least. It's stupid for a programming language.

That sounds like the hallmark of a defective language to me.

gpderetta 3y ago

most languages don't even have a specification.

pizlonator 3y ago
Yes! This is much under appreciated. Usually, it’s just some core calculus of the language that is rigorously specified and the rest is hand waving. There are some exceptions like JS. But even Java has the problem that if you just implement what’s in the spec, you won’t be able to run anything meaningful unless you also do things exactly how the JDK would. You can find out what the JDK does by reading its code and writing test cases and I think that’s what folks do, if they want to be compatible. UB and memory safety are orthogonal. If we specified formally and super rigorously that a pointer is an integer and that memory is an array of bytes, we could have a UB-free language but memory safety would still be on fire.
- gpderetta 3y ago
  Everything is memory safe if your only datatype is uint8_t /s
  - pizlonator 3y ago
    Yup :-)
- tialaramex 3y ago
  > If we specified formally and super rigorously that a pointer is an integer and that memory is an array of bytes, we could have a UB-free language That's PVI (Provenance Via Integers) and it's a performance disaster. If anything in memory might be pointed to, almost all the nice modern optimisations aren't correct. It is really popular with a certain kind of "Portable assembler" programmer, who typically has no idea how the machine actually works, nor how their language is defined but is very confident the nonsense they're writing ought to do what they wanted it to do. So, the "bad" news is that you can't have this, your compiler vendor won't make it, and the "good" news is that you'd have hated it anyway which is why they won't make it.
  - lifthrasiir 3y ago
    I don't think it is same as PVI, because i) there are a lot of possible non-determinisms still allowed and thus to be exploited, and ii) the specification will have to require only the observational equivalence anyway because every optimization will be invalid otherwise. It should be definitely possible to define a very precise machine without actually mandating PVI.
thfuran 3y ago
That is an even more grievous deficiency than an inadequate spec, but it hardly means that a bad spec is good.
vlovich123 3y ago
The issue isn't that C++'s specification has an issue. The issue is that the same issue resulted in no CVE for any C++ vendor. And most languages tend to have 1 reference de facto implementation whereas C and C++ are quite unique in having 2-4 mainstream ones in regular use (& the C++ frontend is ridiculously complex). Java, Python and C# are the only other mainstream languages with a formal spec and only Python that I know of maybe has alternate frontends (there are multiple runtime implementations for C# and Java but I don't believe the language -> bytecode part is different). JS is maybe closer on this front but it's also quite old & JS is also a mess & a lot of development has shifted to TS as the language for those reasons & TS only has 1 frontend & no formal spec.
- Sindisil 3y ago
  There are at least two Java bytecode compilers. Though javac is obviously the "reference", there is also egc. It's used primarily by IDEs and editor plugins (like Eclipse, from whence it came, and the RedHat Java plugin for VS Code). Still, if memory serves there have been a handful of cases where egc's implementation of the spec differed from javac's with resulting fixes in javac itself (though I don't have sources at hand, so perhaps I misremember).

paulddraper 3y ago

Loads of very popular languages don't have formal specifications at all: * Rust * Python * Ruby * PHP * TypeScript

steveklabnik 3y ago
Ruby is weirder than that: it has an ISO standard, but that standard is 100% irrelevant.
- paulddraper 3y ago
  Similar to TypeScript, which has a standard. [1] Last updated Jan 2016. [1] https://javascript.xgqfrms.xyz/pdfs/TypeScript%20Language%20Specification.pdf https://javascript.xgqfrms.xyz/pdfs/TypeScript%20Language%20...
- syockit 3y ago
  Funny, Matz mentioned about it in RubyKaigi 2023 keynote, that it was made with the hope that it gets wider adoption in the industry, maybe even used in technical exams. It didn't get the expected result and he felt like it was a waste of time and effort.
  - steveklabnik 3y ago
    I'll have to track that down! This is a bit of a spicy take, but I do think of the Ruby ISO spec whenever people say that Rust needs to have one or else it won't get real adoption...
    - tialaramex 3y ago
      ISO - and more specifically SC22 of JTC1 which is where a programming language ISO committee would live - is a terrible place to develop anything like this. It's almost designed to be unsuitable, and the insane thing is that JTC1 wasn't even created until 1987. If you told me it was from the 1960s I'd say maybe they didn't know any better, but in 1987 the IETF is already running. WG21 (the C++ Standards Committee, in JTC1/SC22) took until the pandemic forced them to to stop insisting on 100% in-person meetings to make decisions. Here's my line in the sand: After the Mother of All Demos, if you're trying to agree things internationally and you are physically moving people to a location to do that you're doing it wrong, but maybe you don't know that yet. After JIPS ceases to be a pilot project, not knowing you're doing it wrong means you're grossly incompetent. Those two dates are somewhat arbitrary, I picked them deliberately but I can entertain other nearby events for the same purpose. In particular if you're in Asia or Africa the JIPS date seems very arbitrary, I pick it because in my opinion this outcome (The United Kingdom's tertiary education will use IP not X.series standards) firmly means the Third Network will be the Internet not the X.25 standard. X.25 can win if only the Americans do IP, but it can't once IP spreads and that's what JIPS is. I'm far from convinced Rust should have standardization via some SDO, but if it did need that then I'm sure ISO is the last place to go. ETSI isn't great, but it's already better than JTC1. If some corporates insist on an ISO document, mint the document somewhere else and just get ISO to put their stamp on it, have the corp. pay for that - but tell anybody who cares to ignore the stupid ISO document. You (Steve) undoubtedly know that C++ 23 is a thing, they signed off on it mostly in 2022 and a little bit of 2023, but because ISO is awful actually ISO/IEC 14882:2023 doesn't exist, they are still working through the tedious process of agreeing to publish a document everybody settled on twelve months or more ago. This process was fine for, I dunno, standardising how the plastic joints fit together on a water pipeline. Maybe it takes a few years to nail down exactly the text, you standardise it, nobody needs to revisit for decades at least. It's stupid for a programming language.