DemoCamp Toronto 9

Yesterday we had the ninth Toronto DemoCamp, at No Regrets. I got the impression that the crowd was noisier than usual -at times I had trouble listening to the presenters. A brief summary of the demos:

• DictaBrain – A phone-to-blog service: call to a phone number, dictate whatever you want to have in your blog, and the service does voice recognition and uploads the content for you. Don’t know how good really is the voice recognition, though it worked fine during the demo. Anyway, I can’t see myself using it -I write only 2-3 posts per week, I can always wait until I reach a computer, and I like pretty pictures with my posts.
• InfoQ – An IT news and articles website. It was partly a demo of their site and partly of some “funky AJAX” stuff. InfoQ tries to service five communities -Java, .Net, Ruby, SOA, and Agile-, and I guess they have a huge challenge in keeping the pace and offering innovative articles for all of them.
• ConceptShare – A service to share visual designs (web pages, advertisements, logos, anything), annotate them, and get feedback from experts. One of their goals is to shorten the feedback cycle between designers and clients, by sharing the designs through the net. The service seemed very polished and very convenient. Great stuff -the best of the night, in my opinion. And I can see how software development teams can also use it to speed up requirements elicitation and prototyping.
• The Email Company – They help you do web polls, surveys, email campaigns, and contests. Unfortunately things got really noisy at that time around me, so I couldn’t follow the talk fully.
• Pursudo – “What will the audience get from you?” “Hopefully someone here will get laid thanks to us”. It’s a website to hook up people; basically you say what you want to do and who you are, and people that want to hang out with people like you will get in touch. I don’t know how much of Pursudo is the service itself and how much is just showing off geek skills -the presenters were bragging that they developed it really fast, that Ruby is so cool it hurts, and so on.

Besides ConceptShare, the most interesting part of this DemoCamp was an annoncement by Jane Zhang and Nadia Gouveia, from The Partnership Platform. They’re looking for software development companies to connect them with non-profit organizations in software projects. It’s a very cool initiative; if it sounds like something you’d like to do you should drop them an e-mail.

Guanajuato at the Times

Today’s Travel Magazine of the NY Times (registration required) has a nice piece on Guanajuato, the best touristic spot near the city where I was born and raised, Leon (which sadly only gets two pages in my 1,000-page copy of the Lonely Planet guide to Mexico).
Guanajuato, a labyrinthine colonial city as old as it gets in Mexico, is a great place to visit all year-round. During October, in particular, it hosts its yearly “Festival Internacional Cervantino”. The shows are amazing, though I have to warn that the city gets impossibly crowded and noisy. The rest of the year the city is kinder to peace-loving visitors.

(Photo by tmtm_)

Brecht’s Galileo

It is at least unusual for dramatists to put scientists and the social implications of research in center stage. Bertolt Brecht -an unusual dramatist if there’s any- did just that, economically and elegantly, in his play Galileo. The scope of the play is incredibly broad: Plagiarism, elitism, relations with businessmen, with the Church, and with sponsors, the social responsibility of scientists, and the impact of their work on the general population; all of this concentrated in a few short scenes, sometimes in a couple of loaded phrases. Brecht, as in the rest of his plays, does not give us any answers, but he asks questions better than most.

The overarching theme, of course, is the fight to disseminate the truth when it hurts the interests of the powerful. Considering how religious dogmatism and political interests escalate their efforts to muddle scientific truth in our times, it’s still a very relevant read.

Syntax is not sugar

Let’s say we’re representing some information visually with a standard directed graph. We have four nodes (B, C, D, and E) all pointing to another one (A). We have several choices to display the graph. Here are two:

Are they equivalent?

In terms of explicit information being represented, they are. Both diagrams map to the same graph. Spatial placement of nodes is not relevant information in standard graphs (and in fact it is often performed by a visualization algorithm). However, a human will interpret them differently. Even at a glance, the first diagram represents centrality, the second one, hierarchy. More attention leads to more ambiguous and tacit meanings. In the diagram to the left, is node B conceptually “closer” to C than to E? Is it opposed to E? In the diagram to the right, is there a temporal reason for having first B, then C, D, and at last E?

We can play with the spatial structure of graphs a bit more. Each of the following tells a different story:

       

We humans use many hints and tricks, not always consciously, to communicate among ourselves. When communicating face to face, most of the content of the message is passed not through words, but through tone, volume, body language, and subtle moves, sounds and pauses. Face to face communication is very rich. When communicating with diagrams we also use plenty of extra “channels”. Spatial placement is one, but colours and weights, among others, help us to convey information that is impossible to capture formally:

