Google Wave is impressive

So, if you haven’t noticed yet, Google Wave happened recently. If you have like an hour to kill for some really impressive tech demo, you might want to take a look at the video on the link.

Its a fairly ambitious project, one that merges email and chat into one seamless application. I call it ambitious because it tries to do the following simultaneously:

• Merge real-time (chat) and asynchronous (mail) like communication together. They had that going on in a somewhat crude form (compared to google wave) with gmail’s chat.
• Instead of independent messages being sent either way it more about editing a collaborative document. The concept is fairly close to a wiki except that its also real time.
• It has a decentralized architecture where pieces (also known as wavelets) of the collaborative document can originate from multiple domains and can be edited. The various pieces or wavelets can have
  • Domain scope: some parts of the collaborative document may remain private in a set of domains.
  • Revision history: every edit is stored so that there is a revision history and accountability of every change made to the collaborative document.
• The document model itself is pretty general and allows many views (and consequently many google wave “applications”) to be built with the existing framework of de-centralized real-time collaboration.

So its basically a decentralized, real-time wiki with a flexible document model ready for making applications and guess what, email are chat are the most basic things that can be built starting from that.

Comparison with file syncing services

You may also compare this to Live Mesh where the basic idea really was some collaboratively edited cloud storage with edit notifications available as an activity feed for applications to tap in. In fact, when I played with various file syncing services, such as Live Mesh and dropbox, the limitation which stood out most was the inability of applications to manage conflicting changes. Changing the underlying document model from essentially a large chunk of bytes to hierarchically organized, change history retaining document model is just what applications need. Of course the applications need to be redesigned (separation of the actual document and the changes made to it) but that may be a necessary step to achieve what Live Mesh set out to do in the first place. Of course, I am not sure if Live Mesh was supposed to be either decentralized or real-time.

Note that even though the implementation of google wave demoed at Google I/O was an HTML 5 application, there is nothing stopping a normal desktop application like Microsoft Office to adopt a similar document model.

Comparison with Social Networks

Does existence of google wave necessarily obsolete social networking sites like facebook (i.e. sites that provide the social network infrastructure and not the specialized social networking applications such as dopplr, last.fm, digg)? I think they still have a place because social network communication over facebook is very public and that public meme is a value that facebook provides in addition to a collaborative infrastructure. However, I am pretty sure there will be somebody out there who will take google wave’s reference implementation and just add enough “public” mantra to it to make a competitive social networking platform.

This is of course great news for social networking applications such as last.fm, dopplr and digg who can now use google wave for their social networking infrastructure.

Will it be robust and glitch-free?

Managing concurrent real-time editing of a document originating in pieces from several domains is of course not going to be glitch-free . However, there is quite some stuff to be learnt from decentralized source code management (tools like git and mercurial). These guys have been dealing with decentralized conflict management and revision history since quite some time now. I guess the following additions to the wave implementation will make it more robust than just keeping content (wavelets) in authoritative domains.

• A wave domain should cache the entire wave aggressively (at least the parts it has access to).
• The document model should be built such that it is incrementally consistent i.e. if a set of changes from a domain or a user is removed then the document isn’t corrupted.
• Each incremental edit should be checksummed for integrity against the entire history of edits previous to this edit. This ensures that edits originating in different domains agree on consistency of their edits. This also requires that we revoke edits that happen over an older revision (the whole “rebase-ing” concept in git applies here… and should be possible to do automatically if changes are synced sufficiently in real-time).

Wave without the cloud?

I am sure we will all be happy to see Google or somebody else provide free and nearly unlimited storage for wave documents. Like gmail, it should be easy to monetize for the cloud expenses using ads. However, I was thinking, if it was possible to build it using p2p techniques alone. Given git like consistency and aggressive caching, it may not be a bad idea to let the client be authoritative on its wave documents but be offline too. It also achieves storage redundancy automatically so one may be able to just start a fresh client and sync up its waves from its peers if it has the appropriate signing key. Git itself may not be suitable for building this as git doesn’t provide a standard incremental consistency model (I am thinking basic DTD document type check). However, it should be fairly easy to adapt the core git storage with such a type check, handling wavelets from different authentication domains and wrap it in a real-time network layer to make such a client.

