5 ms·

Wait, what? The code is a translation of a requirement to an implementation. The comment describes the requirement. The only problem with competing sources of a

Wait, what? The code is a translation of a requirement to an implementation. The comment describes the requirement. The only problem with competing sources of authority is when the comment disagrees with the real requirements of the programmer/business/whatever. As another example, what if it were a method name instead of a comment? function printEveryOtherLine(myStringArray) { for (var i = 0; i < myStringArray.length; i++) { console.log(myStringArray[i]); } } Is your argument that the method name is incorrect because the code dictates a different behavior?

computerphage 10y ago
This is the almost the same example. Function names also don't execute. The parent's point was that if the code has been tested or was considered working, and then you noticed this in the code, you should think twice before "fixing" the behavior to match the comment or function name.
- choward 10y ago
  Then why even name anything? Are you saying I should just name my functions and variables a, b, c, d, etc.?
  - eternalban 10y ago
    Of course names are important to us, human programmers, but the compiler doesn't given an 'f'.
    - posterboy 10y ago
      We use mnemonics, because we can't remember numbers as well, but to the compiler, addresses are pretty much like names.
      - eternalban 10y ago
        It's a bit more than that. Function names are precisely encapsulation of the intent of the function. And unlike comments, function names are not subject to rot. Also addresses are not like names. As with names in general, a name can refer to more than one object. (Consider modules, for example.)
        computerphage 10y ago
        > function names are not subject to rot I don't agree with this. I think often a function will drift from its name if functionality is added to an aspect of its implementation or because of refactoring.
        douche 10y ago
        And thus it's important to also rename things when refactoring, or else you get awful confused when your Foobinator(x) function returns you a Splunkinated value, or your FrobbleTheFribbets() call also woggles the wiggles.
        posterboy 10y ago
        >Function names are precisely encapsulation of the intent of the function that's a rosy way to say, names entail a message. An Address can also be computed, your argument is invalid.
  - the_af 10y ago
    That's an extreme position. Function names are a valuable hint of what the function is supposed to do. But if the name doesn't match the implementation, which one is wrong? We don't know.
    - foota 10y ago
      But you do know something might be off, which is better than not knowing when something is off.
      - derefr 10y ago
        I was thinking the same from the root of this argument: "redundant encoding" isn't a way to automatically fix errors, but rather only a way to detect errors. Like a one-bit Error Correcting Code: the fact that the parity bit is wrong tells you something is corrupt, but it doesn't let you know what the right value should be. There's one useful thing you can avoid doing in response to such an error being detected: not rely blindly on either the implementation or the specification being correct, but instead check them both.
        foota 10y ago
        In fact, I was reading about the bitcoin redemption vulnerability in stripe, and how often times security bugs are discovered by "huh, that's weird" rather than by eureka, and this ECC (error correcting code, see the pun?) seems like it would help to provoke that, and likely validates the amount of effort that it takes.
      - the_af 10y ago
        Fully agreed. That's why I consider descriptive identifiers a valuable hint.
    - lucb1e 10y ago
      > We don't know. I don't know about you but I certainly know that if a printLine function accidentally does something else, it's definitely the code that's wrong and not the function name.
ifdefdebug 10y ago
Well no, I think the argument is that this kind of comment gets outdated easily, so if the program works as expected, the comment is probably outdated (new requirement, the program was changed to print every line, forgetting about the comment). If the program does not work as expected, then it's a bug and the comment is still valid. This does not happen in your function name example: if the program requirement changed to print every line, no sane programmer would change the code in this function, they'd write a new function printEveryLine() instead and use that. So you can be pretty sure this is a bug.
- dsp1234 10y ago
  no sane programmer would If this were only true.
- alexbecker 10y ago
  > If the program requirement changed to print every line, no sane programmer would change the code in this function, they'd write a new function printEveryLine() instead and use that. So you can be pretty sure this is a bug. Unfortunately many programmers seem not to be sane.
- cmontella 10y ago
  > if the program requirement changed to print every line, no sane programmer would change the code in this function they'd write a new function printEveryLine() instead and use that. I'm not sure I understand the distinction you are making here, so I'd like to try and understand. From my perspective, function names are just another form of comment. After all, in many languages, as soon as you press "compile", your function names are mangled into something a machine can understand. So you feel that programmers are more inclined to treat the function name as an authority, as opposed to a comment. Is that an accurate? I'm curious what lead you to this conclusion.
  - ifdefdebug 10y ago
    A function can be called from different places, maybe it will be used in code not yet written. So a programmer has a need to print every line. The code to be changed calls printEveryOtherLine. They won't change that function to print every line, because they know that would break things elsewhere.
