Friday, September 14, 2007

Dangerous Knowledge

http://video.google.com/videoplay?docid=-3503877302082311448

"In this one-off documentary, David Malone looks at four brilliant mathematicians - Georg Cantor, Ludwig Boltzmann, Kurt Gödel and Alan Turing - whose genius has profoundly affected us, but which tragically drove them insane and eventually led to them all committing suicide.

The film begins with Georg Cantor, the great mathematician whose work proved to be the foundation for much of the 20th-century mathematics. He believed he was God's messenger and was eventually driven insane trying to prove his theories of infinity. Ludwig Boltzmann's struggle to prove the existence of atoms and probability eventually drove him to suicide. Kurt Gödel, the introverted confidant of Einstein, proved that there would always be problems which were outside human logic. His life ended in a sanatorium where he starved himself to death.

Finally, Alan Turing, the great Bletchley Park code breaker, father of computer science and homosexual, died trying to prove that some things are fundamentally unprovable.

The film also talks to the latest in the line of thinkers who have continued to pursue the question of whether there are things that mathematics and the human mind cannot know. They include Greg Chaitin, mathematician at the IBM TJ Watson Research Center, New York, and Roger Penrose.

Dangerous Knowledge tackles some of the profound questions about the true nature of reality that mathematical thinkers are still trying to answer today."

Thursday, September 13, 2007

The imperative vs functional decision in Scala

When programming in Scala, one needs to think about whether to use an imperative or functional approach (or some hybrid thereof) when writing most methods. Thinking about which approach to use so frequently could result in a significant waste of time.

One thing that makes OO development easier is the use of automated refactorings for evolving a class hierarchy. So getting things right at the start is not so important because you can easily change things later.

To address the imperative vs functional decision that one encounters in most Scala methods, one can similarly have automated refactorings for transforming code fragments from one paradigm to the other. In this way, you don't need to worry much about getting this decision right because it is easy to change it later.

Moreover, for those not so familiar with functional programming, such refactorings can provide guidance by helping them transform imperative code to functional code.

Wednesday, September 12, 2007

How Google could beat Facebook at its own game

Google could obtain a social network graph quickly from gmail accounts.

Moreover, it could release a platform similar to Facebook based on GWT but take it another step further by providing free hosting on its massive computer cluster.

There would be some sort of revenue sharing system in place for apps created using this platform.

Instead of hiring so many software engineers worldwide, Google could "outsource" much of their app development to entrepreneurs.

Although Google already acquires a few startups here and there, one would expect thousands of apps to be developed quickly in what I described above.

Thursday, August 9, 2007

Why social networks use bidirectional links even though unidirectional links are probably better

I think the main reason is simply to get people to invite their friends to the site, thus increasing the number of users via peer pressure.

For specialty social networks (or specialties within a general social networking site), your friends are probably not the best people to connect to. In that case, it would probably be better to use unidirectional links so that you can "subscribe" to anyone whom you would like to learn from.

Yet these unidirectional links -- while better suited in such cases -- are not great in attracting people to the site. And so such sites probably won't get enough critical mass to be interesting.

Instead of friend requests and acceptances, users should just be able to subscribe to other people via unidirectional links.

Such unidirectional links don't designate friendship at all, but rather, interest in keeping in touch with someone's activities (e.g., their subscriptions to discussion groups, the apps they add to their profile, etc.).

You could use some sort of reward to encourage people to invite their friends that has nothing to do with these links.

For example, wherever people are listed throughout the site, you could rank them based on the number of friends that they have invited to the site.

Sunday, August 5, 2007

Why not let online ads fight it out in a geometric real-time game played by advertisers and consumers?

In this approach, the advertiser would display his/her ad along with all the other ads currently on display.

Larger ads have the disadvantage that they will overlap with other ads and may end up being underneath many of them.

Advertisers may resize and/or move their ads at any time to reduce overlap.

Whenever two ads overlap, they will then have to fight it out to see which one will go on top. This fight is on-going and may involve one ad appearing on top, later underneath, then on top again, and so on.

To determine which of two overlapping ads goes on top, we would compare their current scores, where the score of an ad could be the number of visits minus the number of "hide" requests from consumers say.

One can view this approach as a geometric version of social news.

For a non-geometric version of this idea, we could have something like reddit but where the submitter determines and can change the rank of his/her link on the front page.

The issue is that a link ranked highly will have to share that rank with many links. We can have the probability that a user will see a link at rank k depend on the score of that link with respect to the scores of other links with rank k.

Monday, July 30, 2007

Why it is in Microsoft's self-interest to have an OS that is susceptible to viruses

If you are a commercial software developer, you would like an operating system where security risks (e.g., viruses) discourage users from pirating your software.

Yes, there's a limit to what users will tolerate. A system that is too insecure would not work. But the virus threat needs to be real to discourage piracy.

Ultimately, users do care about an OS with lots of software available. Many users will put up with some security threats to get that.

Saturday, July 28, 2007

Making random people famous

Consider a service that crawls the web for home pages and then displays one chosen at random each day for all to see and discuss.

It would be sort of like this Facebook app:

http://apps.facebook.com/fifteen/

The difference though is that people would not sign up requesting they be made famous. Rather, the service would do it without their permission.