Why Alan Moore is right, and why he's wrong

blog entry posted by lalo (Lalo Martins) on 2009-02-28 05:23:00

Tags:

Excerpt from Alan Moore's interview at Wired:

One thing is that with the comics medium, it has been proven—I believe by Pentagon tests in the late '80s—that comics are actually the best medium for imparting information to somebody in a form that they will retain and remember. That's not just me saying that, that's the Pentagon. I personally feel—and this is just pseudo-scientific hippie bullshit—I feel this might be because the unit of currency of what used to be called our left brain is the word. Our left brain is what goes about speech and rationality. The unit of currency for our right brain, conversely, would be the image, because the right brain is preverbal.

So perhaps it is because of the combination of words and images in a readable form that comics does have this unique power. Now, of course, movies are a combination of words and images, but they have a completely different structure and completely different way of working. With a movie you are being dragged through the scenario at a relentless 24 frames a second. With a comic book you can dart your eyes back to a previous panel, or you can flip back a couple of pages to check whether there is some reference in the dialog to a scene that happened earlier.

You can also spend as much time as you want absorbing every image. This is especially true of something like Watchmen, where I was trying to take advantage of Dave Gibbons' brilliant capacity as a former surveyor for including incredible amounts of detail in every tiny panel, so we could choreograph every little thing. The little symbols and signs appearing in the background, every little touch could be choreographed to the last detail, and we knew that the audience—because they'd be reading at their own pace—would be able to study each panel and to take in these almost subliminal details. Even the best director in the world, even a person as talented as Terry Gilliam, could not possibly get that amount of information into a few frames of a movie. Even if they did, it would have zipped past far too quickly. Because the audience at the movie theater is not in control of the experience in the same way somebody reading is.

One of my big objections to film as a medium is that it's much too immersive, and I think that it turns us into a population of lazy and unimaginative drones. The absurd lengths that modern cinema and its CGI capabilities will go in order to save the audience the bother of imagining anything themselves is probably having a crippling effect on the mass imagination. You don't have to do anything. With a comic, you're having to do quite a lot. Even though you've got pictures there for you, you're having to fill in all the gaps between the panels, you're having to imagine characters voices. You're having to do quite a lot of work. Not quite as much work as with a straight unillustrated book, but you're still going to do quite a lot of work.

And I have to agree. Comics are comics; you read it at your own pace, you analyse the details like it held the secrets of the universe, you enjoy the little hidden things both in the art and story, and you fill in the gaps. That's what makes it great, and that's why, no matter how well the movie is done, the comic will always be better.

