7 ms·

The more I think about it and reflect on my (computer science) education I think more and more the lectures are awful. It is only the ease/ubiquity of creating

The more I think about it and reflect on my (computer science) education I think more and more the lectures are awful. It is only the ease/ubiquity of creating them that has kept them around. Fancy graphics is by no means an indicator of good information, but neither are lectures. It blows my mind that I can be taught programming concepts, say data structures, on a PDF. That is insanity, it is a total divorce from the idea of computer science to begin with, to hide data and information in a non-executable environment. Someone has the quote that "pdfs are where data goes to die". Give me the data structure, let me ask questions of it, hold it in my hands and inspect it at the pace of my own thoughts. This is not what material provided in "lecture" through "slide decks" provide. The information density of lectures is also low, why are we anchored to the low bandwidth channel of voice (I could say the same about text writing or a textbook)? Give me the information, let me have it, then let's talk about it in organized discussion.

lonelappde 7y ago
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
Mikhail_Edoshin 7y ago
The better the tool the less you learn from it. There was an experiment, I don't have a link, read about it someplace, about a task two groups of people had to solve on a computer. In one case the tool was merely checking the final answer; in another it was also offering helpful visual clues during the solving. Both groups solved the problem, but a follow-up check revealed that the first one has built a somewhat better understanding of the task, a better mental model of it. I think this is same with today's maps: it's very easy to find a road with a navigator, but it doesn't leave any lasting impression. Fine if it's a one-time task, but not that good if you want to become an expert on local roads. With a PDF about data structures you do have the executable environment: the compiler or the interpreter the PDF uses to give examples. The compiler has no manual on data structures, but you have the PDF instead. This is the real thing, by the way, that compiler. An medium that combines both instructions and some interactive thingie that shows the data structure will be much farther from the actual compiler than that poor PDF.
- angleofrepose 7y ago
  > The better the tool the less you learn from it This seems too broad to make a general rule. Shall I not use calculators and memorize trig tables to better understand the tools that are these functions? I would be interested in seeing that experiment, I cant come up with a concrete example in my head which would follow that pattern. > maps I agree, I think most people should not have to become experts on local roads, then again, I think you over simplify the issue. I would bet that most people are experts on their local roads. I am in my hometown, I am not when I travel. I do not know how pdfs are made today, but keynote/power point are generally drawn with WYSIWYG tools rather than post script or latex. I am not aware that I have ever read a pdf or been to a presentation with slides not generated by one of these WYSIWYG tools in my entire life. I have never actually opened one of these files, but I also don't expect that I could. I would bet they are not stored in text files. Overall I contest each of your points, though I appreciate the ideas. I understand the sentiment but don't agree on the reality. Sorry for the late reply, I'm happy to continue if you have the time.

lonelappde 7y ago

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

Mikhail_Edoshin 7y ago

The better the tool the less you learn from it. There was an experiment, I don't have a link, read about it someplace, about a task two groups of people had to solve on a computer. In one case the tool was merely checking the final answer; in another it was also offering helpful visual clues during the solving. Both groups solved the problem, but a follow-up check revealed that the first one has built a somewhat better understanding of the task, a better mental model of it. I think this is same with today's maps: it's very easy to find a road with a navigator, but it doesn't leave any lasting impression. Fine if it's a one-time task, but not that good if you want to become an expert on local roads. With a PDF about data structures you do have the executable environment: the compiler or the interpreter the PDF uses to give examples. The compiler has no manual on data structures, but you have the PDF instead. This is the real thing, by the way, that compiler. An medium that combines both instructions and some interactive thingie that shows the data structure will be much farther from the actual compiler than that poor PDF.

angleofrepose 7y ago
> The better the tool the less you learn from it This seems too broad to make a general rule. Shall I not use calculators and memorize trig tables to better understand the tools that are these functions? I would be interested in seeing that experiment, I cant come up with a concrete example in my head which would follow that pattern. > maps I agree, I think most people should not have to become experts on local roads, then again, I think you over simplify the issue. I would bet that most people are experts on their local roads. I am in my hometown, I am not when I travel. I do not know how pdfs are made today, but keynote/power point are generally drawn with WYSIWYG tools rather than post script or latex. I am not aware that I have ever read a pdf or been to a presentation with slides not generated by one of these WYSIWYG tools in my entire life. I have never actually opened one of these files, but I also don't expect that I could. I would bet they are not stored in text files. Overall I contest each of your points, though I appreciate the ideas. I understand the sentiment but don't agree on the reality. Sorry for the late reply, I'm happy to continue if you have the time.