6 ms·

Things can hardly get any more structured than with a formal description using an equally formal language. Read the formal semantics of any programming language

Things can hardly get any more structured than with a formal description using an equally formal language. Read the formal semantics of any programming language (that happens to have one, like Standard ML), and you'll see why. --- @pron: Most humans only reason very sloppily, if they reason at all. I don't see any good reason to cater to the lowest common denominator.

pron 10y ago
But the intrinsic mathematical structure of the code by no means implies a mental structure compatible with the preferences of the human mind. I'm not saying there is no good mental structure, just it is not necessitated by the existence of the mathematical structure. The ML specification contains no reference to studies on human perception of code. I didn't say anything about the lowest common denominator or sloppy thinking, but there is no evidence that suggests that the human mind works equally well with any arbitrary mathematical structure. A mathematical structure caters neither to the lowest common denominator nor to the most disciplined thinkers, but is, as far as we know, arbitrary with respect to human cognition. If it caters to anyone in particular, it is by chance. My point is not that mathematical structure is bad -- far from it -- but there is no scientific basis to suggest a particular structure is particularly good. I read your comment as saying that a good mathematical structure implies a good mental structure, and I don't see what is the scientific justification for that claim.
- catnaroek 10y ago
  > The ML specification contains no reference to studies on human perception of code. Why would such a thing be necessary? Code isn't meant to be “perceived”, it's meant to be designed to meet a given specification.
  - pron 10y ago
    In order to be designed it must first be perceived and understood by the designer. Without considering the nature of the designer, how can you create a good interface between the designer and the program? As an extreme example, consider that life on earth displays all the desired qualities of programming -- abstraction, modularity and composition, maintainability, and it even supports complex ideas such as concurrency and meta-programming -- yet the language it is programmed in and evidently provides all these nice programming concepts looks nothing like ML. Why? Because it is optimized for a different kind of programmer. I think that if that programmer were forced to use ML, we wouldn't see any of those nice qualities or even a working system at all. This means that programming qualities are not attributes of the language but of the interaction between language and programmer.
    - catnaroek 10y ago
      > abstraction, modularity and composition, maintainability, and it even supports complex ideas such as concurrency and meta-programming Not at all. A while back, I had a kidney problem that somehow managed to first manifest itself as incessant headaches. So much for modularity.
      - pron 10y ago
        :) Modularity doesn't mean compartmentalization, or isolation, of failure, which is impossible in general (imagine a failure in the math module; checking that in other modules would be hard), although life achieves that relatively well, too. For example, a failure in a random number generation module will manifest itself in some strange ways in other parts of the system. In some ways, modularity and compartmentalization are sometimes at odds, with the latter requiring replicated functionality.
        catnaroek 10y ago
        > Modularity doesn't mean compartmentalization, or isolation, of failure, which is impossible in general It's not impossible. There are two ways to do it: (0) Static: Prevent the deployment of incorrectly constructed modules. Obviously impossible in an evolutionary setting (life). (1) Dynamic: Require every module to check its own inputs, internal state and output. Admittedly, this is at odds with performance, which arguably matters most in a competitive setting (life). In general, I wouldn't borrow inspiration from biology. Life forms are too busy trying to survive to bother being perfect. But programmers have a moral obligation to be Intelligent Designers.
        pron 10y ago
        Oh, I'm not suggesting we borrow inspiration from biology at all, just pointing out that desired programming qualities are not features of a language but of programmer-language interaction, that's all (as is evident by those qualities appearing when a different kind of programmer -- natural selection -- uses a programming language which is unlikely to produce the same qualities for human programmers; conversely those qualities would not be replicated if natural selection were forced to use ML). As to the question of failure isolation, your solutions do not work in general. Proving that a component is correct is intractable for all computational models (even finite state machines) in general[1]. When it's done in practice, it is done at great effort, only on very small codebases, and even then at great cost both in effort and in design limitations. Checking the correctness of your input dynamically is also impossible in general because to know whether any arbitrary output of a black box is correct, the entire functionality of that black box must be replicated. In practice, there are solutions of both kinds that are as effective as the effort required to produce them, which invariably means some compromise must be made. [1]: See my post on computational complexity results of software verification: http://blog.paralleluniverse.co/2016/07/23/correctness-and-complexity/ http://blog.paralleluniverse.co/2016/07/23/correctness-and-c...