(Well. In normal circumstances at least. I've seen mediocre books or short stories become great movies, but that's a separate story altogether, and to date I haven't seen it done with comics yet.)

On the other hand, I think dismissing the flick like he does is a waste of good entertainment as well. Time to quote from Dave Gibbons' interview in the same issue:

The most bizarre thing was to actually be inside the Owlship, you know? As I kind of implied in an earlier answer I've always loved drawings and measured plans of things. I went to a lot of trouble to make the Owlship convincing and make room for everything that we saw inside it. So, to actually be inside this thing—the thing that had been inside my head, I was now inside that. It felt exactly like the space that I'd felt when I'd done the drawings. I think that was really the strangest thing, to sit in the command chair and play with the joystick and press the buttons and watch all the lights flash on.

And that's where the magic really is. That's why those geeky movies are so great. It's like, well, going to a theme park, except usually with higher quality results. These things have lived in our imaginations for years, and now we get to see them there, big and real-looking. It's, well, fun.

Another important thing missed there is that movies can be a social experience. Comics, by the very merit of being read at your own pace, are solitary; you can get together with people to read comics, but you don't actually read together — well, you can, but it kind of ruins the experience. That's what is (well, used to be) so great about Heroes; it's kind of like reading a comic book, only I do it with my girlfriend, and we react together.

Short version? Absolutely do go watch the Watchmen, but not if you haven't read the comic yet. :-)

The Muse: Bipolar disorder type 2?

blog entry posted by lalo (Lalo Martins) on 2009-02-13 01:15:00

Tags:

Here's my latest archeo-neurological or archeo-psychiatric theory: “muse” is really an old term for bipolar disorder type 2.

It is my impression that old artists would sit around (or walk around) for days, weeks, doing nothing remarkable, or sometimes doing the hard, mechanical work of polishing up their creations. They would wonder where their “muses” are, why their genius is dormant.

And then one day, without warning, they feel that creativity, that exhilaration, that burst of awesome ideas, and a touch of insanity, that we've come to call genius; and they would attribute its less-than-constant presence to an invisible entity, the “muse”.

I believe, in our age, we call it hypomania, instead. A symptom of bipolar disorder type 2, a very common affliction that is frequently found in creative people. Paraphrasing Wikipedia, it's unknown whether creative types are more prone to be bipolar, or bipolars are more prone to be creative, or both are caused by a third, unidentified factor. What we do know is that the overlap is too great to be a coincidence.

Why is this interesting? Well, bipolar 2/creative people also tend to be romantics. So if you don't mind, I think I'll start referring to my hypomania as a muse, thankyouverymuch. It just sounds so much more desirable that way.

XML considered harmful, or,

blog entry posted by lalo (Lalo Martins) on 2008-10-25 15:37:00

Tags:

I have, on a number of occasions, stated that XML is harmful, and should be taken out and shot. So here I am today, to explain why I think that, and offer alternatives.

Not good for humans

The main problem is, of course, that XML was never intended for humans. It's not designed so that we can efficiently write it, read it, understand it at a glance, or maintain it. But many tools that use XML today tend to forget that, leading to hours of wasted time and lots of frustration. (XML for configuration files, anyone? Zope's ZCML and .Net's configs and all those Java frameworks?)

Then, of course, that's not XML's fault; it was never designed to succeed at that task. The fault lies with developers who misuse it. Well, yes and no. The reason people misuse it is because it's overhyped; XML is the new peanut butter (or garlic butter, according to Pete Abrams) — adding it to anything makes it taste better and sell more. (I don't even like peanut butter.)

Not good for machines

What it was designed for is communication between programs; an unified, extensible format for data transmission. By having libraries to handle it in most languages and environments, you'd make it easy for developers to deal with it, and as a consequence, to make their programs communicate.

However, after roughly ten years of working with it, it is my informed opinion that XML fails at that, too. I'm not saying it got supplanted by better technology which we invented later. It did, to be fair. But what I'm saying is that it was wrong from the beginning. And if it's not good for us and it's not good for our programs, why are we still using it? (Peanut butter, I know.)

So let's try to break out of the hype and prove that it's bad for our programs.

The perceived problem with XML can be summarised in one sentence: XML is costly to parse. But that's too superficial; let's go deeper, look at the specifics, and the flaws in philosophy/design that lead to this perception.

Parsing XML: layers

I usually tell my co-workers that there's two “layers” to parsing XML. While that is true, it's only true in the context of our data; if I were to make that statement more generic, I'd say: there's always at least two “layers” to parsing XML.

The first, the “bottom” layer if you want, is syntactic parsing. This means reading XML itself: tags, entities, attributes, comments, CDATA, PCDATA, white space, the works. The input to syntactic parsing is a string or stream of bytes; the “output” is an API — SAX, DOM, ElementTree, you name it.

On the opposite end of the stack, the “top” layer so to speak, is semantic parsing, or extracting the data you're actually interested in. The “input” here is a generic API; in the typical case of two layers, the API from syntactic parsing. The “output” is a domain-specific API or, more commonly, a collection of structured data (usually objects, nowadays).

An example where you may have more than two layers is when you're using something else built on top of XML; the most common case being feeds. So at the bottom layer something will parse XML, then another chunk of code will parse that as RSS or Atom, and then your semantic layer will actually extract the data. At work, we initially made our data available as RDF; so we had a second, “middle” layer (we actually used a JavaScript RDF library) which would parse the RDF, and then we did our semantic parsing by using the RDF library's API. That made our code a lot simpler, but it also made it a lot slower; so we later switched to ignoring the RDF and simply treating it as XML. (Even later, we switched to a JSON format.)

Syntactic parsing: too much structure

