undefined | Better HN

0 pointsJensson4y ago0 comments

> there is one true noation (or rather, a separate one for each language) that is unambiguous and clearly defined.

This is such a disingenuous take. How many of the source code files you write are 100% self contained and well defined? I'd bet not a single one of them are. You reference libraries, you depend on specific compiler/runtime/OS versions, you reference other files etc. If you take a look at any of these scientific papers you call "badly defined", did you really go through all of the referenced papers and look if they defined the things you didn't get? If not then you can't be sure that the paper uses undefined notation. If you argue that it is too much work to go through that many references, well that is what you would have to do to understand one of your program files.

0 comments

4 comments · 1 top-level

throwaway313384y ago· 3 in thread

One can look at the source code to a program, the libraries it uses, the compiler for the language, and the ISA spec for the machine language the compiler generates. You can know that there are no hidden unspecified quantities because programs can't work without being specified.

When you get down to the microcode of the CPU that implements the ISA you might have an issue if it's ill-specified. You might be talking about an ISA like RISC-V, though, specified at a level sufficient to go down to the gates. You might be talking about an ISA like 6502 where the gate-level implementations have been reverse-engineered.

You can take programming all the way down boolean logic if you need to and the tools are readily available. They don't rely on you "just knowing" something.

JenssonOP4y ago

> One can look at the source code to a program, the libraries it uses, the compiler for the language, and the ISA spec for the machine language the compiler generates. You can know that there are no hidden unspecified quantities because programs can't work without being specified.

I doubt you actually can do that and understand it all. A computer can do it, but I doubt you the human can do that and get a perfect picture of any non trivial program without making errors. Human math is a human language first and foremost, its grammar is human language which is used to define things and symbols. This lets us write things that humans can actually read and understand the entirety of, unlike a million lines of code or cpu instructions.

Show me a program written by 10 programmers over 10 years and I doubt anyone really understands all of it. But we have mathematical fields that hundreds of mathematicians have written over centuries, and people still are able to understand it all perfectly. It is true that a computer can easily read a computer program, but since we are arguing about teaching humans you would need to show evidence that humans can actually read and understand complex code well.

pjc504y ago

> because programs can't work without being specified.

Someone hasn't read the C spec, with all its specified as undefined behavior.

Programs working on real systems is very different from those systems being formally specified. I suspect that if you only had access to the pile of documentation and no real computer system - if you were an alien trying to reconstruct it, for example - you'd hit serious problems.

throwaway313384y ago

Undefined behavior isn't a feature. A spec isn't an implementation, either.

All behavior in an implementation can be teased-out if given sufficient time.

> if you were an alien trying to reconstruct it, for example - you'd hit serious problems.

I can't speak to alien minds. Considering the feats of reverse-engineering I've seen in the IT world (software security, semiconductor reverse-engineering) or cryptography (the breaking the Japanese Purple cipher in WWII, for example) I think it's safe to say humans are really, really good at reverse-engineering other human-created systems from close-to-nothing. Starting with documentation would be a step-up.

3 more replies

j / k navigate · click thread line to collapse