It turns out my blood is desirable, even valuable (a chorus of relatives and acquaintances cry in unison, “at least something about him is valuable!”). Yesterday, a representative of my local blood bank called to ask me to come in, right away, because they needed my blood. Since I prefer polite daylight phone calls to midnight tapping at the window, I agreed to come along voluntarily, and this afternoon I found myself walking through the fresh air and sunshine to the hospital.
That fresh air must have dislodged an idea jam, or something, because several neat ideas presented themselves while I was walking and bleeding. First, I thought about DigID — but I’ll blog that separately. Then, I thought about different textures of knowledge. Sometimes we know things in a precise, immediate, problem-solving sort of way; we can call that “acute knowledge.” For acute knowledge, one wants a consultant or fixer — there’s no point for most of us to have an electrician on retainer, because our homes are adequately wired. Other times, we know things in a long-run, habituated, way, which I thought of as “chronic knowledge.” (Someone smart like Clay Shirky or Jim McGee probably has already thought this out and developed more pertinent names for the phenomenon, but I haven’t taken time to check.) An acute approach to depression might entail saying, “Pull yourself together; suck it up and get on with life.” That’s why we go to therapists instead, who ask things about our childhood, and why HMOs then step in after twelve sessions to say, “Pull yourself together; suck it up and get on with life.” One might guess that practitioners of acute knowledge are quicker to propose more sweeping changes, and practitioners of chronic knowledge slower, depending on the circumstances.
Of course, that distinction is oversimplified, and where the interesting thinking comes in is in deliberating about the balances and nuances. Is ethics a field for acute or chronic knowledge? Many scholars in ethics treat the field as a set of acute problems, for which one might devise a consultant’s sort of fix-it answer; some others emphasize the extent to which ethics involves attaining the kind of life (ethos, ηθος, right?) within which acute problems arise less frequently, with less urgency and confusion. Again, neither sort is mutually exclusive.
Various people have different strengths when it comes to types of knowledge. Some folks develop storehouses of institutional memory and experiential knowledge, while others have their bright ideas in flashes. When a company must lay off workers, whom do they lay off, and how does affect the knowledge that abides with the organization? Questions such as that one stand usefully to be clarified by considering not just what someone knows or how long they’ve worked for the firm, but also how they know what they know.
Posted by AKMA at April 10, 2003 04:03 PM | TrackBackThe most basic duality that exists with variables is how the programmer sees them in a totally different way than the computer does. When you're typing away in Project Builder, your variables are normal words smashed together, like software titles from the 80s. You deal with them on this level, moving them around and passing them back and forth.
Posted by: Enoch at January 12, 2004 06:31 PMThe most basic duality that exists with variables is how the programmer sees them in a totally different way than the computer does. When you're typing away in Project Builder, your variables are normal words smashed together, like software titles from the 80s. You deal with them on this level, moving them around and passing them back and forth.
Posted by: Felix at January 12, 2004 06:31 PMInside each stack frame is a slew of useful information. It tells the computer what code is currently executing, where to go next, where to go in the case a return statement is found, and a whole lot of other things that are incredible useful to the computer, but not very useful to you most of the time. One of the things that is useful to you is the part of the frame that keeps track of all the variables you're using. So the first place for a variable to live is on the Stack. This is a very nice place to live, in that all the creation and destruction of space is handled for you as Stack Frames are created and destroyed. You seldom have to worry about making space for the variables on the stack. The only problem is that the variables here only live as long as the stack frame does, which is to say the length of the function those variables are declared in. This is often a fine situation, but when you need to store information for longer than a single function, you are instantly out of luck.
Posted by: Alexander at January 12, 2004 06:31 PMEarlier I mentioned that variables can live in two different places. We're going to examine these two places one at a time, and we're going to start on the more familiar ground, which is called the Stack. Understanding the stack helps us understand the way programs run, and also helps us understand scope a little better.
Posted by: Ninion at January 13, 2004 07:17 AMTo address this issue, we turn to the second place to put variables, which is called the Heap. If you think of the Stack as a high-rise apartment building somewhere, variables as tenets and each level building atop the one before it, then the Heap is the suburban sprawl, every citizen finding a space for herself, each lot a different size and locations that can't be readily predictable. For all the simplicity offered by the Stack, the Heap seems positively chaotic, but the reality is that each just obeys its own rules.
Posted by: Gartheride at January 13, 2004 07:18 AMThis will allow us to use a few functions we didn't have access to before. These lines are still a mystery for now, but we'll explain them soon. Now we'll start working within the main function, where favoriteNumber is declared and used. The first thing we need to do is change how we declare the variable. Instead of
Posted by: Margaret at January 13, 2004 07:18 AMWhen Batman went home at the end of a night spent fighting crime, he put on a suit and tie and became Bruce Wayne. When Clark Kent saw a news story getting too hot, a phone booth hid his change into Superman. When you're programming, all the variables you juggle around are doing similar tricks as they present one face to you and a totally different one to the machine.
Posted by: Ebulus at January 13, 2004 10:36 AMWhen Batman went home at the end of a night spent fighting crime, he put on a suit and tie and became Bruce Wayne. When Clark Kent saw a news story getting too hot, a phone booth hid his change into Superman. When you're programming, all the variables you juggle around are doing similar tricks as they present one face to you and a totally different one to the machine.
Posted by: Jennette at January 13, 2004 10:36 AMLet's take a moment to reexamine that. What we've done here is create two variables. The first variable is in the Heap, and we're storing data in it. That's the obvious one. But the second variable is a pointer to the first one, and it exists on the Stack. This variable is the one that's really called favoriteNumber, and it's the one we're working with. It is important to remember that there are now two parts to our simple variable, one of which exists in each world. This kind of division is common is C, but omnipresent in Cocoa. When you start making objects, Cocoa makes them all in the Heap because the Stack isn't big enough to hold them. In Cocoa, you deal with objects through pointers everywhere and are actually forbidden from dealing with them directly.
Posted by: Etheldreda at January 13, 2004 10:36 AM