Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
In this Discussion
Week 2: Code Critique - SkyKnit
Discussion leaders: Anastasia Salter and Anne Sullivan
Code Critique: Of Textiles and Technology
One of the most famous generative textile projects to date is Janelle Shane’s SkyKnit. The project itself runs on top of TensorFlow: you can see the full library for the neural net textgenrnn on GitHub. Playing with it via Google Collab is an easy way to get some context for how the generative model works, and particularly for its reliance on pattern recognition within a large dataset, which is crucial for understanding and enjoying the results of SkyKnit.
This project is a great way to understand the relationship between knitting and code: the initial dataset was trained from StitchMaps, which is an attempt at standardization of the knitting pattern form. There's lots to explore in the dataset visually and textually at https://stitch-maps.com/ - here’s an example:
The written instructions provide a particularly strongly “code-like” overview of the pattern:
Rows 1, 5, and 10 (RS): [K2tog] 3 times, [yo, k1] 6 times, [k2tog] 6 times, [yo, k1] 6 times, [k2tog] 3 times.
Rows 2, 4, 6, and 8: Purl.
Rows 3, 7, and 9: Knit.
However, this rigidly formatted dataset was augmented by a crowdsourced collection of patterns decidedly more diverse. As this section from the documentation (available as an ebook through Ravelry: ) notes:
“WHERE THE TRAINING DATA CAME FROM
4728 of the patterns were from stitch-maps.com. These patterns are in consistently formatted, very logical knitspeak, as required by stitch-maps. Most of these are simple swatches; none have extra directions. 500 of the patterns were crowdsourced. These patterns are NOT consistently formatted (one even contained an Emily Dickinson poem) and range from sweaters to cowls to unmentionables. A significant portion involve tentacles.
Janelle trained the SkyKnit algorithm with a few different combinations of these - some of the results in this collection are from training just on stitch-maps, some are from the tentacle dataset, and some are from a combination of the two. The original patterns aren't recognizable in the final results - although it should be easy to tell whether a particular pattern was trained on the well-behaved dataset!”
As with GitHub, there’s a repository of sorts for the collection process discussion on Ravelry: this lengthy forum includes both the initial input on patterns to seed the generation, and many resulting interpretations of the generated patterns. Here’s a screenshot of the seed post, which has been updated to include links to the coverage:
There are lots of generated patterns worth exploring in this dataset - we’ve selected one that definitely takes some influence from the tentacle patterns in the crowdsourced data, and importantly one that people have knitted so that you can see both pattern and “object.”
Some of the generated pattern name highlights include:
- 282 flukes
- booties twisted
- fishcock
- jackdom
- make caows and shapcho
- prom net
- sea no
- snowing leaves
- techsex
- tuck socks
And so forth.
Here’s the “code” from one particular pattern for discussion, although given its relationship to both the “original” patterns as code and the textgenrnn code, you might find it useful to not approach it in isolation but as a product of a craft ecosystem:
tiny baby whale soto
co 16 st using a 6– for garrent - purl 1 st at end of round and then insert stitches of the rnd. as you come to be sure to work in the round.
using the tentacles and join for working in the round, being careful not to twist the stitches.
keep the last stitch from co edge, ending with round 5.
instep stitch pattern will be picked up all end of the sock, ready through stitch markers and join to work in round. 33 (58, 62, 68) sts using the tail between you worked left
on the rs row. [12 (18, 19, 21, 13) st and 2 adslip st tbl, p3[3, 3] times, (3-st on dpns), k2tog and turn. [108 (112, 120, 134) stitches]
next round: k2[1, 0, 0, -, -], k1, p2, k3, p2, k2, p2, k2] 3 times, p1, k18, p2, k2, p2, k5, p2, k1, p2, k2, p2, k2, p2.
next row: (p1, sl5) 3 times, p1, (kfb, k1) 3 times, k2, sl m, k5, p
cut yarn, leaving a 6 inch tail.
knit 5 [6, 6, 7, 8, 9, 10, 11] sts of needle 1, k2 tog to the end of the row. [101[120, 132] sts onto the bottom of the heel is facing you, pick up and knit 15 stitches and work the purl stitch (do the ears of the round) in the way purl.
finish with the new front of the hat for seaming from the working needle to join to work in the round.
repeat row 1.
row 1 [rs]: slpwyf, k4, p3, [k4, m1, k1] to last 3 stitches, p2, k3.
row 2 [ws]: k4, [p34, k1] twice, p2.
rows 9 – 31: k to 3 sts before first marker, ssk, k2tog, sm, ssk, k1, turn.
row 18 [mc]: k.
row 22 [mc]: k to 3 sts before next marker, k2tog, sm, ssk, k1, ssk, knit to 3 stitches before next marker, k2tog, sm, ssk, k1, k2tog [3 stitches remain, m1r, slip marker -- 32 sts)
round 21: k
row 26 [rs]: [kfb, k1, kfb] repeat to end of round. 20 sts remain by work by 40 (44, 60, 62, 64) stitches]
row 13 [mc]: k to 2nd m, m1l, k3, m1l, work to end. {10 sts.
rnd 17 (rs): knit to 3 sts before first marker, p1, repeat from * to end of row.
repeat the last round until piece measures 13[15.5, 14.75] inches from the end of the round p more stitch from the top edge. 88 (83, 93, 101) sts on hold on needle 3 on needle, k2tog [16 total st).
next row (wrong side): slip 1 wyib (16 sts)
cut yarn and thread through sts on the needle.
weave in ends with cc and the next step 10 minutes.
finishing
weave in ends.
Here’s Gloria Hanlon’s version of the final output (as shown in this fantastic Atlantic article describing how knitters “debug” the patterns):
There are lots of productive ways to explore SkyKnit - the most interesting, of course, is to try and follow a pattern. In the process of knitting a generated pattern, one becomes the compiler - the threads of knitters who have tried to follow SkyKnit’s generated guidelines particularly capture that process, and the ways in which the “compiler” handles errors and ultimately will vary in their interpretation of the coded directions.
The disclaimer on the Raverly pattern listing notes how this guarantees individually distinct, yet computationally similar, outcomes:
“With one or two exceptions, the SkyKnit patterns aren’t knittable without at least some debugging, and each knitter’s solutions makes the product look completely different. After seeing the initial test knits and the variations that individual knitters produced, it became clear that the variety was part of the charm of this project, and so we decided to create one large collection. The SkyKnit patterns are the result of a collaboration between the knitters of Ravelry (mostly the LSG forum), stitch-maps.com (run by JC Briar) and Janelle Shane of aiweirdness.com. There are a couple four-letter words in the titles and instructions, which is why there is an adult-content warning.”
Discussion Questions
- Are textile instructions a domain-specific language?
- What are the similarities between “debugging” a pattern and a program?
- How do we read “rules” differently when material output is on the line?
- What other connections between code and craft are useful to understanding both?
- Notice the highly computational, procedural aspects of knitting rules - if you aren’t a crafter, does that change how you think about textiles?
Comments
@annetropy @anasalter the textiles here is it referring to prints on the clothes or any computer design?
I wonder if it is useful at all to think about how the jacquard loom works. It is certainly different, as SkyKnit applies to knitting and uses a larger vocabulary of actions (finish, repeat, join, etc.), like a recipe for a human rather than a machine, but there are sections (e.g., "p1, k18, p2, k2, p2, k5, p2, k1, p2, k2, p2, k2, p2") that remind me of the way jacquard punch cards represent textile patterns in code.
Mostly I want to share some cool photos (from the Beinecke Library, Yale):
Above, in this 1872 French weaving treatise (Cours de Theorie pour le Tissage), you can see how the punched holes in the punch cards correspond one-to-one to the pattern being woven in the automated loom. The hole determines whether or not a group of threads is lifted during weaving, which in turn affects the pattern. Like the instructions above, the cards in this first image look machinic, but they correspond to silk design that looks identical to one woven without the cards. When not being used, the punch cards are hung in "libraries" like code depositories waiting to be pulled out again.
These types of weaving treatises looked different in the days before pure automation. Check out these photos below, from a 1771 German pattern book:
In the first image, you can see in the bottom center the "code" for weaving this pattern (as it would be cut into wooden rods to assist the weaver during the process, a method typical in Essen during this period). Better yet, the marginal notes in the second image demonstrate how weaving pattern books at times used an even more abstracted (or "code-like") instruction system than punch cards for guiding the weaver.
The biggest difference here is that stitch maps are written for human compiling (and, thus, debugging would be much different, no? SkyKnit users can see an instruction and think, "huh?" by comparing the instruction to their own experience (as Rayn63 implies). An 18th-century German weaving expert might see a series of wood notches and recognize something weird about the pattern, but it is more set up for mindless execution. Jacquard looms are kind of WYSIWYG, but if each punch card is only so many rows, it might be hard to even grasp the whole pattern until executed.
Though I can imagine training a machine learning model on both the patterns above and the "codes" above... and I wonder if those models would in turn produce similar results? I also doubt there would be much satisfaction or joy from being delivered an A.I. pattern is this form and then debugging it as you go.
P.S. I wonder what's new with Google's Project Jacquard.
Zach, I jumped into this on the other thread, but just in case folks are reading here WOVN has a very cool tutorial on using Processing to generate weaving designs: https://www.wovns.com/tutorials/designing-computational-textiles-with-processing/ - not as fancy as a machine learning model, I believe that has been done as well. Gillian Smith has some work on this type of generation in other forms you might enjoy: https://ojs.aaai.org/index.php/AIIDE/article/download/12925/12773/16442
@zach_mann As you say, weaving and knitting are different, but I think this difference can only be understated. Structurally speaking, weaving, knitting and say, javascript are equidistant from each other. The Jacquard mechanism always comes up, but is almost always a distraction - it stands for simplification and automation, and as far as I know, does not introduce any new ideas or techniques to the long history of handweaving.
Back to SkyNet, I find it fascinating, I didn't know about it until now, thanks for sharing! The knitted result is lovely, and this is where it gets especially interesting for me. The symbolic instructions seem meaningless until the result is made, and when there are different outcomes, it seems like the meaning comes from the maker interpreting the instructions, rather than the instructions themselves.
I find this interesting "There are lots of generated patterns worth exploring in this dataset - we’ve selected one that definitely takes some influence from the tentacle patterns in the crowdsourced data". This is cherrypicking - using a model to generate something, and selecting from the output. It's not necessarily a problem unless there is an argument that the model is being creative. If that is the argument then there's some smoke and mirrors going on.. You can creatively select artifacts from a random number generator, and come up with nice melodies etc, but it doesn't mean that the random number is being creative - the person doing the selecting is.
I'd say absolutely yes.
I think in terms of knitting, a 'pattern' and a 'program' or 'algorithm' are mostly interchangeable. The difference is that 'pattern' implies cultural grounding in craft, whereas program/algorithm implies something abstract from everyday life and perhaps inhumane.
I think we follow the rules and read the material, in a creative (and debugging) feedback loop. I find it very hard to read a knitting pattern and imagine what the result will look like. I'd be interested in what more experienced knitters think about this, though!
I find it hard to answer this one as I don't really think of them as being separate concepts.
I think learning how to knit and weave has definitely changed how I think about both textiles and code. Learning how something like houndstooth works really changes how you see the structure of the fabric environment around you - clothes, seat coverings etc etc suddenly open up to you. Personally seeing these coded complexities in everyday life made me realise how culturally impoverished code culture often is and open up new possibilities in grounding code-based practice in heritage technologies.
I wonder if the concept of "brute force" is transferrable across code and textile work in the same way. Because of the materiality of cloth or yarn, there is a level of "rule breaking" or forcing something to work that I'm not sure works the same way with code. For instance, when I'm sewing, there are times where I can just whip out a hot glue gun and for-go thread all together. Or there are times where I can sew a button onto fabric without there being a button hole or any other logical reason for this button to exist. I wonder if others have thoughts about the level of rule breaking or logic breaking that is afforded by the materiality of textiles and whether or not brute force to this degree is possible in code?
@blankenshipa there's definitely an analogous behaviour! But I suspect the same can be said for most crafts, be they physical (eg, building a house) or purely intellectual/mathematical. Square pegs can be forced into round holes is almost allwalks of life. The process may run against our developed aesthetic responses, though.
Hi all, thanks for sharing all these ideas and amazing materials!
I am visual artist working on a Phd, where I am practically and physically exploring some of the connections discussed here - between the threads of the loom and the programming of the computer, between the logics of weaving recipes and algorithms through experiments with coding and weaving.
For one example, I am working on a project (Sunrise Patterns) where I have woven a historical weaving pattern (on a manual shaft loom), mutated the pattern by changing the rhythm of my steps on the loom pedals, and created a visual algorithm (p5.js) that translates the pattern indefinitely.
To pick up on question 4) What other connections between code and craft are useful to understanding both?
I’d say that in addition to understanding algorithms through weaving, studying connections between code and craft (here weaving) can also be a prompt to think differently about the role weaving and weavers play in art history as well as in the history of computation.
How do those of you who practice both coding and weaving experience similarities and differences between algorithms and weaving patterns? (I do not knit myself but see that there might be many overlaps).
@nannadeboisbuhl This is great thanks for sharing! I've not used a shaft loom, can you say something about how it feels to change rhythm? Do some rhythms 'feel' better than others? Also when you mutate patterns, do you then have problems with floats or other structural issues that you have to deal with 'by hand'?
I am not an experienced weaver and have only really done weaving when it was directly driven from algorithms, on what I've called the live loom:
I've also used a TC/1 loom with a design made with my TidalCycles software.
I am always struck at how radically different the binary structure of the block design is on the screen when compared to how the threads actually behave - how the floats behave but also how colour-and-weave effects totally confound my expectations and how sometimes the fabric splits into two or just gets in a mess.. This has a lot of similarities with my experience of making music with code too - rhythms on paper have a totally different structure to how they feel when you listen or especially dance to them. So for your question I think the similarity is in writing code that has no meaning until you run it. Code may be deterministic but that doesn't stop it from being very unpredictable.
@yaxu Awesome to see your live loom, so interesting how it connects not only coding and weaving but also sound! And thanks for sharing the article too!
To answer your questions about rhythms:
When working on a shaft loom the entire weaving is a combination of different horizontal line patterns defined by the warp threads and connection between loom shafts and loom pedals, that you then switch between using the loom pedals.
For my project, I first wove a fragment of an old weaving pattern. In the next weavings I changed the rhythm of my steps on the pedals, so that new patterns were created. Working with less repetitive rhythms created more irregular patterns, and the process of weaving them was more explorative. Regarding floats: based on a small weaving sample, I had decided on a maximum length of floats on beforehand (how many warp threads the weft thread can float over), so that did not change in the process.
As you also point to, one similarity between programming and weaving here is how a small change in input might change the output in surprising ways.
@anasalter Thanks a lot for the WOWN reference, am curious to check this out!
I was not thinking of rule breaking per se, but as a mender/remixer more than a maker, I was also reflecting the irregularities of fabric in relation to code. I often have a 'workspace' (hole, tear, thinning fabric etc) that one the one hand does not allow me to _only _follow the code/pattern of learned techniques (although those techniques are key in the mending process), but on the other hand is very rule-based in that it is the workspace I have to work with, so the shape is set for me (unless I cut it further open, but I like to work as minimalistic as possible). For some fabrics it must be possible to make a program that lets you input the exact shape and generates a funky pattern based on it.
Very sappy answer, but I think care and perception. As with every other skill, once you get into it, you perceive the intricacies in a way you just did not before, and (hopefully) this leads to more care and appreciation for the products and the people that made them. At the same time, the enhanced perception also helps you see the opportunities and how things could be different from the way they are made now.
Finally, for those not familiar with the intersection between code and knitting, you might like the Knit2Code project, I watched this Tedx video about it with my DH class.
@hannahackermans @blankenshipa I am also more inclined to mend or recycle/upcycle material that is mostly whole rather than start from scratch. The process usually involves reverse engineering the item (I did this recently with a pair of jeans... it was actually really interesting!) and then figuring out how to put it back together again. This is also what I spent most of my time doing as a SQL programmer because I often fixed existing scripts when they choked on newly formatted data and such, scripts that had been written years prior by people who'd left the company. Mending is a necessary skill for code and textile projects! Also, the Knit2Code TedX video is wonderful; I especially like the emphasis on intergenerational communities and learning/teaching computational thinking without computers.
@hannahackermans thank you for the link to the TedX talk, that was wonderful! I'm working on a project called Code Crafters with Gillian Smith that looks at quilting and coding, and thinking through how intergenerational communities share knowledge. (our hastily thrown together website is here: http://www.code-crafters.org/)
@yaxu your live weaving and comment about how your fabric might split reminds me of logic vs syntax errors and how they are similar in craft. You may make a mistake in whatever craft form that makes it not look the way you want (logic error) but you can also make mistakes that compromises the structural integrity (syntax error).
@annetropy Yes that's a nice thought. With weaving there have been cases where I have expected a fabric to not hold together, went ahead anyway and it was fine. If I created a 'split' doubleweave without expecting it that would certainly be a valuable experience.
I think this relates to what Tim Ingold called 'hylemorphism' vs 'textility', or what Franklin calls 'control' vs 'craft'. When we have a fixed, pre-conceived idea about what we want, and impose it on the world, any deviance is an 'error'. When we start with an idea but respond to what actually happens while working with the material, then there are no errors any more. If an improvising musician makes a 'bum' note then can just repeat the 'mistake' and it becomes part of the music. It's the difference between the genius channelling divine ideas into the world vs the craftsperson guiding flows of force as part of the world.
It's a good point though about different types of error, and above romantic thought about craft aside, syntax errors can be super annoying. Especially knitting something complex and spotting a dropped stitch several rows down. Over time syntax errors 'pop out' at you when you get fluent with a system though, at least that's my experience of computer programming, and when experienced people help me with knitting.
@KatieA I love the extended metaphors of "mending" in code and textile projects, that's one of the things I try to emphasize with my students in programming: so much of what we do is piecework and repurposing, and even something made "new" begins with materials :-D
Hi all! Late to this discussion but couldn't miss out on the opportunity to think about (and in my case, attempt to knit with
) SkyKnit. Such a weird project and a wonderfully generative space for thinking about code & craft. As I was attempting to knit this (I did not get very far -- only a few rows give my own time constraints) and doing my own debugging I was thinking about the second discussion question:
What are the similarities between “debugging” a pattern and a program?
Not having ever debugged a program, though, I don't know that I can offer much on that. Here's what I did for debugging this pattern to knit, though, and maybe folks with more programming-debugging knowledge/experience can offer some insights back?
Anyway, to start I was struck with 16 stitches to cast on being too few for working in the round (as the pattern says), so first point of debugging was going to DPNs (double pointed needles) immediately, so I could join the round (reading in the pattern, DPNs show up later but as a tool to change over, not a starting there, in my reading). Is there an analogous material limitation in debugging a program this early on? Maybe something in recognizing one language may be better suited than another (though this feels like the analogous craft would be switching between, say, yarn types or even crafts like crochet vs knit).
Once I got my stitches on to start knitting, I found myself making blanket assumptions to "work as presented," which in knitting patterns basically mean "keep doing what you're doing / if it looks like a knit stitch, knit, and if it looks like a purl stitch, purl" For instance, at line4 the pattern reads "keep the last stitch from co edge, ending with round 5" but since we haven't been given 5 rounds of explicit instructions, I read that as "work 5 rounds as presented." So far "as presented" is entirely up for interpretation, but I read this as knitting every stitch except for the last stitch of each round which is purled. All that to say -- are there similar assumptions that either programmers or computers will make in buggy code that equates to "work as presented?" Maybe something in default settings, since certainly my assumption to knit all except for the last stitch of the round is based on the "default setting" to knit unless otherwise specified.
The last thing I noticed myself doing in just this few minutes of trying to debug this pattern was just skipping whole sections that don't make any sense to me from either my knitting knowledge, pattern literacy, or the textile in front of me. So as an example here in line 5 we get "instep stitch pattern will be picked up all end of the sock, ready through stitch markers and join to work in round" which, for me, is not meaningful at the moment since 1) I am not making a sock so there is no instep; 2) I've already joined in the round given the repetition of this instruction in line 1; 3) there are no stitch markers. So the analogous action to "figure it out later / make it Future-Me's problem" to debugging a program seems obvious, if I were interested in figuring this out in the knit pattern later. But in knitting I could just skip this -- and this I think recalls @blankenshipa early comment about brute force -- and I wonder if that same flexibility is available in program debugging? Can you just skip things? Can you tell the computer to "just skip it" (like commenting something out, for instance) in the program?
I don't have a huge lot to contribute to the interesting discussion above (except observe with delight good people interacting), but the SkyKnit project in its evocative strangeness to competent knitters ("wow ok?") reminds me a little bit of Crochet Coral Reef by Margaret and Christine Wertheim.
The Crochet Coral Reef "models" the fractal geometry in fully Mandelbrotian sense of non-integer dimensionality of the wonderful lifeforms found in corals by crocheting. I haven't tried it, but from what I understand is that more-than-two-but-not-quite-three dimensions gradually emerge from the kind of two-dimensional technique, as the material is worked on and the structure of the patterns push the material beyond the two-dimensional plane onto curious folds.
Photo of Toxic Reef and Mathematics Blackboard, from the 2019 Venice Biennale I think.
As they describe themselves:
It is quite wonderful and explicitly addresses textiles, materiality, climate catastrophe, Anthropocene, more-than-human, mathematics, performativity, textile practices, feminism &c &c. Its a travelling exhibition, an installation, a kind of "material essay", dataviz, skill, and I think they also do workshops and share the patterns so anyone can give it a shot. Check it out maybe?
I'd heard of it before but it was really Donna Haraway who taught me about it in her Staying with the Trouble. Making Kin in the Chthulucene (2016, Duke University Press). She discusses the the Crochet Coral Reef and three other projects to discuss concept of sympoiesis in the third chapter called Sympoiesis: Symbiogenesis and the Lively Arts of Staying with the Trouble. Haraway's sympoiesis seems to be aligned with what @yaxu was saying about 'hylemorphism' vs 'textility' (ref. Ingold), "planned" vs. "situated action", tinkering (Ingold), improvization etc. although I am not sure how much the coral reef crocheting is intentional and guided by plans, and how much it is improvized, situated action.
On a personal and more serendipitous rather than intentional note (like Wertheim² Crochet Coral Reef or Hawaway's book), we didn't have much music at my childhood home but my first "musical" experience and some of my earliest memories from very, very young age is however the repetitive sound of my mum knitting. Decades later in adulthood I met people whose needles had the same metallic sound and immediately regressed/transgressed to my babyhood listening to them go. Knitting was somehow trending among anarcho-punks – who would have thought but it of course makes sense. They made a friend of me and taught me basics of a five-needle technique (which I still can do – bodily memory and know-how is amazing), and I knitted a pair of arm-warmers for my mom. I don't have a n active textile-practice (except wearing clothes most days hehe), but have started to make music also with Tidal Cycles and I have wondered if my draw to repetitive music somehow could have been partially influenced by napping to the fast metallic techno beat of mum knitting? I will never know. Another rhythm+textile related tangent was an ethnological book I saw which documented working music which people would sing in agricultural, domestic, workshop and factory settings to keep pace, remember and reproduce work-knowledge in pre-industrial and early-industrial cultures in Finland and nearby.
I suppose part of the fun is knowing that one's interpretation of code will result in a slightly odd or absurd material, as is the case with the "whale." I like that there's always a notion of rules needing to be stretched when debugging enters the scene. For instance, how one defines a "6-inch tail" may be under dispute, but if one knows that there are general expectations of a material output, e.g., that it must be whale-like to a degree, then that will influence how one interprets/debugs the noise out of this message.
Thanks for such an in-depth explanation of knit debugging, @swlaiola. I debug programs a lot but I do not do textile crafts, mostly because I find the unforgivingness of matter really challenging, so maybe I can answer a bit from the other side.
The first difference I notice in this specific project is the outcome is unknown. It is rare in code to be debugging something unknown. The “bug” is usually one of two things: a syntax or other program error that prevents the code from running to completion — in this case, fixing means removing all the places where the program stops — or a logic error where the program does something that is not what was intended. In the second instance, fixing means finding out where the logic has fallen apart and mending it.
So in that sense, the question of debugging early doesn’t necessarily have a parallel. You can only debug what already exists. I would call early choices like language, code style, paradigm “architectural,” rather than part of debugging. This might be related to the physicality of textiles again, too. With code, it is relatively painless to do something, run the code to see what happens, change something, run the code to see what happens, ad infinitum. And so it is cheap for debugging to be less about doing things early than seeing what has happened and intervening then.
There are, however, two broad styles of writing a program: top-down and bottom-up. In the former, the programmer starts out writing their most abstracted code first and then undergirding it with the smaller functions, methods, and state that it calls for. In the latter, you will have still a broad idea of where you are going, but then you start writing the small girders first, checking in on their operation a lot, and building up. This tends to mean you are doing small debugging steps as you go, whereas the former can lead to much more difficult debugging. But it seems top-down debugging is also closer to using these sorts of patterns. You have most of what to do and then you fill it out underneath. I would call that maybe just doing the work, rather than debugging.
(Rant about “AI” projects that just produce nonsense left unwritten.)
This is a pretty insightful connection to me. At first I thought, “Well, no, there is nothing like ‘work as presented’, because a computer can’t make that inference,” but the use of defaults to allow a program to continue on in the face of incomplete information is definitely a tool in the toolbox. Interstingly, though, it is currently a less-popular approach in the programming discourse than having tight requirements and throwing errors when those requirements aren’t met. Sometimes this is because the assumption is that lacking data means the programmer has made an error and continuing without notifying is simply compounding the error. The closer a system gets to raw user input, the more the conflicts here come to the fore, I’d say.
This is definitely a real debugging tool: making the problem space smaller by only running some of the code. In fact, git, the popular version-control system, has a command that helps a debugger find the breaking code by finding which version introduced the behavior, so that then the debugger knows what to ignore. And there is the simpler method of commenting out code until the minimum broken case exists.
There is also an approach to architecture focused on making code “easy to delete.” The idea here is that robust code, so code you don’t need to debug, results from making code that’s easy to delete, which usually means it is code that is well-contained and covers only a small set of functionality.
In the end, I feel like what is called “debugging” in the case of the generated knitting instructions is perhaps an incorrect usage of the word (even though a fruitful misuse, as we can see from the length of this comment!) Debugging has a telos. What you have done is to complete the sense for a project that does not have sense alone. It does not have a goal; it does not have a purpose; so it can’t have bugs. It is rather a demonstration of how AI is a failure and needs people to help it along.
@Mace.Ojala Thank you so much for sharing the "Crochet Coral Reef" project! There's an entire rabbit hole of climate-driven data visualization in textile art we could go down with that sort of work, I'm particularly fold of some of the visualizations from "Temperature Textiles" : https://temperaturetextiles.nl/
I'm just trying to imagine what would happen if SkyKnit patterns were made by an equivalent human rather than a computer. This assumes that the human has never knitted, or has any experience with knots, or even seen or touched a textile - although that would be tricky. All they are given are a lot of knitting patterns (just the notation, no images of what they make) and are asked to make some new knitting patterns based on it. Perhaps the resulting patterns would be pretty similar?
Responding to: What are the similarities and differences between debugging a pattern and a program?
To my eye, the relation between debugging a pattern and debugging a program hinges on their different valuations of failure. Failure, understood as a deferral of closure that holds open the possibility of being, thinking and sensing differently, is necessary for a human body to translate a pattern into a material output. In order to turn a pattern into garment, a human body must navigate its specific histories, contexts and capacities and from them weave together a set of habits and hints that can guide the work of its hands and make sense of all of the messy irregularities that the pattern does not account for. In this way, the crafter’s body becomes a possibility space that gives the pattern meaning by failing it, by holding open its possible elaborations.
By contrast, programs require foreclosed futures in order to run. Speaking to the history of computation and more recently, the foreclosures of machine learning algorithms, Wendy Chun has detailed how the dream of computation is uncanny and draws on a eugenicist logic in which the present is pruned of its possibilities in order to produce a future that is a predictable repetition of one’s plan for it. Adjacent this, debugging a program is largely a matter of predicting uncertainty and mitigating against it, and of carefully distinguishing contexts so that they cannot interfere with one another at runtime. Where a computer is the space of possibility that turns a program into an output, and where, further, a computer cannot allow its inner workings to bleed into and infect one another as a human body can and must do, when one debugs a program, one is working against the possibility of failure, rather relying on it.
All that said, of course, between code and output a computer has to carry out a series of internal translations, and, of course, one can use computers to produce strange outputs that one did not fully conceive of ahead of time. This post is speaking specifically to the process of debugging, because in order to fix a broken program and get any output (exciting or otherwise), one must prune the present and work towards closure.
Thanks @acstanfield that is so lucid and clarifies so much for me. I agree that the concept of debugging comes with particular limited conception of how we interact with a computer and that there are alternatives where we embrace error.