pron 10y ago

But the intrinsic mathematical structure of the code by no means implies a mental structure compatible with the preferences of the human mind. I'm not saying there is no good mental structure, just it is not necessitated by the existence of the mathematical structure. The ML specification contains no reference to studies on human perception of code. I didn't say anything about the lowest common denominator or sloppy thinking, but there is no evidence that suggests that the human mind works equally well with any arbitrary mathematical structure. A mathematical structure caters neither to the lowest common denominator nor to the most disciplined thinkers, but is, as far as we know, arbitrary with respect to human cognition. If it caters to anyone in particular, it is by chance. My point is not that mathematical structure is bad -- far from it -- but there is no scientific basis to suggest a particular structure is particularly good. I read your comment as saying that a good mathematical structure implies a good mental structure, and I don't see what is the scientific justification for that claim.

catnaroek 10y ago
> The ML specification contains no reference to studies on human perception of code. Why would such a thing be necessary? Code isn't meant to be “perceived”, it's meant to be designed to meet a given specification.
- pron 10y ago
  In order to be designed it must first be perceived and understood by the designer. Without considering the nature of the designer, how can you create a good interface between the designer and the program? As an extreme example, consider that life on earth displays all the desired qualities of programming -- abstraction, modularity and composition, maintainability, and it even supports complex ideas such as concurrency and meta-programming -- yet the language it is programmed in and evidently provides all these nice programming concepts looks nothing like ML. Why? Because it is optimized for a different kind of programmer. I think that if that programmer were forced to use ML, we wouldn't see any of those nice qualities or even a working system at all. This means that programming qualities are not attributes of the language but of the interaction between language and programmer.
  - catnaroek 10y ago
    > abstraction, modularity and composition, maintainability, and it even supports complex ideas such as concurrency and meta-programming Not at all. A while back, I had a kidney problem that somehow managed to first manifest itself as incessant headaches. So much for modularity.
    - pron 10y ago
      :) Modularity doesn't mean compartmentalization, or isolation, of failure, which is impossible in general (imagine a failure in the math module; checking that in other modules would be hard), although life achieves that relatively well, too. For example, a failure in a random number generation module will manifest itself in some strange ways in other parts of the system. In some ways, modularity and compartmentalization are sometimes at odds, with the latter requiring replicated functionality.
      - catnaroek 10y ago
        > Modularity doesn't mean compartmentalization, or isolation, of failure, which is impossible in general It's not impossible. There are two ways to do it: (0) Static: Prevent the deployment of incorrectly constructed modules. Obviously impossible in an evolutionary setting (life). (1) Dynamic: Require every module to check its own inputs, internal state and output. Admittedly, this is at odds with performance, which arguably matters most in a competitive setting (life). In general, I wouldn't borrow inspiration from biology. Life forms are too busy trying to survive to bother being perfect. But programmers have a moral obligation to be Intelligent Designers.
        pron 10y ago
        Oh, I'm not suggesting we borrow inspiration from biology at all, just pointing out that desired programming qualities are not features of a language but of programmer-language interaction, that's all (as is evident by those qualities appearing when a different kind of programmer -- natural selection -- uses a programming language which is unlikely to produce the same qualities for human programmers; conversely those qualities would not be replicated if natural selection were forced to use ML). As to the question of failure isolation, your solutions do not work in general. Proving that a component is correct is intractable for all computational models (even finite state machines) in general[1]. When it's done in practice, it is done at great effort, only on very small codebases, and even then at great cost both in effort and in design limitations. Checking the correctness of your input dynamically is also impossible in general because to know whether any arbitrary output of a black box is correct, the entire functionality of that black box must be replicated. In practice, there are solutions of both kinds that are as effective as the effort required to produce them, which invariably means some compromise must be made. [1]: See my post on computational complexity results of software verification: http://blog.paralleluniverse.co/2016/07/23/correctness-and-complexity/ http://blog.paralleluniverse.co/2016/07/23/correctness-and-c...