Micro-blog Idea

A much desired function of my calendar is the counter-part of the TODO list, that is, the DONE list. I need to keep a list of things I have done on a day to day basis, even if it was not on TODO before. It will also serve as a memo taker---some sort of a micro-blog, if you will. It will be different than a TODO list, where you cross things out when something is done and you forget about it. I want to remember what I have done and go back to it when I need to.

I need it because that's the only way I could show my professor that I have done reasonable work whenever he throws at me the "Angus, you're not sticking to your agenda" crap.

This micro-blog would be split up in different streams, some could become public, and others would remain private. It would be browsed over the web or pulled in as an RSS/Atom feed.

Now, it strikes me that SQL database is probably not the best way to implement the back-end for any sizable web application. None of the SQL servers I know of can distribute both load and storage across different nodes the way Google File System does it. SQL, the language, abstracts very little from bare metal, and many higher-level languages like ML that support higher-order functions can do much better in terms of abstraction.

Remember MapReduce from Google? The concept is so prevalent in functional languages that one can almost accuse them of reinventing the wheel. With more advanced compilers (like what Haskell has) that perform deforestation, you can even fuse together a number of MapReduce steps so you do not need to generate intermediate data set. Deforestation allows you to write easy to understand, pipe-lined programs without compromising efficiency.

I think there are many ways that databases can benefit from advanced features of a programming language. For example, the list that results from traversal of a tree index can be implemented as a lazy-evaluated stream, where the resulting list is generated on-demand. Many stream based operations are readily available, such as fold, map, and filter. Other fancy stream operations are also possible, such as taking the cross-product, distribute a set of lists in a round-robin fashion, and doing merge sort.

However, a major short-coming of any functional language today is the lack of a good XML library. People in this community have designed plenty of esoteric, experimental XML parsers and generators, but they are difficult to use in practice. It needs to be as easy to use as Javascript to DOM without sacrificing the power of functional programming, e.g. pattern matching, fold, map, and combinators---I don't know, maybe these are mutually conflicting goals.

We also lack a good HTTP client library. Ocamlnet is very powerful, but it is way too involved for casual usage. I think XMLHttpRequest is a great API that someone should implement. Its greatness is evident from the success of Web 2.0, also known as AJAX.

I'm afraid I have to leave this post inconclusive. I've drifted from an idea to the critique of possible solutions. In the end, I think the saying that ideas are worth (...insert your favorite object of no value here...) is true. I can only make a difference if I actually implement it.

So little time, so much to do.

DONE: spent 2 hours in the morning writing about a worthless idea.