4 ms·

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

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.
    - AstralStorm 7y ago
      It will make it as much of a mess as any legal document, making it impossible to work with for any sane human not paid to do so. If you literally cannot guess at a glance how it will work as a programmer, how can you expect a user to do so? Even this trivial example is rather wrong. People do not think of message passing, synchronization or locks. We generally work on unordered, timesliced but fuzzy logic. When I press a button, it will immediately light up a red lamp - nothing in this is remotely near to how a machine will implement it. There's no message passing in the transistor that sits on a wire. Immediately does not exist, but you can consider some things "perceptually immediate", putting a hard time bound. Yet our programming does not deal with time explicitly. Pressing a button means a contact, but it does not say for how long or whether any bounce has to be handled, because we think in terms of stable states when really they don't exist either. Yet there's immutability and hard state everywhere in our programming. A human will handle a hardware error with a workaround, but software will fail in any unexpected scenario. And there's tons of these. We simplify programming by relying on the intelligence of the operator in many cases, but do not provide guidance. Literally not even whom or where to ask. It's good if the software even attempts to collect error info.

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.
  - AstralStorm 7y ago
    It will make it as much of a mess as any legal document, making it impossible to work with for any sane human not paid to do so. If you literally cannot guess at a glance how it will work as a programmer, how can you expect a user to do so? Even this trivial example is rather wrong. People do not think of message passing, synchronization or locks. We generally work on unordered, timesliced but fuzzy logic. When I press a button, it will immediately light up a red lamp - nothing in this is remotely near to how a machine will implement it. There's no message passing in the transistor that sits on a wire. Immediately does not exist, but you can consider some things "perceptually immediate", putting a hard time bound. Yet our programming does not deal with time explicitly. Pressing a button means a contact, but it does not say for how long or whether any bounce has to be handled, because we think in terms of stable states when really they don't exist either. Yet there's immutability and hard state everywhere in our programming. A human will handle a hardware error with a workaround, but software will fail in any unexpected scenario. And there's tons of these. We simplify programming by relying on the intelligence of the operator in many cases, but do not provide guidance. Literally not even whom or where to ask. It's good if the software even attempts to collect error info.