I am not so interested in studying, reacting to, dismantling, this financializing "encryption" of the common.

I am interested in the common, and seeing it clearly seems simple enough. No need for elaborate studies of encryption and decryption.

I would like to understand how real systems help to manage the common and where they fall short: effectively I want to work with the systems we have without worrying too much about understanding every little detail, while to my eyes Haiven both:

1. valorizes reactionary too-detailed obsessions over exactly those details, and

2. hopes to abolish the entire system anyway.

I don't see eye-to-eye with him on either of these, but I especially don't understand the purpose of doing both. They are impulses so at odds with one another. Although one may benefit from seeking to "Know the enemy," I would characterize Haiven's perspective more as Fetishizing the enemy.

Imaginative cooperation of the common.

"The magnitude and scope of the potential for imaginative cooperation exceeds the imagination at the same time as it animates the imagination." (210, 212) (211 is an image with caption)
~ PRIVATE July 2 - Characters

". . . how we imagine and therefore contribute to the generative, self-organizing social organism of which we are a part: the common." (210)

Encryption and money.

". . . money . . . is one of the most adept and profound tools we have ever developed for reflecting and manipulating---in other words mediating---the common[.]" (212)

". . . I have sought to frame money as a capitalist encryption of our capacities for imaginative cooperation. . . a fundamentally [violent and] inaccurate method for coordinating and organizing social life." (156)

"In contrast, the neoliberal approach sees money as . . . a convenient and neutral expression of humanity's competitive and acquisitive nature. . ." (156)

Art.

Perhaps I have not read the book well enough, but I found no purchase on the positive topic of money art, or art money. There were certainly described examples of it. But what do they mean? There was little to interpret, and little interpretation which interested me. Haiven made claims in the introduction which I thought were interesting, but I don't know that he particularly built on top of them in what I saw in my skim through the book.

"[Art] only emerged under capitalism and coevolves with it." (14)

". . . art cannot be corrupted by capitalism because it has always already been derivative of capitalism." (15)

"Creativity, imagination, autonomy, symbolic communication and intellectual play would, I should hope, be integrated into the fabric of life, not (as today) encrypted, dead and yet alive, in a rarified sphere of "art."" (11)


Possibly I am simply not wrapped up in these art worlds Haiven occupies or is exposed to. If I was more interested in the goings-on of high value art and/or "HNWI (High Net Worth Individuals)" then maybe this book's exploration of art money and money art would mean something more to me, but as things stand I feel it serves to highlight my alienation from such a place.

It exists, of course, but my interest in it does not overlap too much with Max Haiven's. My interest for now is in remaining in blissful ignorance.

So what it is saying, if I'm claiming it can be put so simply? I will borrow Haiven's language to paraphrase what I can, but to be clear, this is an idea that I suppose could take 20 pages rather than 200, not an idea that I think can be expressed in a few sentence by me. I'm not an expert on the idea at all, and I suppose I can further excuse myself by claiming that the writing style is actively getting in the way of my comprehending it.

With caveat in place, what is it saying?

 Haiven reiterates a few terms throughout this book, fingers of a slightly larger idea which is not too complicated, and could have been explored more briefly. I'm glad to have only skimmed AAMMAA: most of the book is spent saying the same thing.

It is a good thing, but made unnecessarily wordy.

Here are some examples of disgustingly overdone lists (See SYNAPSE: ~Lists to better understand my perspective on lists) from page 212:

Quote. . . creativity, cultural expression, imagination, autonomy, and critique . . .

. . . fragmentary, indirect, cryptic, prefigurative, exploratory, experimental and ultimately impossible . . .

. . . better, more reliable, more autonomous, more trustworthy or even fairer . . .

. . . better express autonomy or creativity . . .

. . . better critique or castigate . . .

It is frustrating to see one idea, one good idea, stretched so thin whether due to inefficiency or a desire to (dare I say?) pad the page count.

QuoteThink very carefully how the data is used during the transformation process from input to output. You might realize that you need to [do X with the data, which would be easier if it was Y-structured.] . . . Data-oriented design is a bit of a departure from traditional programming approaches, but by always thinking about the data and how it needs to be transformed, you'll be able to reap huge benefits both in terms of performance and ease of development.

Here's where I feel engineering and design are at a crossroads. I'm not suggesting that OOP is better, but how do you think about the way data is going to be used in the future if you don't, and can't, know?

This article does not appear to address that problem. Data must be organized or searchable, and Llopis' proposed solution is to think ahead of time about every way in which you will need to access the data and organize it appropriately.

Again, OOP is not better; OOP says "this is the way to organize data", Llopis says "there are other ways to organize data, and you have to choose the right one for the circumstances."

