For many of us, it all starts with Smalltalk. (If words such as "VisualWorks" or "VisualAge" or "Squeak" have much meaning to you, and you know what "ENVY" is, then you and I probably share a lot of things to talk about). When I first learned about Smalltalk in 1994, the wealth of ideas was so overwhelming that it changed all my career: it was during that Smalltalk seminar (led by Prof. Binh Q. Nguyen, of IBM in Cary, North Carolina) that I decided to leave Quantum Fields and change to Computer Science for my PhD research.

I am the co-author of the IBM VisualAge for Smalltalk Handbook.
(You can order the book by ISBN: 0738400874 (Volume 1: "Fundamentals"), 0738400769 (Volume 2: "Features")).

To me, TOPLink is a Smalltalk program first. (To those of my readers who wonder what I mean: when we first made TOPLink, it was a Smalltalk program, there was no Java; we ported it to Java when Java became popular).

UIs

In addition to object persistence, I am deeply interested in the implementation of UIs integrated with native facilities. (The Squeak Cheese-5 system falls within this category. It is similar to IBM CW, and Eclipse SWT is a direct continuation of the same idea.) Some other important technologies, e.g. JSR-287, try continue in the same direction (at least in the RI). The Hierarchically Structured Control Information Editor is based on similar ideas (and was implemented in Smalltalk at the time of patent application).

OK, so we have our great abstract machine of the day. For our discussion, it does not matter whether it is some sort of functional or Smalltalk or Java VM. It could be for a new cool-language-of-the-day (1990ish Smalltalk? 1996ish Java?) or cool-device-of-the-day (iPhone or any N-th-generation smart phone or something) — what matters is that we are trying to do this unprecedented new UI with this uprecedented new cool thing underneath (whatever that thing happens to be today).

The first question that interests me, is: Do we build it inside or outside the underlying abstract machine? Or, asking the same question differently: how does our ultra-cool UI relate to the UI facilities outside our abstract machine?

Of course, there have been plenty of very good answers to the question. Research and practical implementations abound over the last 40 years. And yet, today's cutting edge designs for "UIs of tomorrow" are still full of confusion. Let's look at some history (or at least some milestones of greatest importance).

Is Smalltalk still relevant today? I very much believe so. True, with Java we did make a lot of progress from where we were with Smalltalk a decade and a half ago. And yet we do not have a language that gives the answer to fundamental questions. Today, I am trying to go back and revisit some of the fundamental concepts:

One of these, is concurrency. We know that we have pretty much exhausted our potential for growth of sequential performance: with deep pipelining, instruction reordering, etc, we have reached the limit, so the only way to gain further performance increase, is to do more work in parallel. So manycore VMs are the next big thing. And I am not talking about 4–8–16 cores. I am thinking more along the lines of 100–1000 cores. Do we have such hardware yet? Yes, Tilera processors already have 100 cores today. Can one take full advantage of this technology, for example for a JVM? Certainly not when JSR-133 is in the way. We need to go back and do more research. Stefan Marr's RoarVM is a great breakthrough in manycore VM technology. Stefan's VM integrates with native OS threads to back Smalltalk processes. Currently, I am trying to implement a more radical idea. I propose to drop OS threads and go back to the classical Smalltalk "lightweight process" scheduler, basing concurrency purely on message passing semantics. In other words – we need to re-evaluate the ideas in Alan Kay's Smalltalk-71.

Another area of top importance, is security.
During the last several years, I've worked on security for many clients ranging from the world's top military security shops, to tiny private clients. Shockingly, there is a pattern of problems with security repeaeting itself over and over, which always trace back to the language.

This is not a new discovery. There have been a number of proposed solutions to this class of problems. I think the most interesting and promising is Newspeak. I'd say I am satisfied with Newspeak's answers to most of my questions, from the language perspective. The only large piece still remaining, is ORM. So we need to go back and re-think TOPLink.