7 ms·

> 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”, i

> 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...
        catnaroek 10y ago
        > 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. That's because, in general, any random system you can come up with is crap. Even if evolution was good enough for Nature, we need Intelligent Design. (Or maybe not for you. Maybe you're happy with crap programs that only “work” in a statistical sense. I'm not.) > 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. Where you see a limitation, I see a source of relief from not having to explore a design space that mostly consists of crap I wouldn't want to use, let alone maintain.

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...
      - catnaroek 10y ago
        > 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. That's because, in general, any random system you can come up with is crap. Even if evolution was good enough for Nature, we need Intelligent Design. (Or maybe not for you. Maybe you're happy with crap programs that only “work” in a statistical sense. I'm not.) > 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. Where you see a limitation, I see a source of relief from not having to explore a design space that mostly consists of crap I wouldn't want to use, let alone maintain.