Sometimes we just need a default data structure though, something we can use before we know what the circumstances are. In that case, is OOP best (I don't think it is), or is there another structure/paradigm that we can use?

Pingback ~Data-Oriented Design, when Noel Llopis says, "When we think about objects, we immediately think of trees. . ."

He is referring to the objects found in OOP, but there may be a more whole truth resonating with Alexander's argument here that suggests when we think about objects, we can only think in trees.

In OOP, the fabric is "objects," which works great when you happen to want to change procedures and data all wrapped up within an object (e.g. player movement controls), and not so great when you happen to want to change procedures and data strewn across many objects (e.g. your melee attack clips a wall and then contacts the potion that the enemy is holding in their hand), but so far this piece seems to suggest no replacement for objects.

Still, thinking about and reading this is helping me grasp the problem more firmly in my mind.

QuoteWhen we think about objects, we immediately think of trees

See also A CITY IS NOT A TREE, which suggests that people naturally think in trees.

QuoteModularity.

. . . data-oriented design is beneficial to both performance and ease of development.

I'm going to break Llopis' argument here up into a few pieces.

Quote- small functions. . . specifically to transform data
- functions. . . with very few dependencies on other parts of the code.
- The codebase ends up being very flat. . .
- lots of leaf functions without many dependencies

This level of modularity and lack of dependences makes understanding, replacing, and updating the code much easier.

My interest is not only in development but game design as well, and I can only speak to the marriage of the two. Often it is not very useful to change one small piece insulated from every other piece; if there is a problem, a design problem, it involves subtle changes to many interrelated pieces, and modularity can be troublesome if there is no intuitive fabric which connects the pieces.

QuoteHow do you actually get started with data-oriented design? . . . It's OK to think about it in OOP terms for now, just to help us identify the data.

HMm. I have some doubts about usefulness of this advice when the way to approach this type of thinking is to start by thinking about it in OOP terms, the way of thinking the piece is trying to reduce or get away from.

That is, Llopis elsewhere claims "we can make things easy for us and for the hardware and organize our data to deal with the common case of having many items of the same type" (i.e. in the DOD way) [emphasis mine] and now here is suggesting we can think about things "in OOP terms for now". Is this only because he's expecting people to come from an OOP perspective and they will need a little bit of a transitional period before switching over to DOD thinking, or is OOP thinking actually an instrumental part of the process here? Sorry for the interruption, Noel. Reading...

QuoteIdeal Data

If we look at a program from the data point of view, what does the ideal data look like?

Quote. . . large blocks of contiguous, homogenous data that we can process sequentially.

. . . large blocks of homogenous data, which allow us to process the data sequentially (see Figure 1b)

Nice. I like seeing this sentence practically repeated. It is absolutely central.

Understanding: What is data-oriented design (DOD) from Noel's perspective?

Quote. . . data-oriented design does not imply that . . . [it] exposes a large amount of functionality outside of code and lets the data determine the behaviour of the game. That is an orthogonal concept . . .

QuoteData-oriented design shifts the perspective of programming from objects to the data itself. . .

Okay, so my first grasp of DOD is that it's about pieces of free-floating data, unattached to the OOP concept of 'objects'. Is that all, though? Surely we need some tools for organizing data. OOP is also data-oriented, but it provides a particular lens through which we understand that data. All DOD is telling me so far is that the lens is unspecified.

1/3 cup maple syrup is about 60g of sugar.

Plain text of https://sallysbakingaddiction.com/whole-wheat-banana-nut-muffins/

2 cups (260g) whole wheat flour (spooned & leveled)
1/2 cup (43g) old-fashioned whole rolled oats
1 teaspoon ground cinnamon
1 teaspoon baking soda
1 teaspoon baking powder
1/2 teaspoon salt
1 and 1/3 cups (306g) mashed banana (about 3 medium or 2 large ripe bananas)
2 large eggs
1/3 cup (70g) coconut oil, melted (or vegetable oil or melted butter)
1/3 cup (80ml) pure maple syrup*
1/3 cup (80ml) milk (any kind)
1 teaspoon pure vanilla extract
1 cup chopped nuts (any kind—I use 120g walnuts)
optional: 3 Tablespoons oats and/or coconut sugar for sprinkling

(1) Preheat oven to 425°F (218°C). Spray a 12-count muffin pan with nonstick spray or use cupcake liners.

(2) Whisk the flour, oats, cinnamon, baking soda, baking powder, and salt together in a large bowl until combined. Set aside. In a medium bowl or in the bowl of your stand mixer, mash the bananas. Then whisk in the eggs, oil, maple syrup, milk, and vanilla together until combined. Pour the wet ingredients into the dry ingredients, stir a few times, then add the nuts. Fold everything together gently just until combined and no flour pockets remain.

(3) Spoon the batter into liners, filling them all the way to the top. Top with oats and a light sprinkle of coconut sugar, if desired. Bake for 5 minutes at 425 then, keeping the muffins in the oven, reduce the oven temperature to 350°F (177°C). Bake for an additional 15-16 minutes or until a toothpick inserted in the center comes out clean. The total time these muffins take in the oven is about 20-21 minutes, give or take. (For mini muffins, bake 11-13 minutes at 350°F (177°C) the whole time.) Allow the muffins to cool for 5 minutes in the muffin pan, then transfer to a wire rack to continue cooling.

(4) Muffins stay fresh covered at room temperature for a few days, then transfer to the fridge for up to 1 week.

MULE does this well, although perhaps only out of some technical limitation haha

In my case, how to justify a singular locus of collective attention?