Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unix Pipe Card Game

punkx.org

Post reply on HN
Print view View original

51–60 of 88 posts

Re: The Unix Pipe Card Game

#51

Post by dhosek »

williamcotton wrote: post #32
dhosek wrote: post #21

Earlier quoted context omitted.

I’m wondering whether it could be played with a Unix box connected to the big TV in the living room so that with each command added to the pipe you can see the result. That’s my instinct for what to do with this, although it does feel like it is a play once kind of game.

Would this be something along those lines? https://github.com/williamcotton/guish It's a GUI for constructing and executing Unix pipelines and it shows the output of each step in the pipeline.

I’d been thinking more just typing the commands into a terminal window on the big screen, but something like this could be really helpful for seeing the intermediate steps.

Re: The Unix Pipe Card Game

#52

Post by jackdoe »

smj-edison wrote: post #49
jackdoe wrote: post #31

Earlier quoted context omitted.

> 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…

> I am not sure we have the 'best way' to teach anything computer related. Not saying this is the best way, but have you followed any of Bret Victor's work with dynamicland[1]? [1] https://dynamicland.org/

Yea, and I think it is amazing, but in the same time it will work for some and not for others

The same way scratch works for some, redstone for others, and https://strudel.cc/ for third

I think the truth is that we are more different than alike, and computers are quite strange.

I personally was professionally coding, and writing hundreds of lines of code per day for years, and now I look at this code and I can see that I was not just bad, I literally did not know what programming is.

Human code is an expression of the mind that thinks it. Some language allow us to better see into the author's mind, e.g forth and lisp, leak the most, c also leaks quite a lot e.g. reading antirez's code or https://justine.lol/lambda/, or phk or even k&r, go leaks the least I think.

Anyway, my point is, programming is quite personal, and many people have to find their own way.

PS: what I call programming is very distant from "professional software development"

Re: The Unix Pipe Card Game

#53

Post by raddan »

zahlman wrote: post #40
cheesecakegood wrote: post #38

Earlier quoted context omitted.

Needs qualification. Research shows trial and error learning is very durable, but it’s not the most time efficient (in fact it’s relatively poor, usually, on that front). The two concepts are a bit different. Yes, trial and error engages more of the brain and provides a degree of difficulty that can sometimes be helpful in making the concepts sticky, but well designed teaching coupled with meaningful and appropriatel…

> And you’d be surprised how many educators know very little about the neuroscience of learning! I'm (pleasantly) surprised every time I see evidence of one of them knowing anything about it.

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 teaching could be better.

That said, most institutions have teacher training resources for faculty. I was fortunate to be able to work intensely with a mentor for a summer, and it improved my teaching dramatically. Still, teaching is hard. Students sometimes know—but often don’t know—what is best for their learning. It’s easy to conflate student satisfaction with teaching effectiveness. The former is definitely an important ingredient, but there’s a lot more to it, and a really effective teacher knows when to employ tools (eg quizzes) that students really do not like.

I am frequently amused by 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.

Re: The Unix Pipe Card Game

#54

Post by raddan »

JamesTRexx wrote: post #34
nomadygnt wrote: post #14

Earlier quoted context omitted.

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…

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

#55

Post by raddan »

vacuity wrote: post #50
d-us-vb wrote: post #9

Earlier 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…

I'd like to add that, while anything will have some learning friction, learning the Unix CLI is rather unnecessarily painful.

I’m curious: what do you see as unnecessary about the CLI? Or, to put it another way, in what way should the CLI be changed so that the only remaining difficulties are the necessary ones?

Re: The Unix Pipe Card Game

#56

Post by raddan »

shakna wrote: post #27
d-us-vb wrote: post #9

Earlier 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…

I'd add nuance to Hermans' work. Its not all experiment blind, but also not feedback-less. They advocate for "direct instruction", not just rote learning. > As that is not a surprise, since research keeps showing that direct instruction—explanation followed by a lot of focused practice—works well. Note the "lot of focused practice". [0] https://www.felienne.com/archives/6150

