Saturday, April 30, 2016

The Unconscious: Lacan vs Freud

Since approaching Freud's Unconscious via Lacan in recent times, I have come to appreciate the power and flexibility of an Unconscious that is "structured like a language", and in which the "exteriority of the symbolic" makes the Unconscious also transindividual.

Although a direct comparison from any one point in time in either's men's careers is always provisional, due to their ever-evolving theories of the Unconscious, it was nevertheless grounding to read again an early lecture by Freud on psycho-analysis today (from "Five Lectures on Psycho-analysis", 1909). He reviews the early development of his theories, starting with Joseph Breuer's hypnosis experiments.

It is here that we encounter a more sensuous, energetic version of the Unconscious with an obvious intuitive appeal:

... in one and the same individual there can be several mental groupings, which can remain more or less independent of one another, which can 'know nothing' of one another, and which can alternate with one another in their hold upon the consciousness [..] If, where a splitting of the personality such as this has occurred, consciousness remains attached regularly to one of the two states, we call it the conscious mental state and the other, which is detached from it, the unconscious one. (p. 43)

It is as if there are two rivers, both active, but at any one point the one is subterranean and the other in plain sight. Yet both influence each other, due to their connected volumes and velocity.

If we try to find a metaphor that is closer to Lacan's concept of signifying chains we must perhaps compromise on something like electricity, the movement of electrons, and the logic gates of electronics.

Yet another interesting, but as yet unexplored metaphor, might be that of linked quantum states.

I'll leave that one for another day.

Sunday, March 06, 2016

Can Interactive Fiction be Improved?

Like many readers old enough to remember the 80s, I have fond memories of the "Choose Your Own Adventure" series of books, as well as their more sophisticated cousins, adventure gamebooks like "The Way of the Tiger" and "Lone Wolf". So when I recently looked into interactive fiction again I had high hopes that the genre had really been brought into the 21st century.

I wasn't entirely disappointed. Once upon a time an author would have had to make do with simplistic platform engines, or even write one herself. These days the developer has a much slicker experience thanks to the likes of Inform and Spatterlight. The author can focus on writing a good story with rich options, rather than working around the system.

On the down side, however, as a would-be-reader-slash-player I found the interfaces to be rather clunky. As a power user of *nix style terminals, typing in commands such as "look" and "go" and "<object>" will drive me insane very quickly. I expect tab completion, shortcuts, custom hacks, and quite frankly having the option of moving forward by doing nothing at all. Programmers are lazy.

Clearly, this is in part due to the genre's roots, a throwback to the ink-and-paper world of physical books. So I've been wondering, what if the interactive text interface doesn't try to be an interactive book? Because, given the choice of reading through reams of text, or navigating a little character across colourful, scenic screens and interacting with other characters visually, most people choose the latter. It's a stark choice. Hence the popularity of gaming as we know it, while interactive fiction is comparatively languishing.

What if there was a middle ground? Imagine a game where the interface can be discovered via tab completions, as well as clever command combos, where those behaviours actually prove to be more efficient than walking through various screens. Could that not attract some gamers back into the world of text adventures, while opening new possibilities for non-gamers?

If this sounds farfetched, consider the choice a *nix user makes every time he or she fires up a terminal to execute a complex set of commands, versus the same outcome achieved in a Windows world. The terminal experience has a number of advantages: command-discovery, accuracy, programmability, repeatability. That's not to say window interfaces don't have strengths, they certainly do! But most power users I know have learned to love the terminal, even on Windows.

My question is simply this: can the strengths of terminal command line interfaces be leveraged to create compelling interactive fiction?

Perhaps if we did, we wouldn't actually call it interactive fiction anymore, instead it would have the look of fiction, the intuition of programming, and the responsiveness of gaming.

And that's a triple win.

Sunday, February 07, 2016

What Shakespeare has in Common with Software Development

