Hacker News new | past | comments | ask | show | jobs | submit login
Was Alan Kay wrong? And why does that matter? (braythwayt.com)
31 points by raganwald on Dec 22, 2013 | hide | past | favorite | 30 comments



I wrote the tweet that likely triggered this post.

My original joke on Twitter was that I was waiting for Alan Kay to tell everybody how Smalltalk did reactive programming and FRP first.

My original point is Alan Kay has made a hobby of co-opting virtually any paradigmatic trend or fad that has arisen since his original work on Smalltalk, usually claiming Smalltalk did it first/better/whatever.

The point here isn't original sin or only creating objectively perfect things. It's a different problem of people who don't seem otherwise engaged with the work being done in the present only talking about the work they did in the past.

Call for information: is anybody aware of Alan Kay directly contributing to the development of any open source programming languages that aren't Smalltalk in recent history?

I'm not aware of him releasing any new languages or publishing any new papers in the last decade or two, yet his paradigmatic peanut gallery commentary seems to spread pretty quickly.

I haven't seen anybody actually say what raganwald is attacking here.


I guess you haven't been following the many cool papers and projects coming out his VPRI group and the STEPS project, and while Alan Kay is known to enhance the history a bit he's been pretty darn consistent all throughout his career about giving credit where credit is due.

So you must be thinking about some other Alan Kay we don't know about :)


My original point is Alan Kay has made a hobby of co-opting virtually any paradigmatic trend or fad that has arisen since his original work on Smalltalk, usually claiming Smalltalk did it first/better/whatever.

Lisp was co-opting everything long before Smalltalk started co-opting everything.

But on to the main point: what am I attacking here? Nothing, in fact, I think the post is praising the idea that discussing his quote is a useful exercise, leading to fertile grounds.

Whether OOP is or isn't what he says it is, or whether greenspunning a feature is somehow less useful than choosing a language with that feature built in is an exercise I leave to the reader with little comment other than the observation that while i no longer program in Java, I haven't gone so far as to adopt Clojure or Squeak.