Syntactic parsing is what XML is supposedly “all about”; the point being, you don't see it. In our case, at work, it's done by the browser (which gives us DOM with a touch of XPath). In pretty much any other case, it will still be done by your environment (the browser, in our case; JBoss and .Net are other examples), or by a standard library.

Well, that's great, right?

It is, yeah. But it hides the fact that those libraries (even if it's “hidden” in the environment, it's still at some level done by a library) tend to be huge and ridiculously complex. The XML syntax is designed to cover an enormous universe of cases that your program will concretely never encounter, and yet, you have to pay the complexity cost for them.

Semantic parsing: not enough structure

XML shines on xHTML: a markup language for text, where you have arbitrary streams of text sparkled with special instructions about it. Some of those “instructions” are really containers, which have more text and instructions. XML does that really well.

It shines a little less on something like SVG, where it represents arbitrary streams of heterogeneous objects. Some of those contain other objects, and XML does help there.

But the truth is that, for representing your program's data? It probably sucks. Its model is very different from the object model of most (all?) popular languages and frameworks today. In the end, we find ourselves designing our data structures as many as three times: once in the language in which we're actually writing it, one in a relational database, and one in XML. The mappings between them are often poor, since the semantics of the three models are so poorly matched.

Sadly, it would be relatively trivial to pick a lowest-common-denominator model that would fit all of today's popular languages. But XML didn't even try.

That's not the whole of my objection, though. Due to the MASSIVE FAIL in the syntactic layer, we get a semantic layer that's only marginally simpler than it would be to parse a DSL (domain-specific language); maybe less simple, if you use a good library for your DSL. There are about half a dozen XML APIs in wide use; smart people are frequently getting annoyed at the ones already there and coming up with a new, better one. And although a modern offering like, say, ElementTree can be light-years ahead of SAX or DOM, it can't help being clumsy and feeling unnatural to the language; at the bottom line, what it's doing is dressing up a rotting corpse.

Conclusion

Here's a better phrasing then, for the problem of XML as I see it:

XML has too much structure where it doesn't help, and not enough where it matters. One of the reasons I love JSON is that it's not designed to mark-up text, or to transfer “streams of data”; it's designed to transfer objects (JSON means “JavaScript Object Notation”), which means it maps nicely to my code on both ends, whether that code is JavaScript, Python, C++, or even C. (It maps nicely to Java as well, but who cares.)

Alternatives (existing and ideal)

Right now, for real-life code, most places where you're using (or thinking of using) XML would probably be better served with JSON. A few more complex cases may justify a DSL, but I would hesitate a lot before going down that route.

Ideally, I'd like to propose a new format; an “active” derivative of JSON, inspired by the modern practise of “JSON with callback”. Essentially, I'd like to replace JSON's “flat” object notation ({'attr1': 'value', 'attr2': 'value'}) with something which looks like a Python constructor (MyClass(attr1='value', attr2='value')). The pseudo-classes (or pseudo-functions if you're looking at it from C) would play the role that tag names play in XML elements, which would make it even more straightforward to map this data to actual objects on each end.

This would, of course, lose the benefit that “JSON with callback” can simply be executed in a browser. But then again, “JSON with callback” is not formally correct JSON anyway, so we already sacrificed some portability for that ability. “Real” JSON is usually converted to “JSON with callback” by a simple routine on the server side. A similar transformation could convert the format I'm proposing into JavaScript; the fragment above would become: MyClass({attr1: 'value', attr2: 'value'}).

Freedom for Whom?

blog entry posted by lalo (Lalo Martins) on 2008-09-24 16:50:00

Tags:

I think I've seen this argument for the first time in a Slashdot comment, years ago. I've since adopted it, refined it, and used it a lot myself; but now in light of the Android release, I think it's worth mentioning again.

The big problem I see with “Open Source” is that there are, in fact, two groups there. Fortunately the same is not true of Free Software, but even our arguing that it's about freedom still doesn't help... well, read on.

The thing with “Open Source” is: who is it open to?

Arguably, Open Source, as a vague, undefined thing, has existed for decades. But as a conscious, named movement with its own marketing, it spun off from the Free Software movement in the late 1990s, after the “open-sourcing” of Mozilla and the publishing of The Cathedral and the Bazaar. (Or, according to some, it spun off a few weeks later, when RMS noticed those guys were talking about something else and split off from the Open Source initiative.) Still, in hindsight, one can say things like the BSDs, and even the original Unix, were done more in the spirit of Open Source than of Free Software.

