As 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 explicitly be told using words, what all of the commands do. Then they have to hear the parent analyze their solution, and tell them where they went wrong. Picture, however, a different game, played online: A kid has no idea what "sort" does, but when they link the "sort" command to a blob of text, all the lines are sorted in order. Now no one has told them what this command does, but they've discovered it. By playing the role of a scientist discovering these commands, they might actually gain an intuitive understanding of them.
I'm thinking of the board game "robot turtle," where kids needed to create a "program" of commands to move a turtle to a goal. When they did that, they had near-instantaneous feedback: the parent moved the turtle. If the kid mixed up their left with the robot's left, the failure was obvious. But if the game has been re-made so that there was no board, and the parent and kid just needed to talk about whether the turtle would actually end up seven paces forward and three paces to the left -- i.e. doing it all verbally -- it wouldn't have been nearly as powerful.
So I'm not raining on this, I can see this as very cool. But I am having a hard time imagining it's the best way to learn to pipe together commands.
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 shell”
This view is corroborated by the research summarized and presented in the programmer’s brain by Felienne Hermans.
> 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 definitely wasted years of work failing to solve something that I eventually had to give up on (most memorably depending on nasty Microsoft products).
But I've also been paid very nicely because I've solved problems that others struggled with.
I consider myself a fairly good developer, and I think that's in large part due to knowing, "doing this should be possible, and the reason it's not working right now is just due to stupidity (my own or the developer of whatever I'm using's)". But yes, in a few (thankfully rare) cases it just plain isn't practically possible. Even then, I've given up on problems just to have it nagging in the back of my mind and then randomly coming up with a beautifully simple solution weeks later. That's sort of the essence of what I like about programming (and math too).
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 different but I kinda doubt it. Errors and feedback are the way to learn, as long as you can endure the pain of getting to the correct result.
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 appropriately difficult retrieval and practice is better on most axes. When possible… good teaching often needs refinement. And you’d be surprised how many educators know very little about the neuroscience of learning!
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 the department and company.
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.
I'm trying to remember being a young Unix user but it was four decades ago, so the details become hazy. Nevertheless the proper go-to after the manpage fails to clarify matters is the same as it ever was, that is, one reads the source code, if you have it, and this is easier today than ever.
> 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 but cant push with a rope.
And they get intuition, things that are thrown up, go down, and they can transfer this intuition in the math, because math is real.
For some reason its hard to do that with code. People keep trying to push with a rope, even after studying for many years.
PS: I am trying to teach her neural networks now and am working on this RNN board game https://punkx.org/projekt0/book/part2/rnn.html to fight the "square" dragon. I want her to develop good world model for neural networks, so that she understands what chatgpt is. I just keep experimenting, sometimes things click, sometimes not.
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"
> almost all humans use computers but only 0.1% or so can program them.
This is nitpicking but I was curious: there are 4.4 million software developers in the US (https://www.griddynamics.com/blog/number-software-developers...). The population is 340 million, 0.1% would be 340,000. You’re off by over one order of magnitude.
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.
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.
Great video, when I first watched it, it switched my thinking from "why is *nix so hard to use" to understanding they were really trying to build with the user in mind and to learn more about the "*nix way" to work with it, not against it.
Interesting concept but in the current format it feels like a game to bring out exactly once with a very specific group (or perhaps an unexpecting child), play for 10-15min, smile to oneself and then put the deck where these sorts of games go die. If it is attempted to bring it out again with the same group, I'd expect a response similar to "Again? Didn't we play it already?" with some disappointment.
At least it was just $5 but I think it's 1000% more fun to actually use a unix terminal with some sort capture the flag kind of game.
Unix Pipes is a "play once" game, just so you can try some ideas, then try them out on the computer.
I used to randomly set HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon Shell to cmd.exe on my daughter's laptop so she can run programs from there, e.g. go the discord directory and start discord from there.
Then I made unix pipes just to help her with https://overthewire.org/wargames/bandit/ and so we can discuss how do you make "programs that do not know how they will be used", e.g. the programmer of "sort" does not know how it will be used, and you can create ridiculous pipe chains with the cards, just for fun.
Of course I made other random tasks, e.g. we take a random book and we start "catting" and "grepping" it
Most of the games i made on https://punkx.org are like that, i am just trying to teach her something and i need a bit of physical help to "get out of the computer"
The only real card game is http://punkx.org/punk0 which is like uno with state and I play it often with friends, and https://punkx.org/overflow/ which is super intense depending who you play with.
Love this. I once (2017 I think) made a card game based around MS-DOS with elements of Crazy Eights which I called Crazy DOS (shortened C:DOS) but got zero attention so I moved on. I might try this one, I love this kind of stuff.
We need one for SELinux for adults, it'll lowkey force people who haven't taken the time to learn SELinux to learn it and be fully capable of using it without fear.
I felt a lot better after seeing even the all knowing LLMs couldn't explain how a set of files were getting labelled automatically with a label that didn't match the parent directory.
Pipes don't transfer text, they transfer a unformatted byte stream. The commands however do expect a particular format. There is going to be serialization/parsing regardless of the format the command expects. Even if it is an internal object format as found in powershell commands.
I used to work with a guy in the data group at MapQuest a long long time ago and the stuff he could very quickly do with nothing but awk and sed was insanely impressive.
:) 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.
As 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 explicitly be told using words, what all of the commands do. Then they have to hear the parent analyze their solution, and tell them where they went wrong. Picture, however, a different game, played online: A kid has no idea what "sort" does, but when they link the "sort" command to a blob of text, all the lines are sorted in order. Now no one has told them what this command does, but they've discovered it. By playing the role of a scientist discovering these commands, they might actually gain an intuitive understanding of them.
I'm thinking of the board game "robot turtle," where kids needed to create a "program" of commands to move a turtle to a goal. When they did that, they had near-instantaneous feedback: the parent moved the turtle. If the kid mixed up their left with the robot's left, the failure was obvious. But if the game has been re-made so that there was no board, and the parent and kid just needed to talk about whether the turtle would actually end up seven paces forward and three paces to the left -- i.e. doing it all verbally -- it wouldn't have been nearly as powerful.
So I'm not raining on this, I can see this as very cool. But I am having a hard time imagining it's the best way to learn to pipe together commands.
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 shell”
This view is corroborated by the research summarized and presented in the programmer’s brain by Felienne Hermans.
> 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 definitely wasted years of work failing to solve something that I eventually had to give up on (most memorably depending on nasty Microsoft products).
But I've also been paid very nicely because I've solved problems that others struggled with.
And I was paid for the failures too.
I consider myself a fairly good developer, and I think that's in large part due to knowing, "doing this should be possible, and the reason it's not working right now is just due to stupidity (my own or the developer of whatever I'm using's)". But yes, in a few (thankfully rare) cases it just plain isn't practically possible. Even then, I've given up on problems just to have it nagging in the back of my mind and then randomly coming up with a beautifully simple solution weeks later. That's sort of the essence of what I like about programming (and math too).
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 different but I kinda doubt it. Errors and feedback are the way to learn, as long as you can endure the pain of getting to the correct result.
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 appropriately difficult retrieval and practice is better on most axes. When possible… good teaching often needs refinement. And you’d be surprised how many educators know very little about the neuroscience of learning!
> 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.
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 the department and company.
I'd like to add that, while anything will have some learning friction, learning the Unix CLI is rather unnecessarily painful.
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
I'm trying to remember being a young Unix user but it was four decades ago, so the details become hazy. Nevertheless the proper go-to after the manpage fails to clarify matters is the same as it ever was, that is, one reads the source code, if you have it, and this is easier today than ever.
> 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 but cant push with a rope.
And they get intuition, things that are thrown up, go down, and they can transfer this intuition in the math, because math is real.
For some reason its hard to do that with code. People keep trying to push with a rope, even after studying for many years.
PS: I am trying to teach her neural networks now and am working on this RNN board game https://punkx.org/projekt0/book/part2/rnn.html to fight the "square" dragon. I want her to develop good world model for neural networks, so that she understands what chatgpt is. I just keep experimenting, sometimes things click, sometimes not.
> 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"
> almost all humans use computers but only 0.1% or so can program them.
This is nitpicking but I was curious: there are 4.4 million software developers in the US (https://www.griddynamics.com/blog/number-software-developers...). The population is 340 million, 0.1% would be 340,000. You’re off by over one order of magnitude.
there are 45 million devs in the world (out of which probably 10 can actually program) and 8.5 billion people
we could say 0.5%?
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.
woah that looks nice!
hey, I just copy and pasted your comment into an agent I hope you don't mind.
one shot result:
https://wonderful.exe.xyz
you could do the same, or I could give you access to this one if you want.
unreal that an agent knocked this out in one shot.
well, technically 2, my second was "good, now do it better"
One could make an app that actually scans the cards from a distance and computes the stuff. Brett Victor style.
This 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
Great video, when I first watched it, it switched my thinking from "why is *nix so hard to use" to understanding they were really trying to build with the user in mind and to learn more about the "*nix way" to work with it, not against it.
Nit: You can get a link to a specific time in the video by clicking the "share" button and ticking "start at": https://youtu.be/tc4ROCJYbm0?&t=296
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.
Interesting concept but in the current format it feels like a game to bring out exactly once with a very specific group (or perhaps an unexpecting child), play for 10-15min, smile to oneself and then put the deck where these sorts of games go die. If it is attempted to bring it out again with the same group, I'd expect a response similar to "Again? Didn't we play it already?" with some disappointment.
At least it was just $5 but I think it's 1000% more fun to actually use a unix terminal with some sort capture the flag kind of game.
Unix Pipes is a "play once" game, just so you can try some ideas, then try them out on the computer.
I used to randomly set HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon Shell to cmd.exe on my daughter's laptop so she can run programs from there, e.g. go the discord directory and start discord from there.
Then I made unix pipes just to help her with https://overthewire.org/wargames/bandit/ and so we can discuss how do you make "programs that do not know how they will be used", e.g. the programmer of "sort" does not know how it will be used, and you can create ridiculous pipe chains with the cards, just for fun.
Of course I made other random tasks, e.g. we take a random book and we start "catting" and "grepping" it
Most of the games i made on https://punkx.org are like that, i am just trying to teach her something and i need a bit of physical help to "get out of the computer"
The only real card game is http://punkx.org/punk0 which is like uno with state and I play it often with friends, and https://punkx.org/overflow/ which is super intense depending who you play with.
Love this. I once (2017 I think) made a card game based around MS-DOS with elements of Crazy Eights which I called Crazy DOS (shortened C:DOS) but got zero attention so I moved on. I might try this one, I love this kind of stuff.
We need one for SELinux for adults, it'll lowkey force people who haven't taken the time to learn SELinux to learn it and be fully capable of using it without fear.
Well, there's a SELinux coloring book - you need to start with SELinux while they are still young! https://people.redhat.com/duffy/selinux/selinux-coloring-boo...
I felt a lot better after seeing even the all knowing LLMs couldn't explain how a set of files were getting labelled automatically with a label that didn't match the parent directory.
Earlier discussion on this;
2024 - https://news.ycombinator.com/item?id=41047110 (41 comments)
2022 - https://news.ycombinator.com/item?id=33222687 (59 comments)
I bought several of these and give them as gifts. Unix Pipe, Expansion Pack, and PUNK0 are my favorites.
I wish pipes would transfer more than just text to avoid re-parsing.
Pipes don't transfer text, they transfer a unformatted byte stream. The commands however do expect a particular format. There is going to be serialization/parsing regardless of the format the command expects. Even if it is an internal object format as found in powershell commands.
Could I introduce you to https://www.nushell.sh/, kind sir?
Started using it last year and being able to type ‘ls | sort-by modified -r | take 5’ feels liberating.
Disappointing that Debian seems completely uninterested in this :(
To be fair they really transfer bytes, which can be any data format you want.
I used to work with a guy in the data group at MapQuest a long long time ago and the stuff he could very quickly do with nothing but awk and sed was insanely impressive.
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.
What a good idea. I couldn't see on the site if there's an online version (especially relevant since it appears to be sold out in physical form).
https://openbsd.amsterdam/cards.html
"Teaching kids"? Well as a professional in IT I wished I knew how to answer all this!
related: https://printed.games/gates/
Still sold out?