January 18, 2006

All Roads Lead To Lists

Sriram Krishnan : Lisp is sin

Over the last few days, there has been one thought running in my head - 'All roads lead to Lisp'. I've tried to get it out of my head but like a tune from the radio, it has firmly lodged itself into my head and refuses to let go. Why this state? Call it a confluence of several items. In particular, these 3.

I found the above quote and link via a recent post from Don Box. I can't really afford the time to browse the blogosphere, but my brain hurts at the moment while I fine tune the final text and code samples of three different chapters, so decided to quickly hit the "bare essentials", a list which includes (but not limited to) Don Box, Chris Sells, Tim Bray, Sam Ruby, Lambda-the-Ultimate, and the planet (Planet XML (http://planet.xmlhack.com)). NOTE: I realize I could get Tim Bray's posts via the planet, but there are times when I can't make it through the full list of "bare essentials", and as such I will start with Don, Chris, Tim, and Sam, and then move to Lambda and the planet if time allows, something that will more than likely happen this time around because of writing this post. But its an important post, and I'll get a quick glance of the planet (and hopefully lambda) in before I close out for the night... a day is not complete without a general feel for whats up in the land of XML and Lambda. :)]

Beyond the fact that the above post ROCKS! and taking the time to read it is a REALLY GOOD IDEA, one thing thats both relavent to this post as well as the Browser-based XML title (and as such, a justified expense in regards to what limited time I have available to spend):

In what I guess could be termed a "discovery" conference call [1] this morning with Eve Maler and Russ Miles, I mentioned to Russ I would add a certain task to my "list" and then commented that if it wasn't for lists I would never get anything done (even WITH lists I have a hard time getting things done ;) This lead to a "yet another reason why I'm such a Lisp Weenie as, to me anyway, everything is a list." (not an exact quote, but I don't remember the exact quote, and this is pretty close)

This would then lead to a comment that pointed out that I've even moved all of my HTML development (see this post from last February for more details) (In reality, XHTML... I don't actually develop using the HTML "DTD" anymore, but by habit I say HTML development) to unordered lists and list items (ul and li) for all document structure, and inline [2] elements such as p, strong, em, h1-h6, etc... (note: all of you CSS weenies who are about to leave a "p and h1-h6 elements are block level elements!" please read footnote two :) for the text of a document. In fact (DISCLAIMER: please see the bottom of this post as to why this site is a bad example of what a production page should look like underneath) if you take a look at the front page of this site [3] you'll see exactly what I'm talking about. Lists are the most powerful programming paradigm we have at our disposal. While you may believe that HTML/XHTML and programming have nothing in common, when brought into proper context you might be amazed at what the reality happens to be.

Using unordered lists and list items for the structure of any given site brings SO MUCH CAPABILITY along for the ride, that going back to even using div's causes me to shudder, much less tables! Even something as structurally "complex" (in terms of the number of columns and rows) as a calendar can easily use list items with pixel perfect precision as made example by the calendar on the left hand side of the the front page. Add to this the fact that you can then use that same markup as a source of data for other portions of your web page, and/or, (even better) use a simple atom feed as the data source to then generate the calendar using browser-based XSLT and CSS, and you may begin to see what I mean. In reality, the list items become the data source, but in terms of programming, I've never made a distinction between code and data... to me its all the same, its simply context that determines which is what, when.

BTW... For a much simpler example of this method (in regards to the amount of content, and therefore markup) as well as a better example (although not perfect... as usual I was in a rush :) of how a proper production page should implement CSS, see the nuxle.us project front page.

This is all I have time for at the moment, but I will try to post more content in the near future on this topic, and if all else fails, you can buy a copy of the Browser-based XML title when it releases (or pre-order it [note: oops, put the link to the other title Kurt and I are working on. Its fixed now :)] on Amazon now) as a significant amount of code and textual explanations has been devoted to using this method for your XHTML development.

Enjoy your List Processing-enhanced day! :)

[UPDATE: I wanted to use the following quote from the post, but when I chose the title I wanted to be able to tie it into the post, and the quote I chose (the first paragraph of the linked post) did a nice job of this... None-the-less, it occured to me I could still add it in, so here it is :

Paul Graham says in 'On Lisp' "The question is not whether Lisp..but rather 'when'". He also talks about Python and how Lisp features have made their way into Python. This brings forth an interesting question - will the next Lisp be Lisp itself? Or some other language? If you take a look at the programming language landscape, Python seems to be the frontrunner now in terms of bringing Lisp features to mainstream programming.

---
[1] : While email can be an effective tool, there are times when actually speaking with folks "live" is necessary to gain a greater understanding of something (in this case a better understanding of SAML from Russ and my side, and LLUP, (and, in part, nuxle.us and ChannelXML) from Eve's) as well as to bring a sense of reality to a world in which virtual reality is the norm.

[2] : although, technically speaking, a paragraph (<p>content</p>) and h1-h6 are block-level elements (speaking in terms of CSS), I tend to lump them with other inline element (an inline element is, technically speaking, any element that doesn't break the text of any given document (<strong/>, <em/> (<b/> and <i/>) in HTML terms), etc...) as I tend to think of any element that is designed for marking up text as inline elements, even though, as pointed out, this is technically incorrect.

[3] : The page you are looking at (if reading this on the web, instead of a feed reader [4]) isn't completely converted to list items as I never got around to finishing the conversion of the MT template for the archive pages, and never will... I'm only using MT at the moment as I haven't finished off my own "built from the ground-up" blogging engine, and any extra time I have at this stage is not going to be spent on something I don't plan to use in the long term.

[4] : For those unaware, the Atom feeds for this site always have, and always will, provide the full-text of each and every post.