The complete working draft of my thesis as one pdf. Fil:Orstavik 2008 the language of programmers.pdf.
The umbrella introduction Sections of the PhD. As .doc-file: Fil:Introduction to taop.doc. Errata in the doc-file: p.4 line 4.: study -> studies on Article D front page method -> research method
added information about publication on all front pages
A Ørstavik, I. T. B. (in progress)."A theoretical framework for understanding the writing of computer programs".
2 Ørstavik, I. T. B. 2005. "Forms of time and chronotope in computer programming: Run-time as adventure time?". Conference proceedings from the XII Bakhtin Conference, Jyväskylä, Finland.
3 Ørstavik, I. T. B. (in progress). "Language shaping power: Bakhtin, Cassirer, and Phenomenology".
Medium:skrivepraksis.ppt Medium:A_dialogic_grammar.ppt Medium:A_dialogic_grammar_2009.ppt Morphology and Power presentation Method presentation
The Art of Programmers is a wiki for my PhD project. The art of programmers is work in progress.
- write chapter on theory
- write chapter on method
interdisciplinarity as research method my overarching method is interdisciplinarity. It took me a while to actually see how interdisciplinarity has affected my methodological choices in a systematic, consistent and primary way, but it has. There are several different way sto do interdisciplinary research, methodological choices to be made, and i must tell about mine.
Some choices. a) must understand both fields. important. b) Must engage both fields. necessary for a). Must write in both fields. part of b and a.
An interdisciplinary study is a narrow path between two or more big domains. This path probably touches upon several other domains as well. There are just too many threads that can be followed up to pursue them all. This problem is more acute, both for the writer and readers of interdisciplinary research than in disciplinary research I belive. No set standard as to what must be known that the commision can lean on. Openness is also more important.
In my study I have therefore followed several different paths leading to and from ICT engineering and dialogic studies. These paths have different methods, a) literature study in method article, b) chronotope analysis, c) a discussion about the need for new methods to analyze systematic features in diachronic, intertextual material, and d) subjective, qualitative analysis of language use in the other works. methods in a) is described on page x-y, b) on page z-æ, c) is a discussion based on theoretical knowledge and references to some example studies. d) .
This method has guided
- write article "the need for a dialogic grammar"
- write article "a framework for a dialogic grammar"
Intertextuality as a constraint/scaffold for the individual mind
- One way to view the phenomenon of writing programs, is that when writing a program, the writer needs to think how his program should work. This is to imagine. In this process of imagining a program text, the writer relies on and uses an intertextual soup of previous words, texts, voices, and other language resources that he has come in contact with, or can imagine coming into contact with. This intertextual soup is not the only resources for imagination, but the important one that I will focus on here.
Intertextuality is an important part of computer programming, since it is both an abstract entity and a concrete representation around a program in design or running. Abstract, a programmer writing a program does only very rarely imagine all the other concrete program texts surrounding his program. And learning programmers may not even envisage a single one of these concrete texts, thus having huge problems imagining his program. A programmer may also imagine and relate to many other program texts not part of the concrete program environment. The abstract, imagined intertextual environment for a program is therefore extremely situated and flexible.
Concretely, a program is directly linked to many other concrete texts, both run-time and design-time. These texts gives an echo of some of the linguistic, intertextual soup that the programmer imagines his program in. Indirectly, through use by others, a program can be indirectly linked to even more program texts. For example can a program use a library A that is used by yet another culturally, socially or situationally important library B. A programmer linking his program directly to A may therefore be acutely aware of library As connection to B, and expect library and texts in A to in the future change and echo library B and changes in library B. Such indirect, concrete connections between program texts may therefore influence a programmer's writing and textual choices and trump other direct links. The concrete, directly and indirectly linked intertextual environment is therefore also situated, having a highly different accent for different programmers at different times.
As the concrete and imagined intertextuality surrounding a program touches each other, they bridge the reality of written and working programs with the abstract ideas and thinking that programmers do about programs. Concrete direct and indirect links echo the ideas programmers create and the written conversations in which programmers realize these ideas (conversations with themselves and with others). Such concrete links also give the programmer a scaffold, a programmer can do such and such in his program because he can link to a library that assist him doing such actions. The act of writing with others /is, in computer programming,/ the act of ating with others. The words of other programmers and the grammatical means of other programmers are therefore the tools of the trade, a platform of resources that enables and constrains the acts, the writing and the thinking about writing and texts of programmers.
From this we can draw several interesting themes:
1) There is a difference between the imagined and concrete intertextual environment surrounding program texts and programmers. This difference is both a potential for innovation and a source for misunderstanding. As a source for innovation, a programmer swapping between several environments will se unused resources and possibilites as he imagines intertextual resources from other environments. This is not the only "difference potential" in a programmers mind, a programmer can also draw upon differences of environments from "intertextual environment" outside the realm of programming texts and languages (examples??), but it is a useful and direct one. Writers of compilers, teachers of programming and others trying to hurdle textual misunderstanding stemming from programmer disconnects with the intertextual environment, can use an increased understanding of what textual resources the programmer imagines surrounds his program and what textaul resources actually surrounds it, to help avoid textual misunderstandings. From this theory, a rule that programmers should be able to as directly as possibly see the texts and links to other programs that are part of the concrete environment of his program.
2) Changes in program languages /may/ reflect shared traits of programmer imagination. In current ICT research such traits are likely to be seen as "universal cognitive preferences". But other factors such as situational, cultural or social adaptation /may/ outweigh when new traits in programming languages emerge in communities. In all, programming language grammar and intertextual environments that are more "transparent" or "easier to link to new functionality" or "better structured" or "more similar to what I already know" etc. are likely to "win" (in a darwinistic sense) in the long run.
3) All such issues rely on a deepened understanding of the imagined intertextual environments. And a deepened understanding of the program in this environment.
4) If we understand the imagined environment, do we then also understand the imagined program? If we can somehow dig out an understanding from all the direct and indirect imagined links in a program, is there anything left in the program to be understood? I think that you can close the circle and build a coherent understanding of an imagined program by investigating its environment. But this is of course just one of several models to understand an imagined program, and other models does not need to use the intertextual environment as their point of origin. Intertextuality as a perspective on imagined programs should be coherent enough in itself, but not exclusive.
5) How can concrete intertextual patterns and links shape the imagination of programmers? Chronotope analysis is one example, the words of others as building blocks another, metaphors we live by a third(?), relate to Whorf-Saphir hypothesis discussion(?). Common to all these examples, is the intertextual environment. We need descriptions of how we can and do draw images in our mind from the written texts we surround ourselves with as programmers.
The other meanings of the words of others
How are program words interpreted? Both by computers and by humans? Are their meaning fixed, do they have duality of meaning? To understand this concept I will analyze the interpretation of computer program words (and grammar and other text) using the concept polyphonic determinability. Polyphonic means here "other voices". To find out if a words meaning is determined with other voices, the analysis is broken down in several steps. First, we need to see that words (*expressed/uttered words) are interpreted in relation to other words, and that these expressed words are at least partially independent, that is that a word can and do come together with other words, often in the same clusters again and again, but that the same word can appear in new constellations that are unique and maybe unexpected. If a cluster of words are always together, they can be considered one compound word. If words appear in varied constellation, and this is a relevant, important for their function, they form a poly-word object of study. Second, we need to see that these words are social, that they are expressed and interpreted by subjects with ao. independent will and a unique social, cultural and situational context. If so, the words expressed and interpreted are not just a product, but a process. It is the process or act of putting together words, not the product or constellation in itself, that is the object pursued by the agents. To express or interpret the words is something that is worth a while for one or more subjects. Without this liveliness of the words, without their creation and meating with other words, they have no value on their own. If any value is believed to be intrinsic for onw of these words, it is in anticipation of the word coming being expressed, interpreted by a subject, alone or in conjunction with other words. Such lively words, expressed and interpreted by subjects, meating each other again and again and anew, can be understood as voices. If the agents are heterogenic and free (varied and not in full control of each other), an important dimension should be taken into account. The subjects cannot control or foresee all the past, present and future constellations that a word and voice can appear. If the medium of expression and interpretation also enable the word to exist over time and travel, the determinability of words should not be analyzed synchronically, but viewed as something that can disperse into many situations, past, present, in parallel and in future.
Programming words. ok. First, we have the meaning of words. There is a common misconception that programming words are finite and singular in their meaning. That means that it is not relevant who interprets the meaning of a program word and in principle which intertextual context a program word is read. Experienced programmers would know that in practice, this is not the case. There can be "errors" or "features" or "nuances" in how words are interpreted in some part of the surounding system that one needs to take into account. But such practical hiccups might still mean that the idea of singular, finite, universal (what one might call "context free") meaning of words still is a valid theoretical idea. This is not the case. We start small, looking at how the words can have vague nuances.
First, floating point? or floating meaning? we can address the concept that interpretation of words are exact and singular. Lets take the very basic concept of division of a floating point number: 1.1 / 3. The result of this equation can vary from system to system depending on the degree of detail the system calculates numbers and on the basic algorithm for example the processor uses to calculate floating point numbers. Get example: 1) find two java systems working on different level of detail on floating numbers, and 2) find two processors running the same java impl but returning different results.
Second, when words fail. How do programmers make room for situations when a function and the "normal meaning" of a word fails? When writing a program, one needs to take into account that the words you use don't do and mean exactly as you intend in certain contexts. This is such a common and important part of writing programs that most advanced languages have several syntactic features to assist and simplify the programmer handling such exceptional situations. get example: a) a normal try catch exception loop. explain that the meaning of a word is marked as "open to failure", having the possibility of meaning two different things depending on the context. It would be good if the meaning is not a succeed or fail.
Third, bugs? should we include the empirical facts of bugs/features in our theory? or should we disregard them and build a theory of programming words for perfect systems and a world free of bugs? The example above can be excluded as the explicit description of two scenarios. However, what would happen if you did not write the try catch exception? Or a word that you do not expect to fail or behave differently, suddenly acts up in a certain context? The answer to both these questions is that you would have a bug, or a feature in your system. When writing programs, one assumes certain behavior of functions and meaning of words. This assumption is not perfect, it is based on your own knowledge of the system and context that you assume your program will run in. Which is perfect either, you cannot fully know what other systems your program will be included in in the future. The surrounding system and texts that implement the functions behind your words can for example be updated. Hence, your assumptions about your words' meanings are "omtrentlige" and "good enough" for the cases (contexts) you plan for, not exact and universal/singular for all cases.
Forth, intentional "other interpretation". Still, all the examples above can be read as imperfections, errors on a road that still will lead to an exact, universal program environment that we all strive for. Then, there are the cases when people deliberately mean different things with the same word. Programmers striving for different goals. You have the differences of style and syntax in programming languages. for example "a piece of text" + "another text" means different things in php and Java; + means text concatination in Java and numerical addition in php, ie. + means different things in this context in the two languages. Find an example of two camps that have different ideas about what a set of words should be constructed, camps that genuinely disagree about what should be done first and last in a similar 2-3 step operation. To get the exact same word, a new version of a package might be a good example, where for example more is added to a function in version 2. Here, the same words has two different known meanings depending on the context in which it runs.
Fifth, hacking words. Who says you cannot deliberately interpret other programmers' words differently if you want? The example of changing the word random. The full story. To get programs to do what you want, you might change their internal behavior by changing their external environment. As journalist might do to politicians, taking their statements "out of context" and putting them into a new one, you might get the words of others to mean something else, something that what you want. Assuming a universal and singular context and meaning for your words might therefore not only be a theoretically problematic notion, but also a practical issue: it might lead you to build programs that might easily be interpreted differently than you intend, for good and bad.
All these examples point in one direction. A program word is interpreted in a context of other program words. This context can vary from machine to machine, and over time on the same machine. This variation also changes this context, most often nuance and gradual changes, but sometimes abrupt and big alterations. How a program word functions and what it means changes with this context of other program texts. And since human programmers are writing the program texts and controlling their changes, the interpretation and its variation is ultimately a social and cultural phenomenon as much as a technical one.
What can we learn from this? As programmers we generally need to be aware of the different textual contexts that our programs will run in here and now, and other places in the future. Technical understanding of the texts that surround our program are of course needed, but we are also placing bets on how this context will look and behave in the future and making assumptions about the intentions and social dynamics of the other programmers that will make the changes to our environment. As student of human nature and language, we can learn that the same is true in programming as in other languages. We construct the meaning of our words, together and on our own, and that the easy choice, having a language with words meaning the same for all, for all times and for all places, is as unlikely in the real world of programming as it is in any other real world of human activity.