The bigger problem really is maintaining connections to a large number of peers in the network. However, NAT traversal schemes should help.

Many-core task parallelism: low overhead task switching

With the upcoming multi/many-core processors, there is an industry wide push towards programming for task-parallelism. Without it, programs aren’t getting any faster. There are high level programming constructs such as OpenMP and ConcRT which can be used at the programming language level to exploit task parallelism. However, one often forgets that every task runs within a context (usually a thread context) and switching between contexts (for synchronization or fair scheduling) is costly. It is generally recommended that one should try to expose as much parallelism in their programs as possible and let a runtime schedule them on the cores that are available on the system. Of course, with that comes context switching cost till there comes a time where dividing up work into finer parallel chunks leads to poor performance due to a large amount of context switch overhead.

At the hardware level, task parallelism allows the processor to schedule instructions from multiple streams together on its functional units. It can do so because the individual tasks are supposed to be independent instruction streams. However, with it also lies the caveat, these streams often contain a large amount of state which the hardware manages independently and which the system software has to save/restore on task switch. While very fine grained task parallelism seems like an elegant goal to achieve with software in general, after a level of parallelism granularity, task switch overheads can spoil the entire show. [A task switch in (system) software involves saving and restoring the entire register state including vector registers which can be a large amount of task state].

Fortunately, there has been some work (in computer architecture) to deal with this problem. One of the nicest examples I found was the Tera Computer system. Its architecture is detailed in this paper [PDF]. There are two notable features of the Tera Computer (later the Cray MTA) which enabled low overhead task switching:

1. A large number of hardware thread contexts. The Tera Computer processors had 21 stage pipelines. However, a single processor could store the context of 128 threads in total. Thus, it was very effective at hiding instruction and memory latencies.
2. The Tera Computer supported hardware based thread synchronization primitives. You could make a (hardware) thread wait on the state of a memory word which you could update from another thread, thus “waking” up this thread. There was no need for system software to do any context save/restore as the thread context was always present in hardware.

However, the above technique seems to have a limitation. If my program has more than 128 hardware contexts then I need to resort to context save/restore. If my program has fewer than 128 hardware contexts (but enough to keep the 21 stage pipeline busy) I am wasting hardware resources (register storage).

I thought about this for a while and it occurred to me that register based architectures are perhaps not suitable for MIMD (task-parallel) processors. I know this is a bold claim but I feel that may be resorting to a memory operand based architectures (where an instruction’s operands are memory addresses) may eliminate context switch overhead all together. Note that the working set of a hardware thread is probably cached on the processor L1 cache and is available as fast as register storage itself*. However, having 3 64bit memory addresses in every instruction doesn’t seem like a good idea. It increases program size and takes up valuable instruction memory bandwidth. What I propose instead is to do something similar to the register stack engine in Itanium or register windows in SPARC. However, instead of using bona-fide registers, the instruction operands are offsets from a per-thread stack pointer. Using offsets allows register like compressed instruction encoding while at the same time not deviating from the memory operand instruction model. The only context that the software needs to save on a task switch is the stack pointer which is okay as its just a single register. Thus task switching simply involves saving/restoring the stack pointer and resuming execution by popping the return address off the stack. With this CPU architecture, its possible to do lightweight context switching without any assistance from hardware (like the Tera Computer).

But who am I kidding… I am going to see only x64 and ARM for the rest of my life :/.