lnanek2 10y ago
It is possible to make the text a test spec that is then verified. See: http://jenisys.github.io/behave.example/tutorials/tutorial01.html http://jenisys.github.io/behave.example/tutorials/tutorial01... His complaint is that it isn't being done here, so all the prose is jut going to get out of date and incorrect, and meanwhile you have to write everything twice for no benefit.
- the_af 10y ago
  The problem I see with verifying comments in English (that is, using English as a specification language) is that it's impossible in the general case. So you must, in practice, use a subset of English grammar/nouns which turns into a formal specification language. In turn, this becomes a programming language of sorts, and then we stray away from the goal of "programming languages for humans". I'd love to be proven wrong, but I think the problem is that this goal itself is mistaken. If we can formally specify something using a language X, this necessarily becomes a language not "for humans" -- i.e. a formal language that doesn't follow the rules of natural language and that we must be trained in. Natural language is notoriously bad at unambiguous specification.
  - posterboy 10y ago
    And then you'd need to describe the specification language and how would that be verified? I suppose that English is imperfect and could use improvements. Ideally those two would converge. That would solve problems about the interpretation of laws, as well. How would that convergence work? To answer that you'd have to know how language is acquired in the first place. I suppose some form of self-reference in the language that mirrors some of Chomskie's stipulated universal grammar, if it exists.
  - derefr 10y ago
    I think there's one kind of "specification language" that works completely unlike programming itself—and that's the interactive form of specification known as requirements-gathering that occurs in the conversation between a contract programmer and their client. I could see potential in a function-level spec in the form of an append-only transcript, where only one line can be added at a time. So you (with your requirements-specifier hat on) write a line of spec; and then you (as the programmer) write a function that only does what the spec says, in the stupidest way possible; and then you put on the other hat and add another line to the spec to constrain yourself from doing things so stupidly; and on and on. The same sort of granularity as happens when doing TDD by creating unit tests that fail; but these "tests" don't need to execute, human eyes just need to check the function against them. --- On another tangent: I've never seen anyone just "bite the bullet" on this, acknowledge that what they want is redundant effort, and explicitly design a programming language that forces you to program everything twice in two separate ways. It seems to me that it'd actually be a useful thing to have around, especially if it enforced two very different programming paradigms for the two formalisms—one functional and one procedural, say; or one dataflow-oriented ala APL or J, and the other actor-modelled ala Erlang. Seems like something NASA would want to use for high-assurance systems, come to think of it. They get part-way there by making several teams write several isolated implementations of their high-assurance code—but it will likely end up having the same flaws in the same places, given that there's nothing forcing them to use separate abstractions.

computerphage 10y ago

This is the almost the same example. Function names also don't execute. The parent's point was that if the code has been tested or was considered working, and then you noticed this in the code, you should think twice before "fixing" the behavior to match the comment or function name.

choward 10y ago
Then why even name anything? Are you saying I should just name my functions and variables a, b, c, d, etc.?
- eternalban 10y ago
  Of course names are important to us, human programmers, but the compiler doesn't given an 'f'.
  - posterboy 10y ago
    We use mnemonics, because we can't remember numbers as well, but to the compiler, addresses are pretty much like names.
    - eternalban 10y ago
      It's a bit more than that. Function names are precisely encapsulation of the intent of the function. And unlike comments, function names are not subject to rot. Also addresses are not like names. As with names in general, a name can refer to more than one object. (Consider modules, for example.)
      - computerphage 10y ago
        > function names are not subject to rot I don't agree with this. I think often a function will drift from its name if functionality is added to an aspect of its implementation or because of refactoring.
        douche 10y ago
        And thus it's important to also rename things when refactoring, or else you get awful confused when your Foobinator(x) function returns you a Splunkinated value, or your FrobbleTheFribbets() call also woggles the wiggles.
      - posterboy 10y ago
        >Function names are precisely encapsulation of the intent of the function that's a rosy way to say, names entail a message. An Address can also be computed, your argument is invalid.
- the_af 10y ago
  That's an extreme position. Function names are a valuable hint of what the function is supposed to do. But if the name doesn't match the implementation, which one is wrong? We don't know.
  - foota 10y ago
    But you do know something might be off, which is better than not knowing when something is off.
    - derefr 10y ago
      I was thinking the same from the root of this argument: "redundant encoding" isn't a way to automatically fix errors, but rather only a way to detect errors. Like a one-bit Error Correcting Code: the fact that the parity bit is wrong tells you something is corrupt, but it doesn't let you know what the right value should be. There's one useful thing you can avoid doing in response to such an error being detected: not rely blindly on either the implementation or the specification being correct, but instead check them both.
      - foota 10y ago
        In fact, I was reading about the bitcoin redemption vulnerability in stripe, and how often times security bugs are discovered by "huh, that's weird" rather than by eureka, and this ECC (error correcting code, see the pun?) seems like it would help to provoke that, and likely validates the amount of effort that it takes.
    - the_af 10y ago
      Fully agreed. That's why I consider descriptive identifiers a valuable hint.
  - lucb1e 10y ago
    > We don't know. I don't know about you but I certainly know that if a printLine function accidentally does something else, it's definitely the code that's wrong and not the function name.

