January 30, 2008
HTML tables and exploratory programming
Today (or yesterday, depending on your time zone) Paul Graham has released Arc, his very own successor to Common Lisp and Scheme. I don’t care much about it, at least not in its presents state, but the article that accompanied its release is very interesting in its statements on exploratory programming.
What particularly struck me was his comparison of HTML tables with Lisp’s untyped lists.
First, Paul talks about the evolution of his opinion on untyped lists:
“I went through a stage, after I’d been programming in Lisp for 2 or 3 years, where I thought the old way of using lists to represent everything was just a hack. If you needed to represent points, surely it was better to declare a proper structure with x and y fields than to use a list of two numbers. Lists could contain anything. They might even have varying numbers of elements.
I was wrong. Those are the advantages of using lists to represent points.
Over the years my appreciation for lists has increased. In exploratory programming, the fact that it’s unclear what a list represents is an advantage, because you yourself are unclear about what type of program you’re trying to write. The most important thing is not to constrain the evolution of your ideas. So the less you commit yourself in writing to what your data structures represent, the better.”
I’m sure most Lisp programmers will agree to this.
Now, what about HTML tables?
“Tables are the lists of html. The W3C doesn’t like you to use tables to do more than display tabular data because then it’s unclear what a table cell means. But this sort of ambiguity is not always an error. It might be an accurate reflection of the programmer’s state of mind. In exploratory programming, the programmer is by definition unsure what the program represents.”
And yes, CSS still can’t do more than three columns, and even for three I would have to look it up.
Comments(6)
“And yes, CSS still can’t do more than three columns, and even for three I would have to look it up.”
It can, actually. If all you want to do is duplicate the look of a table, CSS2 specifies `table’ and related values for the `display’ property. The problem is that the major browser (read: IE) doesn’t support it. CSS3, on the other hand, specifies proper multi-column layouts.
As for the relevant quoted section of the article, I really can’t agree with his reasoning. If the programmer is so unsure of what (s)he’s doing, why not use a bunch of `div’ and `span’ elements rather than abusing `table’? Those elements are meant to be completely semantically meaningless, yet have hooks (`class’ and `id’, to be precise) for attaching behaviour (JavaScript) or styling (CSS) through which you can later refine your design. In fact, using `table’ elements forces you to think in grids, whereas `div’ and `span’ elements let you create free-form designs.
Forgive me if this is going offtopic. I just found his logic rather irritating. :-P
I suppose you can also nest DIVs to achieve a column layout with more than three columns. But this gets ugly, obviously.
As for why he didn’t propose to use DIVs, I can only guess. Tables are much easier to layout in a grid, perhaps that’s why :)
.
.
.
div {
float:left;
width:200px;
}
all the collumns you need.
I should have added “fluid columns”. Of course, doing it all float-left is easy with fixed widths. But I have never seen a fluid layout with more than three columns in CSS.
Leslie
I have to tell you this is one Lisp programmer who won’t agree with this.
I have been working on a very large codebase where everything was represented as a list. It’s a huge pain! After a while, I just dug in and started defining structures of (:type list) so that I could rip out all the calls to car, cadr, etc. and start saying things like (var-binding ) and (tree-children ) instead.
Later, when I figured out which were the most often-referenced structures, I started redefining these structures as normal structures, not list structures.
If Paul’s opinion extends from lists to structures implemented as lists, I’d be more inclined to agree with him…
I think Paul didn’t mean to say that everything should be a list. As I understand it, he values them as a great tool for sketching.