Update: When I was discussing this with a colleague, an interesting question came up: How do we integrate thread wake-up from software and hardware events with the above scheme? At first I thought just having a trap for the hardware events would be okay… however hardware events may require a much lower service latency and special processing than software events to get good performance (eg. wake-up after L1 cache miss). So I finally thought of the following: the architecture keeps separate lists of ready-to-run contexts (stack pointers) for hardware and software events and service the hardware ones preferentially. While notifications for wake-up of software events could be done in software, the hardware would need to take care of hardware wake-up events and wake-up (and resume the halted instruction) in the corresponding threads. Thus, it is also important to keep this list in pinned L1 cache. There also needs to be a way for the hardware to let the software know when a previously hardware interrupted thread is ready-to-run… a trap could work here as long as we guarantee that it won’t cause any further trap invocations. Another simpler and more performant mechanism could be to just pre-empt the current running thread with the hardware woken one and maintain a stack of contexts to switch back to the pre-empted ones once the current one arrives at a hardware / software synchronization point.

One may also think of using low overhead task parallelism to cleanly emulate cache hierarchies, cache coherency and many other kinds of system specific processor facilities (reminds me of the PALcode in DEC Alpha).

* The fact that the Itanium architects went with a backing store for their register stack (and not direct memory operands) makes me a little skeptical that my idea can be implemented in a performant way on real hardware. However, given a large number of switchable contexts, an occasional event of high latency to L1 shouldn’t be a real problem.

Well written article about the current financial crisis by IMF chief economic officer Simon Johnson

This article in The Atlantic discusses the current financial crisis very well. The article criticizes the

• blind faith people and the goverment have in the financial system and the de-regulatory legislation which happened in the US during the Bush administration.
• the impact of leverage in a financial system, how a small amount of speculative investment can be grown systematically into a much larger investment.
• the dismal handling of the stimulus package and continuation of the oligarchy of banks by virtue of which they still have a lot of control in the stimulus.

The article also compares the crisis to past economic crises in emerging markets. Quite a few points are noteworthy – for eg. high economic growth, corruption in governance and influence of corporations in legislation, lack of oversight in markets and unstable currency. Reminds me eerily about India.

Its depressing how collusion of even large tech companies gives rise to immediate anti-trust investigation whereas massive collusion in wall street gets rewarded with millions of dollars in bonuses. Chose the wrong industry, didn’t I?

Gmail and Thunderbird (Conversations + Threading)

Man! What a long and frustrating journey… here is how it started.

I am subscribed to a programming discussion mailing list at UNC Chapel Hill which can get very bursty at times. The problem is that its very hard to find out the relationship between posts in Gmail’s conversation view. I really like message threading in such cases as it helps me follow subtopics etc. I don’t mind having a separate message viewing pane for message viewing.

So I searched ( a lot! ) for a webmail or otherwise mail client which would help me see the message threading but let me keep my email in gmail. The only thing that looked half decent was zoho’s email ( this page shows the kind of UI zoho mail provides). However, the main mail view is still list based and you have to select a mail and opt to view it separately in a conversation + threading style. I wish they had provided threading as an option in the main mail view.

After a futile search for a webmail app (I preferred webmail so that I can store all my preferences/settings at one place) I bit the bullet and downloaded thunderbird 2. Thunderbird does provide a threading view ( I like keeping a 3 pane vertical view with a threaded list of messages in the middle pane). Below is a collection of tips and tricks (some collected from other sources) to get to my conversations + threading setup. Thunderbird IMAP setup for Gmail is officially detailed here.

• Gmail IMAP behavior: Gmail labels show as folders in IMAP. So the actual behavior in IMAP causes a corresponding non-conventional behavior in Gmail. This diagram shows it all
  

  Gmail IMAP behavior

