Turkle explores a lot of fascinating territory in this book. She looks at how, as the computer has grown more complex over the last two decades, our reaction to it has grown less hostile. We still think of it as 'different', 'not-alive', but no longer 'mere machine'. She looks at the history of Artificial Intelligence and Artificial Life, and how our metaphors have changed from symbolic, top-down, transparent, reductionist computation, to those of a connectionist, bottom-up, opaque, surface, holistic approach. With these changes in metaphor, we have become more willing to contemplate that a machine might be 'intelligent', and that we ourselves might be somewhat machine-like.
[Myself, I do not believe that the 'post-modernist', surface-only, approach is intrinsically better than the modernist reductionist approach. Rather, I think that each provides one possible way of thinking about a system, and that we need to use both ways, and more, to get a fuller understanding.]
And she explores some people's lives in simulated computer worlds, MUDs and chat-rooms, and how this allows them to explore multiple personae, allowing them a more decentralised view of the self. For some people RL (real life) is just one more persona, no more important than the rest.
Turkle is a social scientist and psychologist. She has gathered the material for this book by means of interviews with a wide cross section of users, and she uses these interviews to provide a wealth of fascinating illustrative anecdotes to flesh out her main thesis.
Very thought provoking fare. Here are some of the thoughts it provoked in me.
As computers have become more complex they have become opaque -- we can't understand them as machines, and experience them on their surface level only. We now interact with them by means of simulations -- not just video games, but simulations of pieces of paper, grids of figures, boxes of index cards, and filing cabinets.
In the 1970s and early 1980s, when people claimed CP/M and MS-DOS were transparent, they meant there was nothing to prevent them seeing what was going on all the way down to the bare machine. Now in the 1990s, claiming transparency for MacOS and MS-Windows, they mean there is nothing from the machine intruding to prevent them seeing and interacting with just the application: they 'think in MS-Word', the machine itself has become opaque. These two opposed usages reflect different styles of users: those who want to understand and be in 'control' at all levels, and those who want to use the applications. Interestingly, some people prefer MS-Windows over MacOS, because they feel it gives the 'the best of both worlds'; they can sit on the surface as a user when they want to, and they can drop down into MS-DOS when they feel the need, or when the surface transparency illusion can no longer hold.
I appreciate both styles. The order I was introduced to computers was: IBM mainframe and Cray supercomputer (early 1980s), BBC micro (mid 1980s), Sun Unix workstation (late 1980s), Macintosh (early 1990s) and MS-Windows (mid 1990s). As a user of applications (spreadsheets, word processors), I prefer the windowing 'surface' interface of the newer machines, but as a developer I really do need that extra level of control. And in my experience, MacOS gives the best surface, but is a pain when something goes awry ("I just want a command line so that I can tell it what to do" -- after all, we invented writing thousands of years ago because pictures only communicate if you already know what they mean). Unix gives the best depth, but is not at all easy for the novice or casual user ("Unix is a great place to live, but I wouldn't want to visit there"). So, whenever I use MS-Windows, I can always think of a different machine I would prefer to be using in that style (but, of course, it's not always the same different machine).
In the 1980s, programming was taught as 'structured', and 'top down design', and anyone who wanted to use a 'bottom up' or 'bricolage' approach was penalised. Turkle tells a story of the way she preferred to write essays: lots of ideas on little bits of paper scattered about, rearranged, gradually brought into a structure. So to satisfy her teachers, who were of the 'outline this week, essay next week' school, she would write the entire essay in the first week, then abstract an outline from it. With the advent of 'surface' computing, encouraging an experimental, 'try it and see' approach, the bricolage style has come to be a better way of interacting with computers.
I think the truth lies, and has always lain, half way between these extremes of total rigidity and total fluidity. Some structure is needed, but it is there as a guide, not an immutable framework, and when the details being fleshed out don't fit, or suggest a better approach, or reveal something previously unknown, then the structure is revised. Software design, or essay writing, is an iterative process.
And this fits in with how programming is really done. Every one knows the old 'waterfall model' (specification, then design, then coding, then testing) is some abstraction that rarely if ever happens in practice. Indeed, I remember being at a talk given by Edsgar Dijkstra where he himself said that top down programming was a good way to document a design, but he never meant it to be the way to do the design in the first place. So maybe Turkle and her interviewees suffered teachers who had fallen for the idea that the 'post hoc rationalisation' was in fact the development process. And maybe, in the 1990s, the message is getting through to those teachers. Let's just hope we don't end up spending a decade at the other, bricolage, extreme!