So we see diagrams convey information implicitly, and a bit ambiguously. People in software projects use them this way all the time. What about other ways to represent information in software development projects? What about code? You’d think software code is a rigid, formal communication tool. It’s not. When communicating through code (yes, we do), we use whitespace, comments, and variable names to convey non-explicit information. Anyone with at least basic code reading skills will be able to detect personal coding styles just as we detect handwriting. We can spot sloppy hack jobs and thoroughly thought out methods; delicate fragments and routine calls.

This richness of communication is only possible thanks to some degree of syntactic flexibility in the languages we use. However, syntactic considerations have a bad reputation in many areas of academic Computer Science (perhaps in every area of Computer Science, except Human-Computer Interaction). Syntactic improvements to programming and modeling languages are second-class to the real stuff, the semantic formalisms and “expressive power”. The clearest indication that this is so is the term we use to refer to syntactic improvements: syntactic sugar.

It’s supposed to be a slightly derogatory term, a disincentive for discussing the topic. The sugar metaphor carries meanings such as the following:
• Sugar is tasty, but unnecessary. We can live without sugar. It adds calories but no nutrients.
• Kids love sugar, but us grownups have a developed palate and only enjoy it in moderate quantities.
• An excess of sugar leads to nasty health problems. Or as Alan Perlis said, “Syntactic sugar causes cancer of the semicolon”
• If a dish is not sweet enough, we can fix it easily: just add some more sugar! Everyone knows how to do it, and there’s no skill involved.

I think the term subsists because many computer scientists and programmers have an antiquated, simplistic model of coding. They believe the only communication act involved in programming is that of the developer formally describing to a computer what instructions to follow:

If this was the case, I would accept that the formal semantics of a language are the only thing that really matters. But in all but trivial cases, programming is not talking to a computer. There are many, many other communication uses of the same code in a development project –most of them among humans:

All of these interactions are vital in software projects. Software development, then, is not just talking to a machine -it’s talking to lots of other people through code and models. And since people will grasp meaning both from semantic and from syntactic cues in code and in models, both need our attention.

(Yes, I’m saying there’s semantics in syntax. Or rather, that our syntax is guided by informal semantics. Or, more eloquently and famously, that the medium is also the message.)

Computer Science loves formalism, but most of real software development consists of informal and implicit exchanges of information among people. Software engineering research must accommodate these informal exchanges. Syntax is not sugar –it is an elementary ingredient to make sense of our projects and activities. It should be studied as such.

Fun with representations IV – Chaotic libraries

Alright, moving on with the representation series! This time I’ll start with an old puzzle that I, by coincidence, got from Steve Easterbrook and, separately, from Angelika Mader in Dagstuhl with a couple of weeks’ difference.

We have an 8 by 8 grid such as the one in the picture. We also have rectangular tiles that cover two adjacent squares of the grid. First question: can we completely cover the grid using these tiles? It should be easy to see that yes, we can do that quite easily.

Two-square tiles

But let’s make the puzzle a bit more complicated: we’ll take away the squares at two opposite corners of the grid, leaving 62 squares instead of 64, as shown below. Second question: Can we completely cover this grid? If so, how? If not, why not? (No overlaps, and no putting tiles out of the grid!)

The answer may not be obvious this time. We can try to work out a solution only to see it fail in the end:

(I’ll go over the solution now, so stop here if you wan to work it out yourself!)

Let’s substitute the 8 by 8 grid with (surprise!) a chessboard. If you take away two opposite corner squares, you’ll end up with a shape like this:

Two-square tiles

Note how the two removed squares are of the same color. In this case we have 32 remaining whites and 30 remaining blacks. And since our rectangular tiles each cover 1 black and 1 white cells, we will only be able to cover, at most, 30 and 30. There will always be two squares of the same colour remaining, so there is no way to arrange our tiles in the grid.

The answer to this puzzle is quite elegant. It’s so nice that it works not only with 8 by 8 grids, but with square grids with even lengths of any size (including, say, a million by million grid!).

What is it about this second perspective on the problem that makes its solution so trivial? It avoids the issue with the first: problem size. With the first perspective (where we’re putting tiles in the grid to try and stumble upon a solution) there are so many permutations that it’s hard to see whether we’ve tried them all or, perhaps, the real solution is still hiding somewhere, and we just need one more try to find it.

Re-representing the problem in terms of number of blacks and number of whites avoids the size problem entirely. We don’t need to try out every permutation, we don’t need to try out even one.

I have mentioned before how defining whether a representation is useful or not depends on the tasks it is needed for, and on the context of its reader. Now I’m adding a third consideration: the usefulness of a representation depends on how it handles the size of the problem it is representing. Some scale up pretty well, some others don’t, and for large problems the difference is key.

Two more examples of problem-size issues before I’m gone. Both have to do with chaotic libraries.

In the book “How Would You Move Mount Fuji?”, William Poundstone describes several puzzles that high-tech companies, particularly Microsoft, like to ask to their hiring candidates. Apparently they like to ask, among others, the following: How would you locate a specific book in a big library? There’s no cataloguing system and no librarian to help you.