• Gmail Conversations: The good thing about gmail conversations is that it shows related incoming and outgoing messages together. By default, Thunderbird threading (say in Inbox) will only show you incoming messages. Thunderbird doesn’t allow you to merge the Inbox and Sent Mail folders in a view (search folders through which you may be able to create a view don’t support threaded display… ). So I resorted to the following hack. I copy sent mails to Inbox instead of a Sent mail folder ( Google recommends not to do anything for sent items as it automatically stores and tags sent messages with “Sent Mail” ). This basically just adds the Inbox tag to all my sent mail. Now, I can just thread the Inbox view to see all related messages together with threading.
• Drafts and Templates: I set the Draft and Templates folders ( Thunderbird account settings ) to the Gmail Drafts folder.
• Gmail Trash folder with Thunderbird: Thunderbird doesn’t allow me to change its trash folder from the UI. The default Trash folder causes an [Imap]/Trash label to be created. The work around ( courtesy lifehacker’s guide to Gmail + Thunderbird ) is to add a mail.server.server<x>.trash_folder_name = [Gmail]/Trash config string through the config editor ( Tools -> Options -> Advanced -> Config Editor ). After that, I removed the [Imap]/Trash label using Gmail’s web interface.
  I also set the “When I delete a message:” to “Remove it immediately” in my Tools -> Account Settings -> Server Settings. I didn’t want my messages I archived ( by deleting from Inbox ) to be moved to Trash.

I hope this helps others with their own Thunderbird + Gmail configurations.

Threading is not the only reason why I shifted to Thunderbird. Gmail’s webmail interface is heavy on compute and memory resources. Thunderbird consumes < 20MB to show me the threaded conversations view of my inbox (~25 messages). However, this quickly climbs up to 100+MB if I try viewing a large folder such as [Gmail]/All Mail. I do that only when I am searching for something.

I also integrated Google calendar into thunderbird by installing the Lightning and Google Calendar provider addons.

IPv6 costs and incentives

The following video is an excerpt of a Google hosted discussion of the state of IPv6 on the Internet. I don’t recommend you see it even though the discussion is orchestrated by none other than Vint Cerf himself. 

http://www.youtube.com/watch?v=mZo69JQoLb8

For something like IPv6 which is supposed to be “the future of the Internet” there seems to be a lot of religion out there. Let me try to summarize what I thought were the main reasons to go with IPv6.

 

• A Cisco representative in the panel suggested that ISPs were willing to add more customers to their network than allowed by their IPv4 address space budget. According to some other comments, the real battle is between the cost of acquiring more IPv4 addresses and the cost of IPv6 deployment. The way I see it… its an opportunity for Cisco to make money out of address scarcity. There seemed to be a difference in opinion between the Juniper representative and the Cisco representative about whether the current routers can handle IPv6 traffic. The Juniper representative in the panel said that recent routers should be fine… the Cisco representative thought that a complete network assessment was needed before such a decision could be made. This re-emphasizes my point about Cisco trying to make money out of this whole IPv4 -> IPv6 ordeal.
• The other point seemed “religious” for the lack of a better word. It was about end-to-end connectivity on the Internet. The IPv4 network currently has a lot of its edge clients behind NATs. Some speakers really thought that this was “bad” without giving any particular reasons. They stated that opening up home devices to the outside Internet would bring in “a lot of innovation”. The only thing I draw from this (which is the reason I posted this article in the first place) is that IPv6 opens up an opportunity for Google to crawl through the data behind NAT devices and promote the Free Culture without going through massive infrastructure investment like Youtube.com. What really bothers me is that nobody brought this point out as clearly as the security point. End-to-end connectivity is not just manifests a security stance but also a political stance and benefits companies which thrive on user-generated / free content.

 

Of course a number of people in the audience pointed out the difficulty of getting on IPv6 in the first place. Besides the address expansion, most of the benefits of IPv6 have been back-ported to IPv4 already. The chicken and egg problem was often sited:

 

• ISPs don’t want to transition to IPv6 because having no network destinations on IPv6 doesn’t justify putting in the infrastructure cost.
• Content sites don’t want to transition to IPv6 and incur infrastructure costs unless there is enough of an audience which is IPv6 only.

 

The funny point here is that (if we are to believe that network ISPs and content sites are close collaborators… which I think is true for cable Internet) then they have business incentive to keep the Internet in the content creator vs. consumer divide for as long as possible. It may not be a bad idea for the content sites to subsidize the IPv4 address scarcity to keep Google and entertainment startups further away from making available even more user generated content without investing heavily into infrastructure.