There’s a pretty rich literature around this style of pedagogy going back for decades and it is certainly not a new idea. My preferred formulation is Vygotsky’s “zone of proximal development” [1], which is the set of activities that a student can do with assistance from a teacher but not on their own. Keeping a student in the ZPD is pretty easy in a one-on-one setting, and can be done informally, but it is much harder when teaching a group of students (like a class). The. Latter requires a lot more planning, and often leans on tricks like “scaffolded” assignments that let the more advanced students zoom ahead while still providing support to students with a more rudimentary understanding.

Direct instruction sounds similar but in my reading I think the emphasis is more on small, clearly defined tasks. Clarity is always good, but I am not sure that I agree that smallness is. There are times, particularly when students are confused, that little steps are important. But it is also easy for students to lose sight of the goals when they are asked to do countless little steps. I largely tuned out during my elementary school years because class seemed to be entirely about pointless minutiae.

By contrast, project work is often highly motivational for students, especially when projects align with student interests. A good project keeps a student directly in their ZPD, because when they need your help, they ask. Lessons that normally need a lot of motivation to keep students interested just arise naturally.

[1] https://en.wikipedia.org/wiki/Zone_of_proximal_development

Re: The Unix Pipe Card Game

#57

Post by zahlman »

raddan wrote: post #53
zahlman wrote: post #40

Earlier quoted context omitted.

> And you’d be surprised how many educators know very little about the neuroscience of learning! I'm (pleasantly) surprised every time I see evidence of one of them knowing anything about it.

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 subject, as opposed to be able to credibly represent (e.g. to employers) that they have learned the subject?

How often is the nominally set-aside time actually an inconvenience? (Generally, they would either be at leisure or at the kind of unskilled work their parents would be disappointed by, right?) My recollection of university is that there was hardly any actual obligation to spend the time on anything specific aside from exams and midterms, as long as you were figuring out some way or other to do well enough on those.

Re: The Unix Pipe Card Game

#58

Post by vacuity »

raddan wrote: post #55
vacuity wrote: post #50

Earlier quoted context omitted.

I'd like to add that, while anything will have some learning friction, learning the Unix CLI is rather unnecessarily painful.

I’m curious: what do you see as unnecessary about the CLI? Or, to put it another way, in what way should the CLI be changed so that the only remaining difficulties are the necessary ones?

I'm not qualified to give a complete answer, but I think two main issues are the proliferation of flags in standard tools (e.g. ls has a lot of flags for sorting behavior) and the extreme preference for plain text. Text is very useful, but a lot of semantic information gets discarded. Representing structured data is painful, stdin/stdout/stderr are all in one place, window resizing makes a mess sometimes (even "write at end of line" isn't given), and so on. I'm definitely not qualified to describe just how to fix these issues, though.

Re: The Unix Pipe Card Game

#59

Post by raddan »

vacuity wrote: post #58
raddan wrote: post #55

Earlier quoted context omitted.

I’m curious: what do you see as unnecessary about the CLI? Or, to put it another way, in what way should the CLI be changed so that the only remaining difficulties are the necessary ones?

I'm not qualified to give a complete answer, but I think two main issues are the proliferation of flags in standard tools (e.g. ls has a lot of flags for sorting behavior) and the extreme preference for plain text. Text is very useful, but a lot of semantic information gets discarded. Representing structured data is painful, stdin/stdout/stderr are all in one place, window resizing makes a mess sometimes (even "write…

I think you hit the nail on the head. Plaintext is universal in a way that nothing else really is. Outputting structured data means that consumers would have to process structured data. That definitely raises the difficulty of the programming. It’s not an easy problem, but I also do not have any good ideas.

Re: The Unix Pipe Card Game

#60

Post by lrvick »

jackdoe wrote: post #33
j2kun wrote: post #19

I saw that huge box of decks they printed for this, and I though, oh dear, how are they going to sell that many copies? :(

:) I actually printed a lot so the price is cheap, and I could sell for 5$ then I sold them until I recoup the printing cost and donated the rest to schools. I am thinking of doing a reprint, but tbh shipping is so expensive now, and I there is also USA's tariffs and etc.

I would pay triple to not have to worry about how to print and box these all neatly as you did. Please take my money for this and all your other games.
Post reply on HN