Below are the 20 most recent journal entries recorded in atheorist's LiveJournal:

[ << Previous 20 ]

Tuesday, May 15th, 2012
4:18 pm	Vurt Vurt is a novel by Jeff Noon. The eponymous premise is that Vurt is a dream-realm accessed by putting special feathers in one's mouth. For example, using a blue BABY RACER feather causes you to dream of being a young skilled driver (whose real experiences were read using a special 'sucker' feather, then edited into a polished game-experience), at least for a while. Feathers are color-coded. Blue feathers, which are legal, have DRM so that after one use they turn cream-colored and are not reusable. Pink are pornographic (and legal, though age-restricted), while black are not legal, and yellow (gold) feathers are both illegal and potentially fatal. (It's not explored what agency regulates this color scheme, or why these objects are feathers rather than something else.) The concept of Vurt clearly derives from drugs, videogames (virtual reality), and magical otherplanar travel. The main character, Scribble, is a Vurt addict. Scribble's distinguishing characteristic, the origin of his name, is his habit of writing down his adventures in and out of Vurt (which makes me think that Scribble might be an author surrogate). Vurt addicts become bored with the same dreams, and seek out more and more extreme / exotic experiences, eventually seeking out very 'difficult' dreams that may not seem like fun to someone who does not do Vurt. The main character, Scribble, and his friends start out at a point where blue feathers are generally not interesting to them, and eagerly seek yellow feathers. In the opening, they complain about how tame a black feather called SKULL SHIT is, when using it involves the experience of, among other things, gouging themselves with knives. Scribble and his friends, the Stash Riders, are amazingly realistic addicts. Unfortunately, their (realistic) shortsightedness means they think very little about the how and why of things. This makes it difficult for the reader to discover much about the world they inhabit. For example, is the world a dystopia, or is their corner of the world dystopian, or is it just that they perceive the world as dystopian? This is a strategy, handwaving at some provocative features of the world and leaving the detailed worldbuilding to the reader, that many sf writers use. Things generally have more impact if you can get the reader to do them in their own head, just like jokes are funnier if you can get the listener to generate a taboo thought or image rather than stating it explicitly. Noon drops the word 'nanotech' a few times, and with sufficient acrobatics, we could piece together an sciency explanation of what might be going on. However, despite mentioning the word 'nanotech', it is probably better to understand Vurt as actually being a magical other-planar realm. Scribble's problem is that his sister, Desdemona, was trapped in Vurt, and due to a law of exchange between the realms, he received an slimy, tentacled being that the Stash Riders call the Thing from Outer Space in return. A possible nanotech-based explanation is that Desdemona, after putting the feather in her mouth, was uploaded to a distributed computer, and her body was reshaped into the Thing, a pattern downloaded from that distributed computer. However, there is no hint of this in the text, and it's a sufficiently gruesome and peculiar image that I think Noon would mention it. The overall feel of the book is relentlessly depressing - essentially all of the Stash Riders sacrifice themselves for Scribble's quest to swap back his sister one way or another, most fatally. There's a hint that I wish Noon had followed up on. CURIOUS YELLOW, the dream that Desdemona is trapped within, is a feather that forces the player to revisit their own past, and makes everything that occurred worse. If someone survives it, they come out stronger and/or more knowledgeable. If it had turned out that the entire story was inside of Curious Yellow, then the generally dystopian, dream-like feel of the book would be vindicated. However, it could also be argued that "it was all a dream" is a terrible way to end a story, even a story about dreams-within-dreams. In summary, I think it's an interesting book, though not for everyone. (Comment on this)
Tuesday, May 8th, 2012
7:17 am	creative destruction In Daniel Quinn's Ishmael, Ishmael argues that people are powered by stories, mostly implicit stories. In particular, he claims that most of (western) civilization is 'enacting' (a word meaning living-according-to or living-in-order-to-make-true) a story of humans-conquer-world. Ishmael focuses too narrowly on a duality between Leavers and Takers - if we can put that obsession aside, the general idea of a culture (or subculture) powered by an implicit story is very useful. For example, Jonathan Coulton wrote a song "The Future Soon", which (to many of us geeks) is recognizably the story we were enacting in our teens. It's also more than a little rapey. By making the implicit story explicit, we can now say things like "It's more than a little rapey." Without the text, criticism is impossible. Is he celebrating, enacting, or propagating rape culture via "The Future Soon"? No; he's holding a mirror up so that we can see ourselves better. If we made more stories exactly like "The Future Soon", could it turn into celebrating, enacting or otherwise propagating rape culture? Sure. But let's not - now that we can see the problem more clearly, we can deal with it, perhaps by kneading reality and fiction together (again). I'd love to read about a character who instead of (or in addition to?) fantasizing about a space lab in space, loves Jonathan Coulton's song "The Future Soon", but agree it's a little rapey. (Comment on this)
Friday, April 20th, 2012
2:02 pm	history If openssl says it's should be installed in /usr/local/ssl for historical reasons, what does 'for historical reasons' actually mean? It means there's a mountain of some sort out there in the world and we don't want to shift that mountain. The explanation for the mountain is a story (history) of "how the mountain got its hump", something like 'it was done like this in the past when the world was small, and then the world inflated, and so now everyone does it this way' (note that everyone is the mountain). Routinely told stories that appear to point into the past can also be read as saying something different (possibly more subtle) about the present. I tell myself stories about the origin of life, the human brain, religion, science, the american revolution. What do I mean by those about the present world? Origin of life: "Life happened to happen" becomes "New life could happen at any time." (and also "God does not exist.") "Life destroyed the sky with oxygen." becomes "Selfdestructive shortsightedness is endemic." Origin of the human brain: "Our ancestors were apes who lived in tribes and needed brains to handle tribal politics, including violence, sex, food-sharing." becomes something like "Everyone constantly thinks about the world in terms of politics of small tribes, including violence, sex and food-sharing". "Due to a coevolutionary red-queen race, brain size exploded." becomes something like "In some circumstances, constantly-increasing intelligence is important and inevitable.". (Comment on this)
Monday, April 16th, 2012
2:48 pm	Write-only code Open-Source licenses are based on the existence of source code. Source code is the 'preferred form in which a programmer would modify the program'. Bending a piece of metal causes linear defects to be generated and percolate through it. The defects get tangled, and bending-back a previously-bent piece of metal is far more difficult. This is 'work hardening'. Similarly, though a painter may have a small amount of time to modify a piece while they are painting it, the paint gradually dries, layers of more paint may not be able to get back to 'the same as' a previous good-looking state. There is no 'undo' functionality. Software engineering projects, as a general rule, slow down their pace of visible change over time. This suggests that software (often though perhaps not always) has a natural characteristic work hardening similar to metal. Certain diagram editors, wysisg website-building applications, source code editors (e.g. Smalltalk-based IDEs) provide a surface where something can be gradually built, including gradual change. The entity that is built may have a serialized form - something like a dense sequence of drawing commands filled with floating-point numbers, a block of generated html-and-javascript-and-serverside code, or an object dump of a virtual machine image. However, that serialized form is not exactly the 'preferred form for modifying'. A professional, given the task to modify one of these artifacts, may throw up their hands and perform nearly the same operations (gathering requirements, observing people interacting with the previous system, making design choices) as if they had been tasked with writing a new system from scratch. Or they may perform different operations (laboriously reverse-engineering and refactoring), but at cost comparable to writing a new system. My point is there may be no 'preferred form for modifying'. The 'source code' might be nearly useless for modifying. What might be advantages of write-only code? Well, you might want other people to produce write-only code. For example, Microsoft/Apple/Adobe and similar might want people to use their languages, IDEs, build systems, and document formats in order to lock value into their ecosystems. You might produce write-only code yourself if you were intending on giving the app and the source code away as an 'economic complement' strategy. You might be compelled by law (those open source licenses) to provide your source code, and you might not want to give up anything valuable to your competitors. If you just don't care about maintenance, then you might generate write-only code sortof accidentally. I'm not saying that there are any large advantages in speed or price, but if some dimension is ignored, and other dimensions are assiduously optimized, then usually there is degradation of the ignored dimension. You might not care about maintenance if you know you're not going to be doing it, either because it's a short-term product that you will not support, or because you don't care about whoever will be maintaining. (Comment on this)
Saturday, April 14th, 2012
7:35 pm	kneading reality and fiction together Art holds a mirror up to life. If we take a simple truth, that people are scared of the dark/strangers/et cetera, then there is art (scary stories) that reflects that. Art is also inside of life, and sometimes you can see the art/life boundary inside of particular pieces. There is causation within a story - a character sees a zombie and they run, for example. However, this "horizontal" or "within-world" causation is primarily effective at the fovea of the story, the stuff that happens on-screen, center-stage. As you chain backward, asking "why are there zombies?", you may get a sketchy answer within the story, but eventually the best answer is actually outside the story, pointing at the author's goals or message, or the audience's desires. There's a strategy, which I've seen in "Puella Magi Madoka Magica", Diana Wynne Jones' Dark Lord of Derkholm and most recently in "The Cabin in the Woods", where the audience's need for drama, and the author's machinations to create that drama, are made real (or is that made fictional?) within the world. ( spoilers ) I'm not sure what to conclude from this pattern - is it simply a technique used to point out and criticize blatant or mechanical attempts at pathos? Or can it be used in a non-critical way? Suppose that you took stereotypical porn "plot", and added a 'reified author' character, a manipulator who is trying to get titillating scenes to take place, and arranged for the protagonists of the stereotypical-story to become aware of the manipulator. What would the point or message be? Or a story about a sports team or individual either incompetent or down on their luck, who through grit and bringing their backstory to the game, gradually become champion material - and then discover that someone has been manipulating them, arranging for their initial misfortunes and later successes. Again, what would the point or message be? Perhaps the message of the entire story is not pinned down by the use of this technique, but the author of the entire story can put their message forward from the perspective of someone who was inside a genre and then was made aware of the requirements of the genre. On the other hand this technique might just be a way of providing the audience with the same old while lampshading it enough to give the audience plausible deniability: "I didn't go see The Cabin in the Woods to see a cute girl get killed, honest! I'm a fan of the genre subversion!" (Comment on this)
Thursday, April 12th, 2012
3:23 pm	nerikomi The opposite of Connascence Jim Weirich has written and talked about Connascence, the "if I change that I have to change this" connection between different parts of software. It may be exactly as important, or even more important, to talk about deliberate separation; gaps and walls of various kinds. There's many kinds of separation in programming. Separate fields within a record, separate frames in a stack, separate lexical scopes, separate namespaces, the kernel-space / user-space boundary, separate processes, staged computation (compile or deploy time vs run-time computation), the relation between an interpreter (or virtual machine) and the computation inside it. Time and space as metaphors Sometimes the separation is symmetrical. Symmetrical separation is analogous to distance. Sometimes the separation is asymmetrical, where A can affect B but B cannot affect A. Asymmetrical separation is analogous to time; we cannot affect our pasts. Humans have a particular "natural" scale of distance, something like cubits. We also have natural scales of time - instantaneous is somewhere around a fiftieth to a tenth of a second, a heart beat is longer than that, a conversation is still longer. Within a single room, our natural perception of time at durations larger than instantaneous is quite linear. However, if the speed of light were much slower, or if the story were spread out across a much larger space, then it would be more correct to understand time as partially ordered. Partial ordering of dependencies is the rule in software architectures. In order to create an accurate sense of partial ordering, perhaps we should imagine software using a metaphor of a story (or connecting web of stories) occurring across a nation in ancient times, when travel and communications were much slower. In legacy code, there's a tendency for new code to depend unnecessarily upon old code. Even in nonlegacy code, it's entirely possible for the relationship between components to accidentally become more linear than necessary. In Python, Ruby, and Javascript, there is often a single interpreter that runs over all of the source in some specific linear order. A programmer might lean on that linear order relatively thoughtlessly (of course they are thinking hard about other things), causing the code to evolve towards a roughly linear layercake architecture. One of the benefits of test-driven development is that the thing you are running repeatedly (the test suite) is not linear. Each test (at least conceptually) has its own timestream, so that the whole thing is shaped more like a bundle of short dowels rather than a single long dowel. It may be advantageous to introduce a feature for build systems and for test frameworks to always build or run in "as random as possible" order. The story of a piece of software Stories can (using multiple chapters with separate viewpoints) express partial orders. Chapter 1: Alice and Bob break a tally stick. Chapter 2: Alice's adventures in the Utter East. Chapter 3: Bob's adventures under the sea. Chapter 4: The two halves of the tally stick (stock and stub) are reunited. This is not that different from four separate files in a directory, one declaring an interface, another implementing the interface, a third consuming the interface, and the fourth connecting the producer and consumer. In most languages, everything is built from only a few object-building techniques and/or a few starting objects - for example, you might create a new object by sending a 'new' message to the 'Object' object. Those few initial objects, their behavior and relationships can be magical/circular/incestuous/paradoxical. They're a bit like creation myths (as I've mentioned before in this blog). Nerikomi software It might be possible to imagine the normal story of software as kneading, taking a single thing, separating it into pieces substantively but not completely (the separate pieces retain some sort of weak connection), and then combining the pieces back together into a composite whole. Kneading is one standard route to fractal structure and (if I understand correctly) it's one way ecosystems gain complexity - a single species is accidentally separated by some force or accident, then reunited, leading to an ecosystem with more species. Nerikomi is (one name for) the artistic process of creating patterns by layering different colors of clay, manipulating (rolling out, cutting, stacking) a 'loaf', and eventually cutting the loaf to form many richly-patterned slices. Nerikomi is a good metaphor for software because (ideally) the source code is considerably simpler than the richly patterned run-time behavior of the application, just like the relationship between the manipulations of the loaf and the rich patterns that result from those manipulations, or the relationship from a grammar to the strings in that grammar. (Comment on this)
Friday, April 6th, 2012
2:14 pm	possible offensive mansplaining First, I have to have a disclaimer. There's a pattern (on the internet) of pompous, ignorant "explanations" that simply echo and confirm the explainer's previous beliefs. This habit is often (though not always) done by males, and so is called mansplaining. I am certainly sometimes guilty of this sin. However, I love explanations. I want to make sense of the world. One of my favorite lines from Wrede's "Searching For Dragons" is when the squirrel who gives Mendanbar directions says "If you want explanations, talk to a griffin.". (I am a griffin.) Science fiction was expertly parodied as being ridiculously explanation-heavy. However, different people view the world in different ways (obligatory xkcd regarding umwelt), and though I might not do it all the time, sometimes I do perceive the world like that. Anyway, here's a riff on the theme of "what is the past and future of sex and gender?". ( Read more... ) (Comment on this)
Friday, March 30th, 2012
2:14 pm	the idea of a deity Plato invented the idea of an idea. It's very hard, perhaps impossible, to get into a pre-Plato frame of mind. People have, behind their closed eyelids, mental workspaces where we can put various figures, shapes and entities. Let's call those things representations (we could call them ideas, but I want a word that means 'idea necessarily inhabiting one mental workspace' - from a post-Plato vocabulary, an instance of an idea). Representations are often inspired by things out in the world; salt or pyrite crystals might inspire cubical representations in people familiar with salt or pyrite. By talking and gesturing, a teacher can sometimes work from their representation to inspire a similar representation in their students. Once a species of representation (e.g. cubical representations in many people's workspaces) is broadly established, it is very durable - humans are durable, they change their minds slowly, they infect people unfamiliar with it and correct misconceptions, and there's always the possibility of the original inspiration (salt or pyrite or whatever) triggering a new wave of discovery. Plato's Forms are a way of thinking about species of representations - that they're eternal (durable), non-spatial (widely distributed), sortof accessible to brains, and sortof inaccessible (see previous post regarding the firefly people vs. the quasar people; basically disagreements about ideas are better resolved as if the parties disputing are referring to a distant, inaccessible entity rather than entities inside their heads.) Big jump A principal and an agent have a relationship; an example is a merchant (principal) who hires a buyer (agent) to buy things on the merchant's behalf. The agent normally maintains a mental representation of the principal's desires or instructions, and also normally receives a consideration for loyal service. The idea of a benefit society is that the members keep the society in mind, and act as agents for the society as a whole. One member's loyal service to the society becomes another member's consideration for loyal service to the society. One service that benefit societies perform is insurance - each member pays small steady dues, and in compensation the society pays out larger lump sums in certain disastrous circumstances. In order for members to act as agents for the society as a whole, the members need to learn what the society officially desires, how members are expected to behave. It's like the official briefing of the agent by the principal. That document is something like the DNA of the society (see Snow Crash regarding the three-ring binder as the DNA of the franchise). Perhaps that document can be understood as a story, and the society consists of the people "enacting" that story - working to make that story true (see Ishmael by Quinn). So the distinctions between the idea of a benefit society, and a deity are pretty fine. Note however that the hyperbole about omniscience / omnipresence / omnicompetence and perfection of various sorts are just that - PR spin and braggadocio. Surely all the Catholics in the world are a powerful entity, but they're not infinitely powerful. A deity can easily be weak if it has few, or not-very-devoted followers. So to "create" a deity in this sense, you mostly just write a story. The story concerns things like how the believers of the deities behave, how they recognize one another, what their duties are, what benefits they receive, what divination procedures (voting, leader election are forms of divination procedure) can be used, how to relate to nonbelievers in general and perhaps how to relate to believers in specific other deities. The value of pantheons This is actually based on a presentation by Margaret Seidler; I'm probably mangling the ideas. Many times, we need balance two or more things; working and playing, planning and doing, speaking and listening. Seidler suggests picking two that are important to you and writing down: The benefits that we would get if we could balance these things. The problems that we would get if we cannot balance these things. The reasons it's important to do Foo. The reasons it's important to do Bar. The early warning symptoms of doing too much Foo. The early warning symptoms of doing too much Bar. Then the idea is to focus on one of these at a time, and switch promptly on the warning symptoms. Instead of imagining the world as many people, each with one deity (like the Medieval jokes that always start "so, a priest, a rabbi and a mullah..."), imagine a person as switching between different deities at different times. The family of past and future selves that are enacting a particular story/deity/idea form the support of that particular story/deity/idea. As part of the story, there would of course be relationships from one deity in the pantheon to the next. In test-driven development, there are three modes - getting to red, getting to green, refactoring. Supposing that "gettingToRed" is a mode of thought. How would you recognize someone in the gettingToRed mode from their actions? They're filled with grandiose vision, foresightful to the golden future with no consideration of difficulties between here and there. They're navigators, making sure we're aimed in a good direction. What are their duties? They add a small amount of text to the tests; they don't subtract text, nor do they edit the code. What are their perogatives? They inherit clean, beautifully well-factored code. When should they leave the gettingToRed mode? When the tests are showing red, the mode must vanish. It makes me think about three intertwined secret societies, each secretly performing services for the next in line, and being served in turn by the previous. (Comment on this)
Monday, March 26th, 2012
2:18 pm	Empathy What is empathy? Empathy is modeling something else as a thing like yourself, with stipulated differences. What is modeling? There are several old, closely-related techniques for modeling: system dynamics, queueing theory, process-oriented discrete event simulation. System Dynamics is like queueing theory with more floating-point numbers. Queueing theory is like process-oriented discrete event simulation with more closed-form solutions. Process-oriented discrete event simulation is like an operating system. An operating system (at least, an old one) splits a single real thread of control (the CPU) into several apparently-concurrent threads of control (the applications). The applications are like the CPU; both are threads of control. The applications are different than the CPU; they follow their own source code rather than the operating system. The relationship between the CPU and the applications is like the relationship between a human and a human's (empathy-based) concept of something. The CPU goes into the application, reads the application's code, and does what the application would do, if it had a CPU all to itself. The human moves into their concept of something (possibly another human), reads stipulations about how the concept differs, and does what that stipulated entity would do. What else can I say about empathy? Empathy can fail in two ways. One is that you choose not to use it. There's an activation barrier to doing any imagining of what it would be like to be X at all. It might be easier to think of it as something without inner life, either passive or inexplicable. Another way is that you do imagine something, but your simulation doesn't actually track the real world. If you want to succeed at empathy with computers or computer programs (a necessary skill for a programmer (at least until Bret Victor takes over (I for one welcome our new immediate-interaction overlord))), a standard strategy is to play computer, doing manipulation exercises with, for example, pencil and paper and cardboard and tokens. This practice makes it easier to get over the activation barrier. Secondly, you need to predict what computer programs will do, and compare the prediction against actually running it. By doing this second exercise you are debugging your internal model of the computer (or programming language or library). Is this a variant of the saying (Covey?) "All things are created twice"? (Comment on this)
Thursday, March 22nd, 2012
3:38 pm	discrete event simulation and bookkeeping Okay, this is an old (Halpin 1986?) discrete event simulation model. There's various entities which together are building something out of concrete. The truck goes: fill with concrete (needs a slot at the plant), haul to the site, fill the hoist (needs a hoist), back for more The hoist goes: get filled, hoist up, load the hopper, back down The hopper goes: get filled, fill the buggy, return The buggy goes: get filled, place the concrete, return What if these entities were businesses, and needed to keep accounting books? That is, the truck business would a general ledger that has entries for each activity. Resources normally have positive value, so money normally goes in the opposite direction of resources. Maybe the truck business might have one asset account for "empty trucks outside the plant", another for "full trucks near the plant", a third for "full trucks near the site", a fourth for "empty trucks near the site". What about revenue and expense accounts? From the other perspective, would the hoist business perceive itself as buying and selling trucks? Or the right to a truck? What markets would have to be in place? A truck-owning business with a full truck and a hoist-owning business with an empty hoist ought to be able to engage in a mutually beneficial interaction where the truck-owning business goes away with an empty truck (and some cash) and the hoist-owning business goes away with a full hoist. Suppose that contract was called a 'fill', then there could be a market for fills and speculators in the market for fills. The contract would have a standard orientation. Since the money is moving from the hoist-owning company to the truck-owning company, we would probably say that the hoist-owning company is buying a fill, and the truck-owning company is selling a fill. So on the truck-owning company's ledger, selling a fill looks like an increase to cash, a decrease to the revenue account (fills), a decrease of full-trucks-near-the-site and an increase of empty-trucks-near-the-site. On the hoist-owning company's ledger, buying a fill looks looks like a decrease to cash, a increase to the expense account (fills), a decrease of empty-hoists-at-bottom, and an increase of full-hoists-at-bottom. Everything is symmetrical. Suppose that there is a continuous double auction for fills on each side (the hoist side and the plant side), and the truck company acts as a price taker in both auctions. The truck arrives near the site, and immediately sells a fill, probably to a speculator. Then the truck might immediately execute, or it might waits until the speculator manages to sell the fill to a hoist and then execute. Then the truck goes back, and buys a fill, probably from a speculator, and possibly waits. If the truck company holds the behavior constant, and can act as a price taker, and can make a living, then its ledger accumulates information (prices and durations). It can use its records, together with a discounting rate, to generate prices. What is the correct (internal) valuation for a 'full-truck-near-the-site'? Well, if you have a long, regular log, then you can look for times when you had a 'full-truck-near-the-site', and the pattern of cash flows revenues and expenses that occurred subsequently. That cash flow pattern can be wound backwards using discounting to create a net-present-value of a 'full-truck-near-the-site'. If you have internal valuations, then you might be able to start acting as a price setter rather than a price taker. To set a price on a fill, then you look at your valuation of the situation after executing the fill, and your valuation of the current situation. Those will in general be different, and the difference is a reasonable price. (Comment on this)
Wednesday, March 21st, 2012
4:16 pm	There are two concepts which are routinely confounded in beginning and procedural programming - the decomposition of the problem into simpler subproblems and the call stack. There's a concept in Jackson Structured Programming of "program inversion". It is easiest to understand in the context of data stream processing. In many operating systems you could have two separate processes, a producer and a consumer connected by a pipe. If two processes are too heavyweight, then you might instead have a producer procedure that stays on the call stack for the entire document, and pushes chunks (perhaps bytes or lines) to a consumer procedure. Each chunk corresponds to a new call and a new stack frame activation - though each stack frame is in the same location on the stack. On the other hand, you could have a consumer procedure that stays on the call stack for the entire document and pulls from a producer procedure, which returns a chunk of data. Simon Tatham has a great article describing this. The decomposition of the problem into two subproblems, and the flow of data between those subproblems, is exactly the same in the push-style or the pull-style. Problem decomposition does not necessarily indicate which subproblem is "naturally" the caller. Object-oriented programming was invented with the language Simula; objects in Simula routinely corresponded to (cooperative) user-level threads implemented via coroutines. Therefore I think good object-orientation probably looks like an implementation of user-level threading. Vague and disorganized principles: 1. The activity loops in an activity cycle diagram may correspond to something like an OODA loop or PDCA loop if the entity is an agent. 2. Entities whose "activity loops" look like being born, living, and then dying, often should be closed into a loop by introducing a "World" or "Offstage" queue or pool. Every sparkle of light on the ocean, every drop of dew on every leaf, is a valuable part of the play and should not be created and destroyed lightly. 3. Basic (procedural) programming corresponds to empathy with the computer, being able to "play computer", and some introspection, being able to describe what you're doing. More advanced (object-oriented) programming corresponds to empathy with particular parts of a (possibly not-yet-existing) system. Being able to see an object oriented program from one particular object's perspective is important. 4. Very small code is normally actually very clean code, just like very short pieces of string are normally not tangled. It is about degrees of freedom and entropy. If you want to make some code cleaner, reducing its degrees of freedom (of formatting and naming to begin with, then more subtle aspects of style) and striving for brevity is a good guide. Squashing based on number of lines of code or number of characters while also relaxing formatting and naming conventions is not a good guide. 5. ints and strings scattered throughout your code is a standard code smell, so-called Primitive Obsession. Similarly, primitive control flow (if, for, while) scattered throughout your code is a code smell. Use abstraction, or you won't get anywhere. 6. Equating inheritance with programming-by-difference is a TERRIBLE software engineering practice. Imagine if you just appended patches to your code base, and the compile step stacked them together before doing the usual kind of compiling. Inheritance simplifies the client side (eliminating a dispatch on a type code, for example). Composition is what you should use to reuse implementations. 7. A standard way to build something that appears impossible (e.g. impossibly perfect) is to instead build something larger that, if it were visible, would appear possible (though it may well be more effort), and then remove some scaffolding. For example, you can build a dome by building a mound of earth covered with stones, then digging out the earth. (1 Comment |Comment on this)
Monday, March 19th, 2012
1:02 pm	distributed entities I'm interested in finding out in what sense Plato's or Decartes's dualism is true, or rather, useful. Box says "All models are wrong but some are useful." Why is dualism useful? Imagine that there are firefly-people, who derived various social and individual benefits from all flashing in unison. They form what we might call nations, groups of nearby fireflies that have reached a consensus that everyone will flash at a particular phase, something like the sixteenth hundredth of a second past the second, so that the flashes occur at 10:51.16, 10:52.16, 10:53.16 and so on. When two of these groups meet, they engage in a consensus-finding procedure at the border; the details don't matter, but the upshot is that a smaller nation will likely be absorbed into a larger one without much chance of change to the larger one. Imagine further that there are quasar-people, who flash much like the firefly-people, but who are very interested in the phase of a particular remote quasar. This quasar is so remote that it is extremely unlikely that the quasar people will ever be able to ascertain its true phase. Despite the lack of evidence, they discuss it incessantly and somehow come to a tentative working consensus - at least, everyone in the same conversation does, and a smaller conversation is likely to be absorbed into a larger one without much chance of change to the larger one. The distinction that I'm trying to draw here is that the firefly people are comfortable with their social construction of phase, and the quasar people insist that there is a fact of the matter (the actual phase of the remote quasar). Platonic forms are purported to be durable and do not have a specific location. A distributed entity, such as a file in a distributed, erasure-coded storage system, is also durable, and cannot be said to have a specific location, aside from the entirety of the storage system itself. What I'm proposing is that dualism, with its stories of "other planes", hyperbole about "absolute", "perfect", or "eternal", with special "privileged access" to the other plane via the human brain, is actually a set of tools for thinking about certain socially-constructed widely-distributed entities, which we (now) call ideas. Ideas (or memes) are files in the storage system of society. Thinking about ideas as files-in-the-storage-system-of-society is not as useful; it ignores the crucial behavior regarding seeking consensus at the borders, which is more like people comparing evidence of a remote, untouchable entity than it is like synchronizing file systems. However, I think the cosmology of Anathem is an example of the sort of ridiculousness that comes from taking Platonic dualism too seriously. (Comment on this)
Saturday, March 17th, 2012
11:44 am	A lathe is an instrument for creating things with a particular, cylindrical symmetry. A spaghetti maker is an instrument for creating things with a particular, linear symmetry. Symmetries (according to mathematicians) are related to transforms. For example, a cylindrically-symmetrical object looks the same even if you rotate it; a linear object looks the same even if you translate it. Possibly there is a general principle that if you want to make something that exhibits a particular symmetry, arrange to transform the work-in-progress repeatedly according to the corresponding transform. I don't really want to make (large, gross) physical objects, though. How does this apply to building software? Well, there is a form of linear symmetry for most (long running) software - it keeps running, looking pretty much the same. The simple, old, standard run/crash/edit cycle can be understood as applying a particular transformation (running) to the work-in-progress, and therefore helps to create time-linear software - software that stays doing whatever it starts doing. Hofstadter had an exercise of looking for a self-referential sentence of the form "This sentence has X a's, Y b's, Z occurrences of the letter c, and so on.". See here. The way that he (and others) looked for an accurate self-referential sentence is by iterating a transformation - take a trial (not truthful) self-referential sentence of this type, and add up how many of each letter it actually does contain. Then build a new self-referential sentence out of that histogram using the template sentence. If you iterate this process, and tweak the template, and tweak the starting point, then you have a surprisingly decent chance of finding a real fixed point. Coding Horror describes a peculiar strategy employed by Netflix engineers - they introduced a 'chaos monkey' whose job was to randomly kill services. This was intended to create a more-reliable whole. "If our recommendations system is down, we degrade the quality of our responses to our customers, but we still respond. We’ll show popular titles instead of personalized picks. If our search system is intolerably slow, streaming should still work perfectly fine." So if you wanted to create a palindromic piece of software, it might be reasonable to follow a cyclic edit-reverse-run or edit-run-reverse-run. If you want to create a portable piece of software, porting it repeatedly might be a good idea. If you want to create a system with multiple services that works no matter in what order you boot the services, systematically changing the order that you boot your services might be a good idea. If you actually want documentation that mirrors the structure of the code like the two sides of a Rorschach image (though I don't know why you would want that), transforming documentation into code or code into documentation is the way to go, not telling yourself or your team to "try hard to keep them aligned". Possibly this leads to a deeper principle. Why is it that it is a good idea to transform your code? There's an antipattern, Big Ball of Mud, that suggests that there is a natural entropy force, something like "slumping"; if you always boot your services in the same order, then accidentally you will introduce features that depend on that order. You might also describe Big Ball of Mud as "needle-felted code". Needle felting is a way to create a felt object by taking loose fur and stabbing it repeatedly with a barbed needle, the in-and-out movement of the needle tangling the fur together until it holds its shape (that is, it is felt). Those flat sheets of felt are not made by needle felting; instead, you put the loose fur (or whatever fibers) between two flat things and rub them together. That is, the flatness (translational symmetry in two directions), occurs from translation in two directions. It would be very difficult to create a flat sheet of felt by stabbing. Microsoft seems to have made made vast amounts of money based on a lot of apps slumping against the (richly textured and therefore difficult to replicate) windows API. My understanding is that they try hard to replicate that, trying to get, for example, games to slump against richly-textured graphics APIs. Can we use this slumping / tangling / entropy force for good? What is this concept of "rich texture"? Well, when you rip a piece of paper, (or break a stick) you create two, complementary, ragged edges. It is quite obvious, when you hold the pieces against one another, that they fit against one another. It is moderately difficult to forge something that fits so well, particularly difficult if the forger doesn't have access to the parts. Ripped paper is an example of a shared secret, which is a security primitive. Another example is creating a key and a lock - the key is a rough, high-entropy surface, and inside of the lock is something like a rough, high-entropy surface, the complement of the key. Similarly, the password is (ideally) a rough, high-entropy object, and the hash stored on the server is its complement. In Iain Bank's Excession, certain precious objects are stored in a "baroqued" form, inscribed with elaborate nanoscale patterns. Presumably the entities that inscribed them carry (complementary) memories of the patterns in their minds. Often, if software engineers laboriously needle-felt a piece of software, then they naturally construct a complementary structure, their understanding of the software; to some extent this is outside of their minds in design documents. For compiled languages, it might be source code. However, if the application is beautifully clean, tiny, and simple, then it is also low-entropy. This might be a motive for why businesses do not normally produce beautifully clean, tiny, and simple code - it's not ownable. (5 Comments |Comment on this)
Wednesday, March 14th, 2012
2:49 pm	a rational design process for classes (and tropes) Following Parnas's "Rational Design Process: How and Why to Fake it", here is a possibly-rational design process for classes. A class has a domain. For example, the domain of "trickery", one of Vladimir Propp's "narrative functions" is "folktales". You find occurrences of trickery in folktales, and the things that you might call "trickery" outside folktales are not really instances of Propp's narrative function. As a first step in the process, decide the domain. A class (or a trope) has an individuation. For example, you might slice music into measures, and then say 'this measure is like that measure'. Or you might slice music into voices, and then say 'this voice is like that voice'. An occurrence of one of Propp's functions might be a "turns" in the story. As a second step in the process, decide the individuation. As the third step in the process, imagine that entire domain is a big sheet of cardboard with complicated imagery on it. Slice the cardboard up according to the individuation, and shuffle the individuals. Sort the individuals into similar stacks. Each stack is a class; the contents of the stack are the instances of the class, and each stack has a defining quality (e.g. "this is the red stack", "this is the stack of female protagonists"). Now, if you need N classes, you just go through these three steps N times, and obtain them. (Not really). That's the rational process, but the point is not that we actually follow the rational process, but that trying (with errors) to follow the rational process is a good thing to do. For example, suppose that you have a rough class in mind; by holding the informal concept in mind, and going through the process, you might sharpen one or several of the domain, individuation, exemplars, or defining quality of the class. If you have one of the other concepts (a domain, a few exemplars, or a defining quality), then you can go through the process and get a new class. There are other good side effects from following this process. Often, for symmetry's sake, you will find that there is a consistency that is across stacks - for example, you might discover that you have sorted by color, or by size. This generally turns out to be an interface or abstract class. The other stacks may be interesting classes that you hadn't thought of. When you look at an exemplar, and contrast it with its defining quality, you may find your attention drawn to a manner that the exemplar differs from its defining quality - which may in turn form a seed to create a new class. You can figure out a relationship between two classes by their domains - if one class has a larger domain than another, then they might be in different levels of the application. If they have the same domain but different individuations, then if one individuation is finer than the other, then the classes might have a part/whole relationship. If neither is finer than the other, then there is a third individuation where you slice by both; investigating that third individuation might be valuable. (Comment on this)
Saturday, March 10th, 2012
11:54 am	standard applications for aspect-oriented computing Okay, I had this idea (styling architecture), which is basically a particular, visitor-ish implementation of aspect-oriented programming. Aspect-oriented programming isn't for everything, it's for things that seem easy, except that you 'sprinkle' them through your 'real' code, turning it verbose and unstructured. For example, you might have a simulation and animation, and it's all well architected and so on, but then someone says 'wouldn't it be nice if there were sounds?'. So "all you have to do" is go back through and sprinkle calls to play a particular sound through your code. However, that destroys your nice architected code. It would be nice if you could write the simulation, and someone else, a 'sound person' could come along, watch the simulation and hook appropriate sounds (in their expert judgement) into the simulation at appropriate points (in their expert judgement). Another 'sprinkling' is debugging. Some people really like debuggers that step through code; I don't, and I hate the way 'does it have a good debugger?' slows down programming language development. Moreover, some things (deeply distributed and/or real-time things) practically cannot be shoehorned into a standard debugger framework. However, sprinkling printfs as a debbugging technique is not great; as the hypotheses are eliminated during the localization phase of debugging, there's a lot of code editing and code navigating - which is slow and error prone. What I'd like is to repeatedly edit the same thing (the debuging/logging aspect), hooking different points to get lightweight, focusable logging. Achievements are another facet that might benefit from aspect-oriented programming; as the achievements person finds things to do which are awesome and deserve a reward, as they create the microcontent for the achievement (commentary text and badge image for example), they should be able to hook the achievement into the app without asking anybody else for a new event to be broadcast or a new counter to be incremented. Maybe even art generally - programmers can code default renderings (of blocks, blobs, single pixel sparks and so on), and then as artists finish the art, they can restyle the programmer art - that is, the content pipeline only flows one way (rather than circular iterations) and the content flowing through the pipeline is an actual playable game rather than images or animations. (Comment on this)
Wednesday, March 7th, 2012
10:12 am	ideas about ideas in other people's heads Okay, I've been reading Graeber's Debt, and I think he's muddleheaded and annoying some of the time, but very smart and insightful some other times, and perhaps his "obvious" muddleheadedness is necessary for his insights. Suppose that we're operating in Graeber's "communistic" sense - people give other people things pretty much whenever they ask, the way friends, family, or co-workers routinely operate. And we consider "What happens if a defector, an exploiter, tries to invade this society, and take without reciprocal giving?". Probably, there would be gradual bad feeling towards the defector, and eventually a relatively sudden outlash - Graeber mentions a story (iirc, he says it's Maori) of a glutton asking (and getting) fish from fisherman up and down the coast, until eventually they got together and killed him. In order for that gradual bad feeling and sudden outlash to occur, everyone has to be doing some sort of mental accounting; it doesn't have to be accurate, but there are a lot of computationally efficient ways of doing approximate counting or so-called "heavy hitter" detection. Suppose that everyone is doing rough mental accounting. How is it that everyone knows the SAME score, rather than each person making their own errors, and gradually drifting? Well, suppose that a person, A, signals their current estimated account with another person, B, marking it in details of the speech and body language. A also listens to B's estimate of the account, and (if A and B are on good terms), allows B's estimate to influence A's estimate in some sort of Bayesian/hearsay/information fusion manner. When everything is going smoothly, we can say that A and B both know "the score" rather than distinguishing "A's estimate of the score" and "B's estimate of the score". This grammar-like marking of score in speech and body language is exactly what Graeber calls hierarchy; that is, in order for Graeber's communism to operate correctly (identifying and casting out defectors), everyone has to be doing rough accounting (via something like sketches or probabilistic counters), publishing their current estimates in hierarchically-graded speech and body language, and correcting their estimates based on their peers' speech and body language. (Comment on this)
Friday, March 2nd, 2012
2:51 pm	Suppose you have two entities, call them Alice and Bob. Within Alice's mind is Alice's idea of Bob, and within Bob's mind is Bob's idea of Alice. What makes an idea "of" something? Well, it needs to track that thing. For concreteness, imagine a sprite that hovers below your mouse, that follows it around. Now, the nonobvious question (that nonetheless Brian Cantwell Smith asks and answers) is "What makes an idea different from the thing itself?". In addition to tracking, there has to be some sort of decoupling. For example, imagine that the sprite follows the mouse when the mouse is near Alice, but stays in the same location when the mouse is far from Alice - this tracking/decoupling makes it behave something like Alice's idea of where the mouse is. You could easily make up some sort of rules for a game of battleship, aerial dogfights, or submarine-vs-submarine combat, and get something mildly interesting working on four sprites (Alice, Alice's idea of Bob, Bob, Bob's idea of Alice). However, I think there's a more interesting kind of relationship - the principal/agent relationship. Suppose there's some sort of job-specification interface, where Alice can come up to Bob and say 'do this', and then Bob can work on that task. The task might be building a wall or mining a tunnel. If Bob, in turn, has the power to hire (or create) subcontractors (acting as a principal to them), to do various necessary tasks, then an entire civilization of subsubsub...contractors could be activated by a single sufficiently large order. Decoupling between the agent's idea of the specification and the specification itself could be mistakes or miscommunications. Decoupling between the agent's idea of its principal and its principal could lead to charging someone else for work done, or perhaps a player could hijack a portion of the civilization. (Comment on this)
Monday, February 27th, 2012
2:02 pm	I am incompetent, so don't take my advice as good advice; this is a tentative structuring of my own ideas for my own purposes. Videogames do not need a lot of story, or (sadly) particularly good story. Story that harms the uniquely game-ish elements of the game (e.g. long, unskippable cutscenes) can make some potential fans unhappy. Many successful games have story which, stripped of gameplay, is basically nanofiction. Though some authors follow something like the Feynman Nonalgorithm: Write down the problem Think very hard Write down the solution The rest of us may be able to create stories systematically, by hierarchical refinement, similar to Hemingway's Iceberg Theory or Schenkerian analysis in music theory, or for that matter, software design. ( boring details ) (Comment on this)
Monday, February 13th, 2012
1:47 pm	holons and collective agency What stitches people together into an organization? How could we improve that, and make smarter, more civilized organizations? My apartment building is an archetypal piece of Capital (buildings in general). It is a physical thing, but it's also an organization of lots of people - something like 80 apartments feeding something like cash in, various employees working part or full time on it and tapping some of that cash flow, and various owners/creditors dividing the remaining flow. It has walls, doors, locks, keys, security cameras - and I can't help but think that the pattern of mutual defensibility (of tenants from each other) and vulnerability (landlord vs. tenant) is a crucial component of the whole thing operating correctly - probably there are other crucial components, the relation of the building to the city, various documents promising certain services, legal structures for redress of failure to provide those services, and so on. The corporation that I work for has a big building too (Capital), and the badge that I carry is a sophisticated key, that allows me access to some rooms but not others, and can be revoked partially or fully from the security room. Those buildings (and the key management policies associated with them) support the organizations that they are associated with, much like a mountain valley with only two, easily-defensible passes might support a nation, or a natural harbor might support a city; the nation or city might change names, or the humans at the top might be swapped out, but the existence of a nation or city in roughly that spot is more likely because of the geometry of the situation. (Comment on this)
Thursday, February 9th, 2012
5:34 pm	connascence and cosmogony Jim Weirich uses a word, Connascence, for the connection between two pieces of source code, where if you changed one, you would have to change the other. It's a sort of cheerleading for example, "Connascence of Name" is the connection between two occurrences of the same name - if you want to change the thing's name, you will need to change both occurrences. Mostly the word 'connascence' is useful for dressing up a thing programmers were already talking about with a latinate neologism. There is a flow of something like time inside source code - not control flow at runtime - something flowing from early design decisions to later ones. There was a point in time where you fixed that name, and wrote those occurrences of it later. This is not actual history (or at least, it usually isn't), it's usually a refined, perfected, sufficient-for-version of the design process. I think of the great title "A Rational Design Process: how and why to fake it." Even if you swapped back and forth between several alternate interfaces between module A and module B in the actual history, for the purposes of editing module A (or B) there is only one thing (the final interface) in this virtual past. ( More abstract nonsense ) (2 Comments |Comment on this)