I understand that it may be impolite to directly discuss conflicting business interests publicly in a conference hall like setting. However, religion is hardly a substitute. From a consumer standpoint I don’t want to see my Internet bill go up by $5 or $10 for the IPv6 transition only to help some companies make more money. There should really be choice and transition costs must be paid only by the true beneficiaries of the IPv4 to IPv6 transition. Network connectivity at reasonable costs is more important than “elegant” design decisions in a practical network such as the Internet. May be the entire focus of the next generation IP should have been just laying out a killer transition strategy for expanding the address range. IPv4 is enough of a testimonial on how protocol specs can be improved upon incrementally without breaking the network or requiring the administrative overhead of a dual-stack.

Network Neutrality and flow rate fairness

If knowing my stance on Network Neutrality is really important to you before you read further along, I would like to state that I am against Network Neutrality, I think US broadband can do much better and I blame the government for the situation we are in. I don’t think Network Neutrality will help get rid of any of our broadband problems.

The Internet has been a major force in shaping the economies and culture of the world around. So much that its no more seen as a luxury but an essential medium of communication. Given its importance, its not a surprise that Network Neutrality legislation is being pushed (or at-least has been a subject of debate). Very briefly, the aim of Network Neutrality is to avoid any kind of discrimination between application traffic on a network. Any application provider on the Internet should be treated the same way as another. While such is the aim, the way Network Neutrality legislation seems to be moving forward is to regulate ISPs in a similar manner as Telecoms. ISPs will need to honor “fairness” between applications and will have to adhere to standard basic protocols for managing traffic on the Internet.

Note that the definition of Network Neutrality are as numerous as the proposals for solving it and a fairly good amount of information can be found on the Wikipedia page linked above. Basically, I see the following two opposing forces:

For Network Neutrality: The telecoms and cable companies have a virtual monopoly on the cables they have laid on our land and have been granted huge subsidies by the government to ameliorate the initial investment into basic networking infrastructure. We think that treating Internet applications “fairly” is important to our economy and hence we have the right to claim that from them.

Against Network Neutrality: The problems in Internet technology are far from being solved. There are widespread issues with security on the Internet. There is little incentive for the broadband companies to give us more security or bandwidth — escalating costs of bandwidth will retard the adoption of High Definition media. Unless we give the ISPs more control over their traffic, they claim that they can’t even solve fundamental fairness issues between applications going through a heavily loaded network leave alone other problems with Internet technology.

Before we move on, let me ask you a quick question. What do you think is the protocol that runs on Internet Links? Your first guess may be IP, which is the protocol which everybody on the Internet has to use to communicate. However, that’s not quite true. When packets move over links, its generally wrapped in a Link Layer Protocol. There are many technologies used below IP they will continue to evolve as technology improves with time. Its important, however, to note the resilience of IP which can run on such a variety of technologies with very small number of changes. These days, IP runs over Ethernet, Fiber Ethernet, SONET and Wireless (WiFi, 3G etc). A large number of “management” protocols run between the Link Layer and IP for performing other functions. In many instances, these protocols are not seen separately from Link Layer — in other cases they are. A good example here is MPLS which is traffic management protocol layer used heavily in ISPs. The evolution of technology below the IP layer is very important to sustain the growth of the Internet. Then there are other protocols or protocol extensions to IP which help in bringing more applications on the Internet or make their deployment cheaper. The reason why the Internet works round the clock is because of massive investment in innovating and standardizing infrastructure protocols. A lot of this is driven by the academia and the industry working together. IETF is an important body which helps in this co-ordination.

