deniseyu / crochet-programming

notes for a new talk
4 stars 0 forks source link

A note to reviewers & idea-bouncers:

Hello! Thank you so much for your willingness to help with this talk. It's so cool that there are so many of us at the intersection of programming and fibre arts.

I apologize for the delay in getting back to you, since the time that you reached out via Twitter, Slack, or email. Somewhere between 50-100 people volunteered to help, which was AWESOME, but that also overwhelmed me a lot. That's like, enough people with wide-ranging expertise for a Master's dissertation on this topic. I put pressure on myself to have something more polished than what I had at the time, because I felt like I didn't want to waste the time of 50-100 people. Suddenly, my loosely-organized notes had to quickly gain shape. (I'm hard on myself, I know.)

I would love to acknowledge your help. If you are OK with me crediting you for this contribution at the end of my talk in a "Thank you to..." slide, let me know what name or handle you'd like me to use!

If you have time to read

I appreciate any amount of time you can spend reading over these notes, even if it's just a few minutes.

I am specifically looking for feedback in these areas:

There is an issue template in this repository that you can use if you'd like! If you don't have a GitHub account, you can email me at yu.denise.d@gmail.com or DM me on Twitter.

If you don't have time to read

That's OK! I want to be considerate of your time, and I'd still love your input. I'm curious to hear your input on these questions:

  1. In what ways does [crocheting, knitting, cross-stitch, weaving, etc] remind you of writing, reading, and debugging computer programs?
  2. How would you explain your fibre art craft to a fellow programmer, if you wanted to convince them to give it a try?

I will synthesize the responses and pull common threads out of them (pun very intended). There is an issue template in this repository that you can use if you'd like! If you don't have a GitHub account, you can email me at yu.denise.d@gmail.com or DM me on Twitter.


Talk info

Title

Crochet Patterns are Computer Programs

Abstract

During the pandemic, I picked up crocheting again after a 15+ year hiatus. As I stitched many hats, a few blankets, and dozens of miniature three-dimensional stuffed animals, I couldn't help but notice striking parallels between reading crochet patterns and reading lines of code. It turns out that the concept of written instructions for automating the creation of textiles predates the world's first computer program (written by none other than Ada Lovelace), and fibre arts are a lot more like programming than many of us suspect! This talk will be a loosely structured set of reflections on the relationship between the fibre arts and computer programming.

Goal & Audience

The first iteration of this talk is for GitHub's internal annual conference. I'm hoping to take it on the road afterwards!

The audience for this talk will broadly be:

My goal is to show people that the principles of computer programming have existed for a long time in the realm of the fibre arts, and get people thinking about other unlikely places where "computer programs" can exist!

I thought this was a talk?

I start out by writing my talks as blog posts. This helps me organize the narrative, and iterate the tone that I'm going for. Much of the text here will end up in speaker notes, rather than on the actual slides.

Introduction

In 2020, like so many people around the world who were facing the prospect of a long winter shut inside, I decided to pick up crocheting (again) as a way to pass the long, isolated evenings. In high school, I taught myself some crocheting basics, but never made much beyond basic scarves made with single and double crochet stitches. I often listened to audiobooks and podcasts when I crocheted at that time - I remembered that the repetitive, focused motion of creating evenly-gauged stitches occupied enough of my brain to prevent idle daydreaming, but left enough space for soaking up a good story.

Now that I think back on it, I've always had problems with staying focused on any task for longer than a few minutes. (I probably have undiagnosed ADHD.) Crocheting and programming, among a few other things, are the two pastimes that I can focus on for long periods of time without having to really work at it. I've heard the same sentiment from a LOT of other folks who program and do some form of knitting/crocheting/embroidery/quilting/etc!

The pattern is the program

What is a computer program? I think this story should start with the fundamentals.

The simplest definition (that I can think of) is that a computer program is a set of instructions, written by a human, to be executed by a computer. In carrying out the instructions, the computer will manipulate various resources (CPU, memory, hardware devices, hardware inputs) to produce a desired outcome.

I couldn't help but notice many similarities between reading crochet patterns and reading computer programs. Instead of a computer executing the instructions, it's another person with a set of crochet hooks and too much quarantine-impulse-bought yarn.

In both cases, we have:

With all of these thoughts swirling around the back of my head for the last year, I asked myself: Is authoring a crochet pattern not fundamentally the same exercise as writing a computer program?

A brief historical interlude

