4 ms·

Dijkstra and the European school took a dim view of gluttonous Americans who refused to do computer science if they didn't have an expensive computer in their

Dijkstra and the European school took a dim view of gluttonous Americans who refused to do computer science if they didn't have an expensive computer in their lap. Your pencils, paper, and brain are an executable environment.

angleofrepose 7y ago
I'm not sure what you're referring to but I'd be interested if you shared more. I don't know the references you make, though I do know the Alan Kay nano-Dijkstra quote. I contest your second point, by definition my pensil and paper are not executable environments. My brain is, but this gets us into the game of "how much computer can you simulate with your brain." Why do we play the game of simulate-the-computer? We've had computer environments for at least 40 years now that do that thinking for us, that answer our questions about control flow or definitions or alternate scenarios. We have them, they were thought up, written up and delivered. Yet as a field we value this stupid idea of working alone without help and don't teach these workflows using the computer as a partner. No, in 2019 if you can't do it on paper you don't know it. That's bullshit, yet here I am and I can do it on paper. I'm just sad for those who come after me and have to go through the same wasteful hazing.
- kd5bjo 7y ago
  Fundamentally, it's the act of using your brain to simulate the computer that actually teaches your brain how the computer works so that you can reason about it later. In most domains, I find it best to start with doing things yourself, and only move on to the tool-assisted version once you thouroughly understand what the tool is doing for you. That way, you are still reasoning about the underlying system when working with the tool, and can figure out what happened when things go wrong.
  - mrkstu 7y ago
    Similarly in my domain of computer networking, the best advice I received was 'be the packet' - i.e. visualize the steps/hops the packet would take through the network and where are the decisions about forwarding would happen and what evaluations would be made to make that determination. Troubleshooting became much easier as I took that advise.
  - angleofrepose 7y ago
    I've written up three different replies now and I don't like any of them. I'm not sure how to respond to this statement. Thank you for writing it. I fundamentally disagree with the two assertions "it's the act of using your brain to simulate the computer that teaches your brain how the computer works so you can reason about it later" and "In most domains, I find it best to start with doing things yourself, and only move on to the tool-assisted version once you thoroughly understand what the tool is doing for you". I agree entirely with the notion that ability to reason about the underlying system is incredibly important, but I disagree about the methods to get there. I disagree with those two ideas because (and maybe we have different perspectives here) but the choice of whatever level is the "base level" or "bottom of the stack" seems entirely arbitrary every time. Is assembly the bottom? Or C? No it's machine code. No it's the physical wires. I think I should come back to my original comment here and reiterate. I'll clarify what I mean about those "computing environments that do that thinking for us" because I expressed myself poorly. There are computing environments and workflows that people have built which expose to the end user (the programmer) deep information about the state in which they are working. As a field, as a culture we have not embraced this thinking and rather stick to the simplistic notion of working alone to build understanding for ourselves alone. Sharing is discouraged (outright banned at school under penalty of expulsion) and difficult requirements are kept in place primarily for hazing purposes rather than pedagogical(I have this from a one-on-one discussion with the course designer at my school). There's this thinking that "I had to go through it, and the system produced me, so it must be good" and to think otherwise would be a recognition of being failed by the system, of missing something. A recognition that you could be smarter now than you currently are. So to give a concrete example, as my sibling comment talks about "being the packet". Why is the 'network', and 'understanding the network' not realized as exactly the same idea? Why should I ever have the simulate the network in my head? The network is an man-created artifact, my understanding of the network should come from the network, the literal code defining it, not from text file RFCs however well they are written and whatever brilliant ascii art they have (because they ARE well written, and well explained by their diagrams). Programmers should have inspection tools that are borne out of the definition of the artifact they are inspecting. This is of course being done in other disciplines first. An architect working in Revit is orders of magnitude more powerful than an architect working on pen in paper. In every case where an architect prefers pen on paper it is due to a failure of technology to realize practical or targeted workflow affordances, not due to the superiority of paper.