My basic point it that we are not helping with the evolution of the Internet if we don’t create the right incentives for people to work on these. We can’t just leave the academic community provide us solutions for mounting challenges in Internet technology. In most cases, academia is least interested in costs of operation and ISP business model opportunities on the Internet. It is very uncertain where the drive for this evolution will come from if we regulate the Internet. The bet is between a public body in-charge of Internet technologies or market forces shaping its evolution. I (subjectively) favor market forces in this case.

The recent ruckus over P2P and fair bandwidth usage illustrates the above point very clearly. The academic community has for a long time considered their solution to “fair” bandwidth allocation between applications sufficient for the purposes of the Internet. Very recently, it has been shown that such a model may not be actually good for a practical Internet. The paper “Flow Rate Fairness: Dismantling a Religion” brings out this point very clearly. It shows how the current TCP/IP way of doing networking has very skewed way of looking at fairness. Fairness is also a highly debated topic in the networking community and it definitely seems to be enough complicated for businesses do discard it all together for their operational purposes. It seems that the Industry lagged behind a bit in reminding the IETF of the problems it would begin to face if they continued with the currently prevalent fairness model.

This brings me to the other point:
If we force Network Neutrality on the ISPs then besides not having an incentive to contribute to the evolution of Internet technologies, they will be forced in a way of doing traffic (the current TCP/IP) which is far from the optimal way of operating on a network. We will leave them with a technology mess to deal with under restrictions that they cannot change it. This will cause application makers to work around it for their own good. ISPs will have little power to do anything against that once they operate under regulation. In a sense, the problem of ISPs discriminating between applications will move to some applications discriminating against others. Currently, bittorrent unfairly gets more than its share of resources from other applications by exploiting the fairness system in TCP/IP. The battle will move upward in the application layer and every application maker will want to use bittorrent like features. What’s worse is that some applications (VoIP) will suffer very badly from applications like bittorrent and they will have no way to survive in a regulated ISP world. The only way out is more regulations on applications and application behavior on the Internet… and given that, you can kiss good bye to any new applications coming on the Internet in the same way you kissed good bye to making the Internet efficient in moving data around once you regulated the ISPs.

I think that at the core, there are two problems we need to tackle:

1. If the Internet is so important for us then the government should own its basic infrastructure. It should provide via leases and contracts for any upgrades to services on it and should monitor its health. It should be able to terminate a business’ hold on the property if it feels that its not doing its job properly in maintaining it and providing services on it. In other words, it should be more like US roads or other public amenities. I really think that no government in its sane mind should give its entire property to one company to manage. That would make that company too powerful and destroy the balance in this scheme. Local areas should be able to choose their own businesses to run their own networks. If the public feels that a basic set of services on the entire network is important for the economy as a whole then the government should obtain a license for the technology and release it over the network using contractual services from businesses willing to do the work. The revenue for these businesses could come from the government and/or the consumers. The academia can also contribute technologies.
2. We should leave it to businesses and market forces to come up with a definition of “fair” using actual costs. As any business is free to run whatever it wants over the network (provided it pays for the resources) how it actually manages its costs while providing the service should be left to the business alone. If prioritized VoIP traffic is under high demand then the supply demand curve can appropriately fix an optimum price for the cost of prioritized traffic on the network. We should definitely not regulate traffic priority or regulate companies which are willing to provide us a way to do it in a better way. Note that its the job of the government to make sure that there are no monopolies in this schemes, which should be easy given the ownership of the physical infrastructure. Again, if there is public interest in a particular notion of “fair”, then the public (the government) should pay to nudge the market to a different demand supply point. Note that I am more hopeful about an evolving notion of actual operational cost on the Internet than a (contrived) notion of fairness.

I hope that I have been able to at-least convince you that the problem is not about “fair” Internet access but is more about who owns and encourages development on it.

Patch based inheritance: The revenge of the dynamic and unorganized

Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn’t.

Quite similar is the story of programming and programming languages. For the past many years now the landscape of programming languages has been the following:

Fiction (or what people predicted would be the next generation): Program Verification, Static typing and type checking in “enterprise” level code and Statically typed Object Oriented language design.

