Earlier quoted context omitted.
At the university level in the US, few faculty get any kind of training before they are expected to start teaching. And the teaching requirement is more or less “do no harm.” If you’re at a research university, which includes many publicly funded universities, then your career trajectory is based almost exclusively on your research output. I could go on, but it suffices to say that it’s not surprising that the teachi…
> the thought that here we have a bunch of people who have paid tons of money, set aside a significant fraction of their time, and nominally want to learn a subject that they signed up for; and yet, they still won’t sit down and actually do the reading unless they are going to be quizzes on it. How often have they put down the money, as opposed to their parents ? How often do they actually care about learning the sub…
The Unix Pipe Card Game
61–70 of 88 posts
Re: The Unix Pipe Card Game
#62Re: The Unix Pipe Card Game
#63This gets shared a ton, but the old Bell Labs video from 4:56 to 10:52 is still the best way I have seen pipes explained: https://www.youtube.com/watch?v=tc4ROCJYbm0
It's amazing how these ideas conceived almost 50 years ago still are helpful for new computer users today. Just goes to show how well planned it was.
Re: The Unix Pipe Card Game
#64Earlier quoted context omitted.
As a young Linux user I always hated the experimentation aspect because usually it meant just straight up getting the command wrong 5 times before trying to read the man page, thinking I understood what the man page meant, trying again another 5 times and then giving up. This idea of experimenting and getting instant feedback is just survivorship bias for a certain type of person, not “the way we ought to teach Unix…
> usually it meant just straight up getting the command wrong 5 times before trying to read the man page, thinking I understood what the man page meant, trying again another 5 times I think that is a developer's superpower. The poncy term for it is grit. I tell others that the secret to leaning computers is frustration and persistence. > and then giving up. Knowing when to stop or change direction is hard. I've defin…
Re: The Unix Pipe Card Game
#65Earlier quoted context omitted.
Trial and error was the root of what became my IT career. I became curious about what each executable did from DOS and with that did my first tweaking of autoexec.bat and config.sys to maximise memory. Years later I was the only one who could investigate network (and some other) problems in Windows via the command line while I was the junior of the team. Ended up being the driver of several new ways of working for th…
Ditto. I found that people whose attitude was “let’s just try it” tended to be a lot more capable and effective. Nevertheless the prevailing wisdom when I was in IT was that if you had a problem that didn’t have an obvious solution, you had to purchase the solution.
Re: The Unix Pipe Card Game
#66Earlier quoted context omitted.
As a young Linux user I always hated the experimentation aspect because usually it meant just straight up getting the command wrong 5 times before trying to read the man page, thinking I understood what the man page meant, trying again another 5 times and then giving up. This idea of experimenting and getting instant feedback is just survivorship bias for a certain type of person, not “the way we ought to teach Unix…
Maybe I am wrong about this but I think a lot of recent research has shown that trial and error is a great way to learn almost everything. Even just making an educated guess, even if it is completely wrong, before learning something makes it much more likely that you remember and understand the thing that you learn. It’s a painful and time-consuming way to learn. But very effective. Maybe Linux commands is a little d…
Gaining true understanding/insight is necessarily trial and error. Teachers cannot teach insight. But they can present the optimal path to gain insight.
Re: The Unix Pipe Card Game
#67Earlier quoted context omitted.
As a young Linux user I always hated the experimentation aspect because usually it meant just straight up getting the command wrong 5 times before trying to read the man page, thinking I understood what the man page meant, trying again another 5 times and then giving up. This idea of experimenting and getting instant feedback is just survivorship bias for a certain type of person, not “the way we ought to teach Unix…
> usually it meant just straight up getting the command wrong 5 times before trying to read the man page, thinking I understood what the man page meant, trying again another 5 times I think that is a developer's superpower. The poncy term for it is grit. I tell others that the secret to leaning computers is frustration and persistence. > and then giving up. Knowing when to stop or change direction is hard. I've defin…
Re: The Unix Pipe Card Game
#68Earlier quoted context omitted.
As a young Linux user I always hated the experimentation aspect because usually it meant just straight up getting the command wrong 5 times before trying to read the man page, thinking I understood what the man page meant, trying again another 5 times and then giving up. This idea of experimenting and getting instant feedback is just survivorship bias for a certain type of person, not “the way we ought to teach Unix…
> usually it meant just straight up getting the command wrong 5 times before trying to read the man page, thinking I understood what the man page meant, trying again another 5 times I think that is a developer's superpower. The poncy term for it is grit. I tell others that the secret to leaning computers is frustration and persistence. > and then giving up. Knowing when to stop or change direction is hard. I've defin…
> I think that is a developer's superpower.
I do too, but only because we can do both.I think comparing math education to programming education is quite apt here. After all, programming is math[0]. Both are extremely abstract subjects that require high amounts of precision. In fact, that's why we use those languages![1]
One of the absolute most difficult parts of math is that you don't have feedback. Proving you did things correctly is not automated. You can't run it and have an independent (not you) mechanism tell you that the output is what you expect it to be. This leads to lots of frustration as you sit there thinking very hard about what you've done wrong. It is frustrating because you're often blind to the mistakes as that's why you've made them in the first place! But the upside is that you quickly become attentive to details and learn those pitfalls very well. This also means you can abstract very well (the entire point of math) as you learn to abuse things on purpose. The struggle is real, but the struggle is important to the learning process. You learn very little if there's no struggle. Your mind is made to remember things that are hard better than things that are easy.
In programming we typically have the opposite problem. You get instant feedback. This makes iteration and solving your specific problem much faster. You can experiment and learn faster as you poke and prod seeing how the output changes. BUT there is a strong tendency to leverage this too much and use it to outsource your thinking and analysis. Iterating your way to success rather than struggling and analyzing. This doesn't result in as strong of neural pathways, so you don't remember as well and you don't generalize as well. Having taught programming I can tell you that countless students graduate from university[2] thinking that because the output of their program is correct that this means that their program is correct. This is a massive failure in logic. Much easier to see in math that just because 3+3=6 and 5+1=6 doesn't mean that the process is equivalent[3]. The correctness of the program is the correctness of the process, not the correctness of the output.
While that's the typical outcome of learning programming, it isn't a necessary outcome and there's nothing stopping anyone from also using the same approach we use in math. Math is only that way because we're forced to[4]! Both have their strengths and weaknesses, but neither is strictly better. The strictly better learning path is the combination and that is the superpower we have. It's just easy to abdicate this power and only do the easy thing.
[0] We can really say this from Church-Turing but if you really have concerns with this statement you'll need to read more up on the theory of computer science and I suggest starting with lambda calculus.
[1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...
[2] and even graduate degrees. You'll also see this idea prolific on HN and I'm sure someone will respond to this comment countering the point
[3] You can abstract this, I'm not going to do some long calculation here but I'm sure most people have done a long calculation where they got the right answer but the process was wrong and they had a professor still mark them wrong (and correctly so).
[4] If you're going to lean on me I'll concede
Re: The Unix Pipe Card Game
#69Earlier quoted context omitted.
> usually it meant just straight up getting the command wrong 5 times before trying to read the man page, thinking I understood what the man page meant, trying again another 5 times I think that is a developer's superpower. The poncy term for it is grit. I tell others that the secret to leaning computers is frustration and persistence. > and then giving up. Knowing when to stop or change direction is hard. I've defin…
Grit is something you gain once you already have an intrinsic motivation, such as already having a belief you can do this. Something has to spark in people that they’re capable in the first place.
Re: The Unix Pipe Card Game
#70As a science teacher and former software dev, I find this totally cute, and I understand exactly why the creator chose to make it a physical card game. That said, I do think the translation into a physical card game means that kids aren't getting the experimentation and near-instant feedback that they'd be getting if they were doing this digitally. In order for a kid to "win," they either have to already know, or exp…
> But I am having a hard time imagining it's the best way to learn to pipe together commands. To be honest, it is very strange how hard it is to teach programming concepts, for some reason almost all humans use computers but only 0.1% or so can program them. I am not sure we have the 'best way' to teach anything computer related. People develop world model for physics quite early, they know they can pull with a rope…