ifdefdebug 10y ago

Well no, I think the argument is that this kind of comment gets outdated easily, so if the program works as expected, the comment is probably outdated (new requirement, the program was changed to print every line, forgetting about the comment). If the program does not work as expected, then it's a bug and the comment is still valid. This does not happen in your function name example: if the program requirement changed to print every line, no sane programmer would change the code in this function, they'd write a new function printEveryLine() instead and use that. So you can be pretty sure this is a bug.

dsp1234 10y ago
no sane programmer would If this were only true.
alexbecker 10y ago
> If the program requirement changed to print every line, no sane programmer would change the code in this function, they'd write a new function printEveryLine() instead and use that. So you can be pretty sure this is a bug. Unfortunately many programmers seem not to be sane.
cmontella 10y ago
> if the program requirement changed to print every line, no sane programmer would change the code in this function they'd write a new function printEveryLine() instead and use that. I'm not sure I understand the distinction you are making here, so I'd like to try and understand. From my perspective, function names are just another form of comment. After all, in many languages, as soon as you press "compile", your function names are mangled into something a machine can understand. So you feel that programmers are more inclined to treat the function name as an authority, as opposed to a comment. Is that an accurate? I'm curious what lead you to this conclusion.
- ifdefdebug 10y ago
  A function can be called from different places, maybe it will be used in code not yet written. So a programmer has a need to print every line. The code to be changed calls printEveryOtherLine. They won't change that function to print every line, because they know that would break things elsewhere.

lnanek2 10y ago

It is possible to make the text a test spec that is then verified. See: http://jenisys.github.io/behave.example/tutorials/tutorial01.html http://jenisys.github.io/behave.example/tutorials/tutorial01... His complaint is that it isn't being done here, so all the prose is jut going to get out of date and incorrect, and meanwhile you have to write everything twice for no benefit.

the_af 10y ago
The problem I see with verifying comments in English (that is, using English as a specification language) is that it's impossible in the general case. So you must, in practice, use a subset of English grammar/nouns which turns into a formal specification language. In turn, this becomes a programming language of sorts, and then we stray away from the goal of "programming languages for humans". I'd love to be proven wrong, but I think the problem is that this goal itself is mistaken. If we can formally specify something using a language X, this necessarily becomes a language not "for humans" -- i.e. a formal language that doesn't follow the rules of natural language and that we must be trained in. Natural language is notoriously bad at unambiguous specification.
- posterboy 10y ago
  And then you'd need to describe the specification language and how would that be verified? I suppose that English is imperfect and could use improvements. Ideally those two would converge. That would solve problems about the interpretation of laws, as well. How would that convergence work? To answer that you'd have to know how language is acquired in the first place. I suppose some form of self-reference in the language that mirrors some of Chomskie's stipulated universal grammar, if it exists.
- derefr 10y ago
  I think there's one kind of "specification language" that works completely unlike programming itself—and that's the interactive form of specification known as requirements-gathering that occurs in the conversation between a contract programmer and their client. I could see potential in a function-level spec in the form of an append-only transcript, where only one line can be added at a time. So you (with your requirements-specifier hat on) write a line of spec; and then you (as the programmer) write a function that only does what the spec says, in the stupidest way possible; and then you put on the other hat and add another line to the spec to constrain yourself from doing things so stupidly; and on and on. The same sort of granularity as happens when doing TDD by creating unit tests that fail; but these "tests" don't need to execute, human eyes just need to check the function against them. --- On another tangent: I've never seen anyone just "bite the bullet" on this, acknowledge that what they want is redundant effort, and explicitly design a programming language that forces you to program everything twice in two separate ways. It seems to me that it'd actually be a useful thing to have around, especially if it enforced two very different programming paradigms for the two formalisms—one functional and one procedural, say; or one dataflow-oriented ala APL or J, and the other actor-modelled ala Erlang. Seems like something NASA would want to use for high-assurance systems, come to think of it. They get part-way there by making several teams write several isolated implementations of their high-assurance code—but it will likely end up having the same flaws in the same places, given that there's nothing forcing them to use separate abstractions.