Truth (or what has come to be the reality now): Runtime type safety, No static type checking in the program, dynamic and less verbose programming languages, “enterprises” which move quickly to these languages seem to gain huge productivity from programmers.

The advent of scripting languages into the mainstream has proven beyond doubt the world of programmers would favor “no types” than “better types”. In most cases, type systems generally come in the way of programming than assisting it — especially in environments geared towards rapid prototyping.

I kind of feel the same about OO programming too. Especially the inheritance aspect of it. This is beyond static type checking. I feel constrained when I am asked to extend the functionality of a class by just overriding its methods. Sometimes I would really like to change the behavior of a method very slightly… not exactly accomplished by overriding (and mostly rewriting it). In some cases it can be achieved by dividing the original method into smaller parts and overriding one of them… but by then the interfaces are laid out and the damage has already been done. In other cases, even this approach fails.

Many OO advocates pride themselves in carving out the correct set of interfaces such that the problem above really never occurs in practice. While I surely don’t doubt their skills, I still think that a very large fraction of programmers (may be close to all) have come across instances when even after carefully laying down interfaces, future evolution of the software didn’t exactly follow.

So here’s a somewhat radical idea. What if we forget inheritance the way we know it? Lets assume that we are operating in a dynamic OO language. The inheritance is based on the concept of a patch (just a regular diff between similar lines of code). To derive from a parent class you copy the source, change it according to your needs, rename the class adding a dependence declaration pointing to the parent and take a diff of the body of the derived class with respect to its parent as its source code. Upon compilation, the compiler uses the parent’s source code to dynamically generate the derived class’ source code and then compiles it.

This approach does come with advantages which I will argue are beyond traditional inheritance. The derived class now has the potential of changing the behavior of the parent in any way it feels. The process of derivation from another class is now truly “dynamic” (in the sense of — left to the programmer, the language and the compiler get out of the way). This advantage IMHO is a huge win. It is not necessarily more fragile than normal class inheritance. In both cases changing the parent class in some way may or may not conflict with the derived class. The compilation itself becomes simpler because implementing this is almost as simple as applying patches. The patch application test serves as a sanity check similar to the checks with inheritance (non conflicting member variables, etc).

Another advantage of this approach is that we have now really made inheritance and polymorphism orthogonal to each other. Previously, the derived class included the parent class’ signature in it. It contained all its methods and member variables and the public ones would be accessible. Thus, even though inheritance could allow you to re-use a class and completely change its behavior, the fact that the parent’s methods are still accessible made that logically inconsistent. Think of a Queue class which supports enqueue and dequeue at both the head and the tail. Its perfectly fine to derive a Stack class from it which just has push/pop. Its implementation involves using the Queue’s enqueue and dequeue at either the head or the tail for the push/pop operations but very importantly, also changing its interface to push/pop! This is not possible with traditional inheritance but is possible with patch based inheritance.

I hope I have atleast convinced you that prevalent OO programming is not exactly a good way to program.

reCAPTCHA… Stop Spam, Read (digital) books

Thanks for the tip, Diwaker!

A lot of sites use images which cannot be “read” by computers as a means to stop spam. Generally a human types in the word displayed in the image and goes through. The reCAPTCHA project aims at giving you such images for use and in turn uses the typed in results by people to digitally covert books!

http://recaptcha.net/learnmore.html

Google Sorry Page…

This is interesting. Google thinks that I am a bot . I am getting the following page no matter what I search…

Gmail and igoogle seem to be working fine… however, the search through igoogle’s page is failing too.

Political Compass Test

On appu’s recommendation I took the political compass test too. Here is where I stand:

Economic Left/Right: -1.38
Social Libertarian/Authoritarian: -3.59

I too found the test to be fairly comprehensive… however there were still a few questions which I either didn’t get or genuinely had an “it depends” answer. However, still a lot better than the majority of the polls I have seen.

Also, I thought I was more right than left… may be my definition of right is too different from what these guys think as right.