Jonathan Branam

Alan Kay: The Computer Revolution Hasn't Happened Yet, OOPSLA 1997

Thu, 11 Mar 2010 21:59:54 +0800

Alan Kay: The Computer Revolution Hasn't Happened Yet, OOPSLA 1997

" So here’s a great book. How many people have read this book? When they wrote this book, I..."

Thu, 11 Mar 2010 21:01:00 +0800

“

So here’s a great book. How many people have read this book? When they wrote this book, I called them up and I said, This is the best book anybody has written in ten years, but why the hell did you write it in such a LISP centric, closed club centric way?

This is a hard book for most people to read. If you don’t know the LISP culture, it’s very hard to read. If you don’t know how CLOS [the Common Lisp Object System] is done, it’s a very hard book to read, but this book has some of the most profound insights about, and the most practical insights about OOP, than anybody has done in the last many years.

I really commend it to you. If there are any university professors here who would like to get the next [unintelligible] balloon, I will give it to anybody who rewrites that book so that the general object-oriented community can understand it. It would be a great service to mankind.

”

- Alan Kay

(quoted http://blog.moryton.net/2007/12/computer-revolution-hasnt-happened-yet.html)

"Things like JavaBeans and CORBA are not gonna suffice, because at some point one is gonna have to..."

Thu, 11 Mar 2010 19:59:52 +0800

“Things like JavaBeans and CORBA are not gonna suffice, because at some point one is gonna have to start really discovering what objects think they can do. This is going to lead to a universal interface language, which is not a programming language per se. It’s more like a prototyping language that allows an interchange of deep information about what objects think they can do. It allows objects to make experiments with other objects in a safe way to see how they respond to various messages. This is going to be a critical thing to automate in the next ten years.”

- Alan Kay

Growing an application

Thu, 11 Mar 2010 13:20:00 +0800

Shouldn’t our programming be experimental in a fundamentally new way similar to a CLI and unit tests? What was wrong with the Smalltalk model, or was it just ahead of it’s time?we need to be able to tinker and grow systems. Think about how 37signals (any SaaS app) grows itself slowly and incrementally. Think about how the Internet, with it’s basic routing mechanisms, continues to run despite cut cables and temporary outages. Think of the cellular growth of an application built in Erlang and running across EC2 instances.

We need to grow our systems rather than author them. Unstead of conceiving of the whole and builiding it out, we should build a little bit, test and grow. Build a test platform as we build our systems. Talk to our systems, reroute messages temporarily while we patch one part. Have duplicate systems running side-by-side. Think of the article on developing Twitter. It requires high scalability and solidity, but you must still make changes and test new features. Rollout can be staged and incremental. Nothing should ever fail but simply reroute.

Single responsibility principle

Thu, 11 Mar 2010 10:33:00 +0800

It’s good to have only one thing for a local method to do but when that method is remote, this is a recipe for terrible performance.

There needs to be a middle ground so that the remote caller has options. Essentially what a UI needs is the ability to execute a custom workflow on the server. The workflow will call several methods with a single responsibility and branch appropriately based on the responses. A method chain is not enough.

The loss of locality in this is a huge performance drain as well as creating complicated client code when the requests are asynchronous.

What we (didn't) learn from CORBA

Thu, 11 Mar 2010 01:24:00 +0800

CORBA was designed to solve interoperability problems between computer systems and to abstract away the concept of service location. The particular service might be local or it might be remote.

Today, CORBA is dead and long live Web Services which have fixed all of CORBAs problems, right?

Wrong.

The only change that web services offer is plaintext versus binary. The binary nature of CORBA certainly made message errors hard to debug since a human can’t easily inspect them, but that wasn’t the real failure of CORBA.

CORBA failed because it matters whether your service is remote or local. The principles we use to build local services do not all apply to remote services because they are remote.

In particular, the granularity of service calls must be much larger for remote services or performance will become a huge bottleneck.