There's actually a very good historical reason why writing a crochet pattern and writing a computer program feel like they're tugging on the same brain muscles. It turns out that the world's first computer programs, from the Babbage & Lovelace days, were actually directly influenced by the fibre arts!

TODO: summarize Jacquard loom history https://www.scienceandindustrymuseum.org.uk/objects-and-stories/jacquard-loom.

TODO: Maybe also mention the Apollo rope memory story: https://spectrum.ieee.org/tech-history/space-age/software-as-hardware-apollos-rope-memory

Programming paradigms and styles

Modern programming languages feature many different ways to achieve the same end. I mean, have you ever seen Ruby? (Said with love. I love Ruby.) The path that we often choose for a programming solution is more influenced by the code's readability and maintainability by other humans. To a machine, there is no such thing as messy code: the names and abstractions we introduce along the way are for the benefit of other humans.

Recall the earlier discussion about resource manipulation. Sometimes, humans will encode a lot of detail in how those resources get manipulated. Put this value in this register, cache this thing, forget that thing. Other times, we'll be less particular about how the outcome is delivered, so long as it is delivered, of course.

In computer programming, we call these two ends of the spectrum of human intervention, imperative versus declarative programming paradigms. Imperative languages contain detailed specification about how the outcome is achieved. Think about Assembly code, which requires the programmer to know pretty gory details about the machine architecture, so that she can tell a computer program exactly which bytes to move to which location! That's a very imperative, very procedural way of writing code. On the other hand, think about SQL or CSS. I think CSS is a great example of declarative code, because when you say to your stylesheet, "Give my box 10 pixels of padding", the typical programmer knows not (and cares not) about exactly how those pixels are painted.

The majority of crochet patterns will make you feel like you're reading procedural code:

Screen Shot 2021-06-17 at 8 40 53 PM

(From https://mspremiseconclusion.files.wordpress.com/2012/07/crochet-totoro.pdf)

There are different ways of representing the same information. You know how the same song can be written in formal musical notation, or as a guitar tab? I loved discovering different forms of notation:

Screen Shot 2021-06-17 at 8 44 21 PM

(From https://thecrochetcrowd.com/crochet-cablework-afghan-tutorial/)

Often, an author will include the instructions in written form as well as in a diagram, like you see here. But sometimes, all you get is the diagram!

Screen Shot 2021-06-17 at 8 46 14 PM

(From https://www.gosyo.co.jp/english/pattern/eHTML/hat.html)

As I followed dozens of patterns, I learned a few basic principles about pattern design. (Probably not going to include all of these in the talk)

I wondered if it was possible to express crochet patterns in a way that was more like SQL or CSS, than COBOL. Was it possible to declaratively express the desired outcome of a crochet pattern, that left room for creativity in the hands of the crocheter? I wasn't sure, because I hadn't really seen any declarative representations. Crocheting had more similarities to Assembly code than to high-level, abstracted programming languages: most crochet patterns were designed for a specific set of inputs (yarn weight, hook size, etc) -- in other words, they were closely coupled to the specific "architecture" of the system in which they'd be "run". I'm not really sure how and where you'd introduce the concept of abstraction.

Then, I learned about freehand crocheting.

Writing the program is the easy part

There exist people who can look at a finished object, and figure out how it's made without following a pattern. Or, they might just start with an idea, and start improvising. That, to me, felt like an amazingly difficult thing to do. I started searching online for advice about how one can get started with freehand crochet.

Generally that advice was:

I realized that the skilled freehand crocheter isn't necessarily a natural genius. Rather, they just have more experience at implementing a diverse range of projects. All of those rules that I figured out earlier -- that's what freehand crocheters do, too! They just have spent a lot more time doing this, and learning many more rules than me.

And... that's when it clicked. This is also what senior engineers are. Because that same advice for freehand crocheting sounds a lot like programming advice that I got when I was early in my career:

Senior engineers aren't inherently smarter or more talented than their more junior peers. They just have spent more hours thinking about different programming challenges, and they've encountered and solved more categories of problems.

Closing thoughts

If I haven't convinced you yet that there are a ton of parallels between computer programming and fibre arts, here's one final observation:

Programmers. Who has ever bought a domain name for a side project that you never got around to? Or just started a ton of side projects... (show my abandoned GitHub projects)

I regret to inform you that crocheters and knitters are absolutely the same, but instead of buying domain names, we buy yarn. So. Much. Yarn. (show my shameful stash)

There is quite a lot that tech can learn from the crocheting and knitting community, and perhaps vice versa. Thanks for coming on this meandering journey with me, and I hope you'll look for computer programs in many more unexpected places!