jammygit 7y ago
I’ve always wanted to try that out actually. I wonder whether it’s worthwhile

angleofrepose 7y ago

I'm not sure what you're referring to but I'd be interested if you shared more. I don't know the references you make, though I do know the Alan Kay nano-Dijkstra quote. I contest your second point, by definition my pensil and paper are not executable environments. My brain is, but this gets us into the game of "how much computer can you simulate with your brain." Why do we play the game of simulate-the-computer? We've had computer environments for at least 40 years now that do that thinking for us, that answer our questions about control flow or definitions or alternate scenarios. We have them, they were thought up, written up and delivered. Yet as a field we value this stupid idea of working alone without help and don't teach these workflows using the computer as a partner. No, in 2019 if you can't do it on paper you don't know it. That's bullshit, yet here I am and I can do it on paper. I'm just sad for those who come after me and have to go through the same wasteful hazing.

kd5bjo 7y ago
Fundamentally, it's the act of using your brain to simulate the computer that actually teaches your brain how the computer works so that you can reason about it later. In most domains, I find it best to start with doing things yourself, and only move on to the tool-assisted version once you thouroughly understand what the tool is doing for you. That way, you are still reasoning about the underlying system when working with the tool, and can figure out what happened when things go wrong.
- mrkstu 7y ago
  Similarly in my domain of computer networking, the best advice I received was 'be the packet' - i.e. visualize the steps/hops the packet would take through the network and where are the decisions about forwarding would happen and what evaluations would be made to make that determination. Troubleshooting became much easier as I took that advise.
- angleofrepose 7y ago
  I've written up three different replies now and I don't like any of them. I'm not sure how to respond to this statement. Thank you for writing it. I fundamentally disagree with the two assertions "it's the act of using your brain to simulate the computer that teaches your brain how the computer works so you can reason about it later" and "In most domains, I find it best to start with doing things yourself, and only move on to the tool-assisted version once you thoroughly understand what the tool is doing for you". I agree entirely with the notion that ability to reason about the underlying system is incredibly important, but I disagree about the methods to get there. I disagree with those two ideas because (and maybe we have different perspectives here) but the choice of whatever level is the "base level" or "bottom of the stack" seems entirely arbitrary every time. Is assembly the bottom? Or C? No it's machine code. No it's the physical wires. I think I should come back to my original comment here and reiterate. I'll clarify what I mean about those "computing environments that do that thinking for us" because I expressed myself poorly. There are computing environments and workflows that people have built which expose to the end user (the programmer) deep information about the state in which they are working. As a field, as a culture we have not embraced this thinking and rather stick to the simplistic notion of working alone to build understanding for ourselves alone. Sharing is discouraged (outright banned at school under penalty of expulsion) and difficult requirements are kept in place primarily for hazing purposes rather than pedagogical(I have this from a one-on-one discussion with the course designer at my school). There's this thinking that "I had to go through it, and the system produced me, so it must be good" and to think otherwise would be a recognition of being failed by the system, of missing something. A recognition that you could be smarter now than you currently are. So to give a concrete example, as my sibling comment talks about "being the packet". Why is the 'network', and 'understanding the network' not realized as exactly the same idea? Why should I ever have the simulate the network in my head? The network is an man-created artifact, my understanding of the network should come from the network, the literal code defining it, not from text file RFCs however well they are written and whatever brilliant ascii art they have (because they ARE well written, and well explained by their diagrams). Programmers should have inspection tools that are borne out of the definition of the artifact they are inspecting. This is of course being done in other disciplines first. An architect working in Revit is orders of magnitude more powerful than an architect working on pen in paper. In every case where an architect prefers pen on paper it is due to a failure of technology to realize practical or targeted workflow affordances, not due to the superiority of paper.

jammygit 7y ago

I’ve always wanted to try that out actually. I wonder whether it’s worthwhile