Lisp was no co-opting everything. But research around Lisp did explore much of the dynamic and high-level language space, because it started early and had a lot of funding from the AI application domain - up to the end of the 80s. At the same time Smalltalk, Prolog, Self and other language spawned a lot of research. But only Lisp had this breadth and variety of research in this space. Today some languages are still catching up (say, generational GC in Ruby came only recently) or are ahead (JVM with concurrent GC, Mathematica's IDE, ...).


Why is that picture of Einstein's desk just after he died there? There are various ways you could work Einstein's somewhat isolated position in 1950s theoretical physics into your narrative. Just wondering if it was a random image or carried some weight in the argument?


I added it afterwards as an inside joke about arguing what Dr. Kay did or didn't mean decades later. Dr. Kay is still alive and doing good work of a different nature, but the gap between computer science theory and industry practice is as wide as it ever was.


Greenspunning is not really about languages implementing missing features.

Greenspunning really is about the experience of implementing larger APPLICATIONS in Fortran or C, many years ago. For example a CAD system typically would need things like code loading, redefinition of code, exception handling, runtime execution of code (in a CAD scripting language), objects, more advanced memory management, ... Another example: something like Word or Excel - they also need these features.

Both Java or Javascript have parts of this already implemented in their runtime. But they don't implement the runtime themselves. Those are written in C or C++.


No it isn't about languages implementing missing features, but we still have this experience of reinventing Lisp when writing applications in today's languages. We may not need to re-invent memory management, but I notice that the Rails framework reinvents part of CLOS with its object lifecycle method handling, and Node reinvents continuation-passing style.


I use Clojure and Haskell, I live in the future above and beyond what traditional Lisps have ever offered.

I just find the aggrandizement of those-that-came-before obnoxious and unfair to people doing work here and now.


The flip side is that people have been reinventing Lisp Machines and Smalltalk environments, poorly, for the last two decades, and many would argue we still aren't at feature-parity with them. It's obnoxious to see people take credit for ideas that predate them and pretend we're innovating.


I'm pretty happy with Clojure as a next-generation Lisp.


Then you have some work to do...


cute.


Did you have anything useful to contribute here?

I'm fine with Clojure because I'm more interested in languages with type systems anyway.


What aggrandizement is this? Or is the very idea of quoting Mr. Kay odious to you?

I think this is a simple case of you having an axe to grind, and my post being a rough surface.


>I think this is a simple case of you having an axe to grind, and my post being a rough surface.

Probably so.


Kay is founder of a publicly funded institute that has published numerous papers and released a number of new languages in the past decade or two:

http://www.vpri.org/html/writings.php

http://www.vpri.org/vp_wiki/index.php/Main_Page


I just watched Gilad Bracha talk 'deconstructing functional programming' and it felt like a 'smalltalk did this better since forever'. I can understand the frustration of seeing the world slowly evolving towards idea you were trying to pitch in a void.


That talk was a terrible strawman.


Peruse vpri.org if you want to see what Kay has been up to lately.


Kay and his research team at VPRI have been studying significant reductions in complexity through DSLs and meta-languages [1]. You can get a nice overview of the work from his talk at Qualcomm [2].

[1] http://www.vpri.org/vp_wiki/index.php/Main_Page

[2] http://vimeo.com/82301919


> My original joke on Twitter was that I was waiting for Alan Kay to tell everybody how Smalltalk did reactive programming and FRP first.

I would bet that it did.

Xerox PARC, Atari, Apple, HP, ... - lots of research labs where Alan Kay worked on his vision. Few people did more research on dynamic languages then him. Catching up to his research at PARC and Apple would take you some years.

Currently he is president of 'Viewpoints Research Institute'.

http://vpri.org

The recent writings can be found here:

http://vpri.org/html/writings.php


Reactive Programming[1] (not FRP): Look up ThingLab[2][3]. Done in 1978 on Smalltalk by Alan Borning. Alan Kay typically points to Sutherland's Sketchpad (1963)[4] as inventing objects, computer graphics and constraint programming.

I have to admit I don't understand the hype over FRP. I mean it's great that you can now do reactive programing in FP as well, but it's not like this hasn't been around for ages.

Anyhow, what Alan does is not co-opting, it is pointing out all the great work that has been forgotten and then reinvented, usually badly, in the hope that someone will finally do a better job than what went before. See also Brett Victor's talk "The Future of Programming"[5]. Brett works for Alan now.

Others have pointed out VPRI[6]. Open Source programming languages that came out of there include OMeta (OO pattern matching)[7], Nile (dataflow for graphics)[8], Maru (metacircular S-Expr. eval)[9], KScript (FRP)[10], etc.

In terms of publishing papers: he's 73 for pete's sake. He doesn't have to publish papers, or do anything he doesn't absolutely want to. But in fact he doesn't just rest on his awards (Turing...) or patents or having had a hand in creating just about every aspect of what we now consider computing. He's still going strong.

So yes, there is a peanut gallery. You just may be confused as to who is sitting in it and who is on stage changing the world.

[1] http://en.wikipedia.org/wiki/Reactive_programming

[2] http://en.wikipedia.org/wiki/ThingLab

[3] http://www.cs.washington.edu/research/constraints/videos/thi...

[4] http://www.youtube.com/watch?v=495nCzxM9PI

[5] http://www.youtube.com/watch?v=8pTEmbeENF4

[6] http://www.vpri.org

[7] http://en.wikipedia.org/wiki/OMeta

[8] https://github.com/damelang/nile

[9] http://piumarta.com/software/maru/

[10] http://dl.acm.org/citation.cfm?id=2509590


open croquet, now developed as open cobalt http://www.opencobalt.org/


There might be an interesting point hiding underneath this article, but the badly forced analogy between evaluation of Kay's definition of OOP (which is an abstract concept with no objective external existence) and evaluation of Newton's description of physical laws really gets in the way.

The question of whether Kay is wrong is meaningless. Kay can't be wrong when he says what he means by OOP. You can discuss what language features and programming practices are useful in particular contexts, and you can argue whether Kay's definition of OOP represents a particularly meaningful set of features and approaches. But to discuss whether he was wrong is pointless, and to frame a discussion of OOP in those terms -- and to pretend it has any meaningful analogy to evaluation of how Newton was right, and how he was wrong, in his physical models is pointless. Its an analogy that serves to try to create a false connection and sense of generality, and does more to obscure than illuminate.


NEVER MIND:

I tried rewriting the opening as your comment suggests, and it looks better. Thanks.


I don't think the quote was meant to be taken literally. You are missing the point if you are.

It should be obvious by now that OOP is a programming method that is possible in any programming language, and it is easier in some and harder in others. There is no language that exists where you can't force out non-OOP code, and you can always build your own OOP framework, even in C or assembly.

A more productive use of the quote would be to compare the design of small talk and lisp vs say java and c++, and think about why someone as brilliant as Alan Kay should consider that it is not easy to write OOP code in java or c++.


1. Allen Newell at CMU AI built a system called Lstar that was only for "Greenspuning", it was a language for bootstrapping up higher languages. It's very hard now to find even a mention of this on Google. This was decades ago.

2. I recently have been spending time learning and using the Go language from Google. It has almost no facilities for booting new languages. Nowadays that's called building a DSL. The thing is, Go is very useful, efficient, and easy to learn. Plus, it has an excellent system for concurrent and parallel programming. They explicitly decided against building in facilities for DSLs, as they are seen as making systems hard to understand.

Alan Kay wasn't wrong, he had a particular point of view. To me, today, Kay's view seems old-fashioned compared to Go. Both Go and Kay's OOP are very sophisticated. In very different ways.


Just a personal view, but my feeling about Lisp and SmallTalk is that they have opposing views of DSLs. Lisp culture seems to celebrate "bottom-up programming," While SmallTalk seems to celebrate writing programs that are unmistakably SmallTalk.


It's Smalltalk. Not SmallTalk.

I guess that Smalltalk also likes bottom-up programming, but it does not meta-level or language-level programming often in an object-oriented way. Lisp might do that too, but it often puts other interfaces on top. CLOS is an example: CLOS is itself an object-oriented system (see AMOP), but on top are functional and descriptive (macro) layers.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: