[SamBam]

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.

[d-us-vb]

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.

[robocat]

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

[nomadygnt]

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.

[shakna]

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

[vacuity]

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

[inopinatus]

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.

[pmontra]

Getting a pipeline wrong 5 times is common. The normal process is: write a couple of steps, right output! Add a grep, bad output! Fix it, again, again, right output! Add cut -bM-N, adjust the boundaries a few times. Sort the output. Oops, sort -n

[jackdoe]

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

[bc569a80a344f9c]

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

[smj-edison]

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

[dr_kiszonka]

Amazing diagrams!

[derrida]

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.

[empath75]

unreal that an agent knocked this out in one shot.

[d--b]

One could make an app that actually scans the cards from a distance and computes the stuff. Brett Victor style.

[dhosek]

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.

[williamcotton]

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.