Poundstone explains: “Suppose the books are in random order, which they might be, for all you know. In that case, the best you can do is to scan the shelves methodically (…) On the average, you would expect to have to scan half the library to find a given book.” Ouch!

However, he continues, it is perfectly reasonable to expect that the library will have an order, any order, straightforward or bizarre. What we should do in such a situation, then, is to map out the library and try to detect patterns in the types of books in each shelf. “The best approach is to first try to learn the system, then use that system to direct your search for the book you want.” In other words, we need to transform our perspective; to go from a representation where size is all important (needle in a haystack), to one where size becomes almost irrelevant. Puzzle-solving, in particular, frequently depends on this type of transformation.

The most deliciously complex library that I have ever read about is Jorge Luis Borges’ “Library of Babel”; an “indefinite, perhaps infinite” collection of rooms, shelves, and books. The Library has existed forever, and there is nothing outside of it. Each of its books has a seemingly random sequence of letters, and some of this Universe’s inhabitants have conjectured that there are books for every possible permutation of characters, meaningful or not –every story and non-story can be found in it. At one point, the narrator mentions a superstition some librarians have: that someone, somewhere, has deciphered the order of the Library, that “there must exist a book which is the formula and perfect compendium of all the rest: some librarian has gone through it and he is analogous to a god.” Hereticals, on the other hand, “maintain that nonsense is normal in the Library and that the reasonable (and even humble and pure coherence) is an almost miraculous exception”.

I’d say you must read this short story if you haven’t. You can find its full text here.

Flashlight

Today I went to see a film, Macbeth, screening as part of the Toronto International Film Festival. Since I have been swamped with paper deadlines (hence the lack of updates here), I was frantically working in the theatre before the start of the show; editing a paper by the dim lights.

A lady sitting to my side saw me fighting the dark, and said: “You look like you need a flashlight.”

I responded: “Yeah, thanks.” And when she handed me one I added: “I have a research paper deadline.”

“Oh,” she said. “May we all benefit from your research.”

I thought it was a beautiful wish, and I wanted to share it for all fellow researchers.

Dagstuhl

Last week I was in Germany for a Dagstuhl Seminar on Methods for Modelling Software Systems. It was both quite fun and quite productive. I had the chance to talk to researchers whose work I’ve been studying since I started my Ph.D., and to get feedback from them regarding my own interests.

I guess part of the success of Dagstuhl seminars is that the environment is much more informal and flexible than that of a conference. There’s no official program prior to the start of the seminar. Talks and discussions can be added along the way. At lunch and at dinner, you’re assigned to tables randomly, so you get to hear perspectives from several people instead of joining the same clique all the time. And since Dagstuhl is basically in the middle of nowhere, there’s not much to do at the end of the day other than to visit one of the castle’s rooms and chat with other participants over cheese and wine.

In comparison, the conference format feels somewhat broken: There’s very little time for people to present their stuff, there’s too much going on at once, and the emphasis is on defending and selling your work rather than on exploring it and poking around to improve it. On the other hand, however, a big conference can hold a few thousands of participants, whereas a Dagstuhl seminar, I guess, would break down with over 50 people.

Cloud Atlas: mind-blowing

I know I arrived two years late to this party, but after hearing about David Mitchell just about everywhere I finally decided to give his “Cloud Atlas“ a try. It absolutely blew me out. It’s not just that the six stories in the novel, each with its own narrative style and voice, are all compelling in their own right. It’s not just realizing that they weave in mysterious ways, forming a whole much greater than its parts. And it’s not just that the underlying theme is so universal. The real kick comes from understanding that, above all of that, Mitchell is playing a game with you: Through subtle tricks (self mockery, metaphysical reflection in the midst of pulpy action, etc.) he admits his book is an ambitious, elaborate artifact, and he’s going to go ahead and do it whether you think it’s possible or not.

I won’t spoil it for you. But by the time I got to the end of chapter 6 (of 11), I had the same feeling I got as a child when watching circus performers do their crazy, risky acts: The man is going to kill himself. This should be the book’s ending. It’s been great so far, but it can only go down now, and when it falls it will be really painful. But it was almost as if Mitchell heard and replied “oh yeah? Well watch this…” and proceeded to get himself out of the traps he built, one after another, with perfect execution, while telling a story with a fascinating message that actually had to be told in the contrived Russian-dolls structure of his novel. And all along the higher-level game continued, with my jaw dropping further and further, my mind thinking the man is bluffing himself out of proportion, and Mitchell smiling, looking back at me and raising the bet anyway. When we finally reached the end I had to surrender, both to the virtuoso performance and to the powerful thematic conclusions. Very rewarding stuff for those with the patience to listen.