Now Free Software, with all its GNU/FSF writings, has always been very clear about its goals. We're here for the freedoms of the user. If you get a piece of software, you have a bunch of inalienable rights, rights that aren't being respected by most software, and which we intend to uphold and defend. Nice, eh?

Open Source people, on the other hand, seem to be a little confused about this. It's like watching two madmen (or drunks) arguing, each founding an argument on an entirely different premise. Some, perhaps still in touch with the “origins” of Open Source in the 90s, believe it's about being “open” to the users of the software. Others have adopted the belief (from BSD maybe?) that it's all about “openness” to the developers.

(More importantly, some of them don't realise Free Software ≠ Open Source, and mistakenly argue this in even more confusing terms; like the old fallacy that the GPL, and viral licenses in general, are bad for Free Software because they give “less freedom” than BSD-style licenses. They do, if you're thinking of other developers, who will then have the “freedom” to “steal” my software and use it in their own closed software, and not give back to the project in any way. I don't care the least about those; I'm writing software for the freedom of my users, and those have their freedoms enforced by a viral license. Now are viral licenses bad for Open Source? Honestly, I couldn't care less.)

The Android platform seems to be firmly planted in the latter camp, sadly. (Or maybe not so sadly; I rejoice with every Java-based product that fails.) It's “open”, first and foremost, for handset makers and network operators, and a distant second, to application developers. “Openness” for the end-user doesn't seem to even be a consideration. Now of course, both things are pretty much incompatible; being “open” to the operators means, really, “open” for them to “close” it in whatever ways they want; so yeah, no VOIP.

Oh well. At least I don't need to be conflicted about whether I want an Android device, whether I can stand Java long enough to actually like the OS. Clearly, that won't be a consideration, and OpenMoko — or, if they fail, someone else, probably using LiMo or FSO stacks — will be the mobile phone for me. Eventually :-)

Creationists, I feel your plight

blog entry posted by lalo (Lalo Martins) on 2008-09-15 06:46:00

Tags:

You know what... I do understand and respect a family's right to believe any idiotic nonsense they want to. Who knows; it's a seriously messed up universe we live in, they could even be right.

But whether or not they're factually right is not what matters most in my book (which is not a holy book). Rather... their theories are grounded in a larger belief system, which has at its core a moral and ethical code. Telling the children in absolute terms that their parents beliefs are wrong, understandably, undermines the whole system, which in turn undermines the code.

(I'm not saying American creationists have a great code. Those are often the same people who are racists, xenophobes, or quick to judge someone by the bank account. But it's built on a good stem of what Americans call "work ethic", and arguably, it's better than no code at all.)

At the root of the argument is, in fact, a completely different wrong, which is the one I actually wanted to address in this post. The problem actually does lie with the (majority of) science teachers, who fall for the trap I call "the religion of science".

Good, respectable scientists almost never talk about facts. A fact, or rather an absolute rule, is anathema to good science; the only facts useful to scientists are the results of their experiments, everything else is theory.

What about bad scientists? Oh, those are frequently 100% sure of obvious truths, like, "the atom is indivisible" and "heat is a fluid" and "there's no such a thing as a memristor". (They're particularly eager to label things "impossible".)

The pattern here is: an open mind is the first pre-requisite for science, even more important than genius.

But in school -- and not only America, but many other places -- you only start hearing this kind of talk in college, or if you're really lucky, high school. Basic science, the teachers who were supposed to be giving children the basics of science and awakening potential future scientists, generally fall for "the religion of science". They "teach" absolutes; this is so, because that is so. Which is specially funny since some things they teach in basic school are known to be untrue, like Newtonian physics.

We wouldn't be even having this argument if school science teachers could behave like good scientists and formulate their teachings like, "evidence suggests that..." and "it is believed that..." and "apparently, ..." and, often, "this and that evidence points to the conclusion that...".

What, actually teach creationism in schools? No, now you're pushing it. Come on, the other parents also have the right to keep their children safely away from your nonsensical idiocy.

older posts