4 ms·

It is funny to me that people extrapolate "code" as just our best way of representing computational instructions we want done that we can express in natural lan

by hacknat 13y ago

It is funny to me that people extrapolate "code" as just our best way of representing computational instructions we want done that we can express in natural language. I agree with you that sometimes this isn't true. Sometimes I read code and I can't express what it does in English. I could roughly describe what it does, but I can't communicate all of its subtlety. The limitations of "no code" isn't the theoretical limits of AI it's human!

jtheory 13y ago
Poorly-written code (especially if the reader doesn't have a good grasp of the coding language) can be very confusing, but it will still almost never be ambiguous. If you try taking some well-written code and converting it to natural language with utterly no ambiguity, you'll quickly find that: - the natural language version is far, far longer and harder to read - it takes a lot of work to remove all ambiguities, and you will find yourself wanting to put a dictionary with strict rules and extensions -- totally unlike a REAL dictionary. => Word "allow" will always mean generally the 1st (verb) definition in Mirriam-Webster online, and will further imply that if the subsequent test (see below for definition) succeeds (definition below), then execution (see below) will continue; if the test fails (see below) then standard error (see below) handling procedure (see below) will be followed, in which... It's ridiculous, isn't it? You'd be inventing a new (but probably horrible) coding language, not using natural language at all any more. The thing about natural language code -- it does exist, sort of. Think about the checklists that airline pilots run through before takeoff, for a good example. That's sort of natural language process execution... but it's the same every time, the context is known (it's being executed by an airline pilot sitting in the cockpit of a specific airplane), the pilot is trained such that s/he has practiced running the checklist many, many times before doing it "for real". And: it's a friggin' checklist. Is logic in there whatsoever, beyond "if this is true, continue; if not, abort"? The limitations on it are incredible, and we still have human beings executing that "code"; they are not automated. The answer to one of the questions might unexpectedly be "sort of", or "yes, value in the safe range, but why is it steadily dropping?"
- dllthomas 13y ago
  Code can certainly be ambiguous. We call it unspecified behavior, undefined behavior, or race conditions, depending.
  - klibertp 13y ago
    A race condition is a set of (possibly very many) very well defined states - or at least defined as well as everything else in the program. Someone should discover some algebra for working with concurrent processes and the race conditions would go away! (the second sentence is a joke.)
    - dllthomas 13y ago
      Ambiguity is quite frequently between several well-defined states. A significant difference between race conditions and natural language ambiguity is that in the latter we typically expect resolution to happen favorably when the interaction is cooperative - which is not a feature of race conditions in the general or typical case. I think it's still fair to say that this is not an essential feature of ambiguity, though, which is why I included it as an example. In the case of a race condition, the relevant pieces of the language do not uniquely define a single result - additional context may.
    - bcoates 13y ago
      A simple data race in C11/C++11 is undefined behavior, it doesn't have to result in any well-defined state that you might get by interleaving the execution of threads. I think this has been on HN already: http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/why_undef.html http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/why_undef.ht... Essentially it has to be that way, or on some architectures every access to a potentially shared variable would have to be wrapped in fences by the compiler.
      - dllthomas 13y ago
        Strictly speaking, it could be implementation-defined behavior.

by hacknat 13y ago

jtheory 13y ago

Poorly-written code (especially if the reader doesn't have a good grasp of the coding language) can be very confusing, but it will still almost never be ambiguous. If you try taking some well-written code and converting it to natural language with utterly no ambiguity, you'll quickly find that: - the natural language version is far, far longer and harder to read - it takes a lot of work to remove all ambiguities, and you will find yourself wanting to put a dictionary with strict rules and extensions -- totally unlike a REAL dictionary. => Word "allow" will always mean generally the 1st (verb) definition in Mirriam-Webster online, and will further imply that if the subsequent test (see below for definition) succeeds (definition below), then execution (see below) will continue; if the test fails (see below) then standard error (see below) handling procedure (see below) will be followed, in which... It's ridiculous, isn't it? You'd be inventing a new (but probably horrible) coding language, not using natural language at all any more. The thing about natural language code -- it does exist, sort of. Think about the checklists that airline pilots run through before takeoff, for a good example. That's sort of natural language process execution... but it's the same every time, the context is known (it's being executed by an airline pilot sitting in the cockpit of a specific airplane), the pilot is trained such that s/he has practiced running the checklist many, many times before doing it "for real". And: it's a friggin' checklist. Is logic in there whatsoever, beyond "if this is true, continue; if not, abort"? The limitations on it are incredible, and we still have human beings executing that "code"; they are not automated. The answer to one of the questions might unexpectedly be "sort of", or "yes, value in the safe range, but why is it steadily dropping?"

dllthomas 13y ago
Code can certainly be ambiguous. We call it unspecified behavior, undefined behavior, or race conditions, depending.
- klibertp 13y ago
  A race condition is a set of (possibly very many) very well defined states - or at least defined as well as everything else in the program. Someone should discover some algebra for working with concurrent processes and the race conditions would go away! (the second sentence is a joke.)
  - dllthomas 13y ago
    Ambiguity is quite frequently between several well-defined states. A significant difference between race conditions and natural language ambiguity is that in the latter we typically expect resolution to happen favorably when the interaction is cooperative - which is not a feature of race conditions in the general or typical case. I think it's still fair to say that this is not an essential feature of ambiguity, though, which is why I included it as an example. In the case of a race condition, the relevant pieces of the language do not uniquely define a single result - additional context may.
  - bcoates 13y ago
    A simple data race in C11/C++11 is undefined behavior, it doesn't have to result in any well-defined state that you might get by interleaving the execution of threads. I think this has been on HN already: http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/why_undef.html http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/why_undef.ht... Essentially it has to be that way, or on some architectures every access to a potentially shared variable would have to be wrapped in fences by the compiler.
    - dllthomas 13y ago
      Strictly speaking, it could be implementation-defined behavior.