4 ms·

1. Example is too simple, functions could modify anything in a model depending on context. 2. Good luck trying to optimise this (just merging all behaviours to

1. Example is too simple, functions could modify anything in a model depending on context. 2. Good luck trying to optimise this (just merging all behaviours together at the end does not equal optimisation). 3. You're just pushing the problem elsewhere - now I need to understand all behaviours from a black box, then wrap them, all while dealing with all the other wrappers people have already put in place. Imagine dealing with that complexity.

jerf 7y ago
Yeah. I like it from the point of view of "think new thoughts". It's an interesting thought. Let me highlight that with a few more words here to indicate that I don't just mean that as a polite sidebar; it really is an interesting thought. There may be something there. But as presented, the code complexity scales like a nightmare; it makes the worst Ruby monkeypatching look sane. Something would have to be done about that before even a toy implementation could be done, because this will fall apart very quickly. When you give away structured programming, you give away its benefits too. One of its benefits is that in a structured program, you can freeze a thread at any point and you have a clean mechanism for determining from there what its stack trace is, and all the relevant scopes it has access to and could be affecting it. In real code, this process may produce a very large number of variables and stack levels, but it'll still be a fraction of the program's possibilities. This is how structured programming helps us approach programs as structured slices of the code base, instead of a holistic view of the entire code base at once (this is the true reason goto-based code was so evil in the day; you could never do this analysis). This approach throws this away. That is not intrinsically wrong. But I'm not convinced at this time that the compensating features we get make up for losing that clarity, especially because the benefits are going to have terrible scaling problems as presented. If someone was going to pursue this, this is the angle I'd take; how do I freeze my program and determine what is affecting the behavior of the current execution trace? Assume an arbitrarily powerful debugger attached to your running process, as long as it doesn't "magic" anything into existence. I can see sketches of ideas in my head, I am by no means saying this is unsolvable. But I think it's something I'd need to see laid out a bit more before I got too excited. To anyone thinking about this, I'd advise you to also not forget scale. Anything works for 100 lines of code. I need you to present me with something that can make sense of when I'm running, let's say, thousands of these advisory functions at a time on a single question. Structured programming has an answer to that; being a thousand layers deep in a stack trace may be a lot for a human to take in, but nevertheless, the procedures that structured programming provides will still give you answers. (And I'm not asking for the solution to work any better than structure programming does in that case. Thousands of anything is irreducibly complicated. But it needs to at least give me understanding in the ballpark of what I have in a thousand-deep stack trace.)
- hacker_9 7y ago
  If you want to continue thinking along these lines, then look at how humans do it. For example, when writing a word document, the person has a continuous stream of ideas of how to write about a subject. But do they continually append only to the document? No, they delete, rewrite, restructure etc. It's just english is more flexible than our programming languages (and thus more ambiguous), so these operations are easier to do. I would think if continually layering over the top of existing ideas was somehow better, then evolution would have gone that route instead.
  - sktrdie 7y ago
    You're comparing writing a document with how we evolved which in my opinion is a false analogy. Our brains interact with complex systems in a much more intricate way than what is "writing a structured document". And in fact the entire attitude of this approach is the fact that we're not dealing with a statically structured word document, but with a much more intelligible system: a computer. Hence why not imagine programming differently: where we discuss with the system, and inquire it similarly to how the modules written in the article illustrate.
    - hacker_9 7y ago
      Perhaps, but we've had this problem since being able to formulate speech, where we have no way to 'undo' what we said in the physical world. So our language adapted to allow us to say things such as 'let me rephrase that', or 'ignore what I said, I'm wrong' etc. It's interesting that when we moved to computers, the preference was almost immediately to be able to completely delete/rewrite our thoughts instead.
      - sktrdie 7y ago
        Indeed! And that's exactly why I think programming feels so unnatural. Sure it is natural for us as we have years of experience modifying the structure of programs - where the structure is dictated by the nature of how computers mechanically work with memory/storage and others parts of the processor. Programming is this way because the actual computer structure demands it to be that way. Hinting at solutions that are closer to how we generally think or at least closer to how "non-coders" interact with computer systems should be more mainstream. For instance, this approach is much more similar to how non-coders write down requirements: when we discuss with people "clicking the button should stop the door from opening" we don't open a bunch of other documents and modify them accordingly to satisfy such statement. Instead we just "pile-on-top" such fact that might overwrite, contradict or replace other pieces of requirements. The whole point of this article is to make programming similar to the way we write requirements.

jerf 7y ago

Yeah. I like it from the point of view of "think new thoughts". It's an interesting thought. Let me highlight that with a few more words here to indicate that I don't just mean that as a polite sidebar; it really is an interesting thought. There may be something there. But as presented, the code complexity scales like a nightmare; it makes the worst Ruby monkeypatching look sane. Something would have to be done about that before even a toy implementation could be done, because this will fall apart very quickly. When you give away structured programming, you give away its benefits too. One of its benefits is that in a structured program, you can freeze a thread at any point and you have a clean mechanism for determining from there what its stack trace is, and all the relevant scopes it has access to and could be affecting it. In real code, this process may produce a very large number of variables and stack levels, but it'll still be a fraction of the program's possibilities. This is how structured programming helps us approach programs as structured slices of the code base, instead of a holistic view of the entire code base at once (this is the true reason goto-based code was so evil in the day; you could never do this analysis). This approach throws this away. That is not intrinsically wrong. But I'm not convinced at this time that the compensating features we get make up for losing that clarity, especially because the benefits are going to have terrible scaling problems as presented. If someone was going to pursue this, this is the angle I'd take; how do I freeze my program and determine what is affecting the behavior of the current execution trace? Assume an arbitrarily powerful debugger attached to your running process, as long as it doesn't "magic" anything into existence. I can see sketches of ideas in my head, I am by no means saying this is unsolvable. But I think it's something I'd need to see laid out a bit more before I got too excited. To anyone thinking about this, I'd advise you to also not forget scale. Anything works for 100 lines of code. I need you to present me with something that can make sense of when I'm running, let's say, thousands of these advisory functions at a time on a single question. Structured programming has an answer to that; being a thousand layers deep in a stack trace may be a lot for a human to take in, but nevertheless, the procedures that structured programming provides will still give you answers. (And I'm not asking for the solution to work any better than structure programming does in that case. Thousands of anything is irreducibly complicated. But it needs to at least give me understanding in the ballpark of what I have in a thousand-deep stack trace.)

hacker_9 7y ago
If you want to continue thinking along these lines, then look at how humans do it. For example, when writing a word document, the person has a continuous stream of ideas of how to write about a subject. But do they continually append only to the document? No, they delete, rewrite, restructure etc. It's just english is more flexible than our programming languages (and thus more ambiguous), so these operations are easier to do. I would think if continually layering over the top of existing ideas was somehow better, then evolution would have gone that route instead.
- sktrdie 7y ago
  You're comparing writing a document with how we evolved which in my opinion is a false analogy. Our brains interact with complex systems in a much more intricate way than what is "writing a structured document". And in fact the entire attitude of this approach is the fact that we're not dealing with a statically structured word document, but with a much more intelligible system: a computer. Hence why not imagine programming differently: where we discuss with the system, and inquire it similarly to how the modules written in the article illustrate.
  - hacker_9 7y ago
    Perhaps, but we've had this problem since being able to formulate speech, where we have no way to 'undo' what we said in the physical world. So our language adapted to allow us to say things such as 'let me rephrase that', or 'ignore what I said, I'm wrong' etc. It's interesting that when we moved to computers, the preference was almost immediately to be able to completely delete/rewrite our thoughts instead.
    - sktrdie 7y ago
      Indeed! And that's exactly why I think programming feels so unnatural. Sure it is natural for us as we have years of experience modifying the structure of programs - where the structure is dictated by the nature of how computers mechanically work with memory/storage and others parts of the processor. Programming is this way because the actual computer structure demands it to be that way. Hinting at solutions that are closer to how we generally think or at least closer to how "non-coders" interact with computer systems should be more mainstream. For instance, this approach is much more similar to how non-coders write down requirements: when we discuss with people "clicking the button should stop the door from opening" we don't open a bunch of other documents and modify them accordingly to satisfy such statement. Instead we just "pile-on-top" such fact that might overwrite, contradict or replace other pieces of requirements. The whole point of this article is to make programming similar to the way we write requirements.