Shakespeare is widely regarded as the world's leading playwright in English, and perhaps any language. Such is his influence that phrases and ideas coined by him at the turn of the 17th century still live on in our colloquial speech today. Romeo and Juliet is shorthand for passionate, ill-fated love, and quotable lines from his works permeate our treasure trove of idioms and phrases.

What is perhaps less well known is that many of Shakespeare's plays have no definitive version. Take "Hamlet", for instance. There is the famous First Folio version, compiled and published seven years after his death, and there is the First Quarto version, a.k.a. the Bad Quarto, and then also the Second Quarto version. None of these versions are considered 100% definitive. Edited versions usually combine parts of each to present the modern reader with the most feasible "Hamlet", and even these are subject to change.

How did this happen? So many details about that time have been lost to history that it is difficult for us to reconstruct a real sequence of events from the remaining evidence. There are entire books written to argue one case or another, but consider that some people even dispute William Shakespeare's authorship, then it is clear that we are on shaky ground from the get-go.

Personally, I've come to a different view while mulling over an under appreciated ingredient of Shakespeare's genius, an aspect that has something in common with software engineering - especially agile development.

Shakespeare wasn't just a writer, he was also an actor and part-owner of the theatre company the Lord Chamberlain's Men (later the King's Men). I find it useful to think of his plays as a function not only of Shakespeare's maturing talents as a writer, but also of the needs of the company. Those needs were financial, like any company's, and were directly informed by the success or failure of a particular play in the eyes of the audience of the day, as well as the tastes of their influential patrons.

It is thus hard to imagine that Shakespeare would just write a single, finished version of Hamlet, tell the actors their lines once-and-for-all and be done with it. As part-owner he had a responsiblity and exposure that went well beyond writing. He would have wanted to make sure the play is as good as it can be, on a continual basis. The company would receive financial feedback, and the company's patron would have his say, and so the day-to-day operations would hone the way the play was performed - if it was performed at all.

As an actor of second-tier roles he would also have been in a unique position to experience feedback from the audience. I imagine him night after night, observing the audience's reactions, hearing them laugh at the funny parts (or not), seeing them moved or engaged during tragic or passionate moments, and smiling or bored as the case may be during the play or afterwards. He would be thinking of the various stakeholders, of the dramatic value of a particular phrase or scene, of the audience's reactions, and so he might choose to change the lines - add a bit more zing, create more drama, more references to current affairs - who knows?

Shakespeare's mind would have been working constantly to improve the play and I have no doubt that this is precisely what happened. His plays have a uniquely organic feel to them, as if the action is happening right there, and the actors could step off the stage and mingle with the audience at any moment. By assimilating his audience's emotions and interests he was bringing art closer to the audiences' reality.

It is this approach of continual improvement, of being tested night after night against a real live audience, that strikes me as being very much in the spirit of agile development. It's a bit like running continuous integration while already in production.

I would go a step further and suggest that Shakespeare was so canny and pragmatic that, even if he had a successful version of a play, should the political climate change he would be willing to adapt the play again, to cater to his audience and so prolong the play's financial success. If this is so, he may well have found a dramatic architecture that admitted of continual adaptation, just like good software architecture is flexible, and written with ease of maintenance in mind. That would certainly go some way towards explaining his plays' capacity to be continually repurposed for modern audiences.

To put that achievement into perspective, imagine writing software that is still in demand 400 years later!

If we take this view it is a bit of a shame that not more of our worthy literary works are "production tested" with a feedback loop that permits continuous improvement. There was a time when serial publication afforded authors some engagement with their readers, and thus to inform the next installment. Nowadays, authors are required to write once, for all time. But in software development we know that this is usually premature, costly, and occasionally disastrous.

This is the reason that many writers form reading groups with other writers, to permit them a trusted soundboard and source of feedback. But the General Reader is a different beast, whose tastes are not to be tamed so easily. Shakespeare wrote "not for an age, but for all time", and perhaps it's because he wrote not once, but all the time. He understood the value of his users.