Huw: I haven’t noticed much signs of development on S# recently. Your web site hasn’t been updated since 2004 so what’s brought the project back to life again?
David Simmons: Actually the development never stopped. What happened was that I joined Microsoft and became deeply involved in some other projects. I knew that there was some revamping that needed to occur to take it from a demo / open trial to a release language. The core group of people who contribute to the project have been in discussion with me all the time – so development has never stopped at all.
Huw: What’s going to be new in the new release?
David Simmons: The licensing agreement will be different. The license that’s there states that you can try it but you can’t ship anything with it. The language itself will have been very much stabilised too. In the earlier release we were trying to experiment with all sorts of possibilities. In many cases there are multiple ways to do the same thing. That’s fine when you are experimenting but it’s really not what you want to have in a stable language. You want to have one consistent pattern for each set of semantics. You want the number of actual concepts that someone has to learn to be minimal.
Huw: What sort of things are you taking out of it?
David Simmons: There is more than one way to declare fields. There’s more than one way to involve certain kinds of messages. For almost each part of the syntax there are often two or three ways to do things. That has now being culled down in almost every case to just one approach and everything else is either deprecated or disabled.
Huw: Will this be hosted in Visual Studio 2005?
David Simmons: Good question. The short answer is that S# has its own IDE which will be significantly enhanced. The Visual Studio model is file-based and, while S# supports fully the file-based model, especially for scripting development, it also supports a repository-based model where you navigate semantically by class, method, module and namespace.
Huw: Are you saying that those things would have been impossible to implement in Visual Studio or did you simply decide that it would be more appropriate for it to have its own environment?
David Simmons: There are many reasons for it to have its own environment – one of which is cross-platform support. Visual Studio is clearly the most dominant and most popular IDE on the Windows platform and has a really rich debugging environment and lots of other tools, so there are many reasons why it might be valuable to have S# supported in there. The version that was released – the technology preview of S# - worked with Visual Studio 2003. But the plugin for that has not been upgraded and probably won’t be upgraded to the current release. There is a lot of engineering work involved in doing that and S# is not trying to be a mainstream language competitor in the commercial space.
Smalltalk And S#
Huw: What was the real motivation for bringing a version of Smalltalk to .NET in the first place? I mean, what does it bring to .NET that other languages don’t?
David Simmons: S# wasn’t designed for .NET at all. Smalltalk in its original incarnation made a lot of sense when there were no other operating systems and you didn’t have to have a lot of interoperability. But today the kind of interop you want to have, the ability to be small and agile in what you have to write – which are the characteristics of the programming aspects of scripting languages – those are the things that Smalltalk lacked. S# was really an attempt to bring the best characteristics of a rich language like Smalltalk and mix them with the characteristics of scripting languages and high-level programming languages which have typing information in them. When .NET happened to coincide with the time that as being developed it made sense to make a version that ran on .NET.
|S# .NET |
| Working in direct collaboration with Microsoft since 1999, the S# compiler architecture was extended to support the generation of native Microsoft.NET Framework IL modules and assemblies. Key features of the Agents Object System’s [AOS] dynamic language platform facilities were also extracted and ported to Microsoft’s .NET Framework to add an extended range of dynamic and scripting language services to Microsoft’s .NET Framework Runtime.|
Huw: You previously had versions for both AOS and .NET. Can you explain what AOS is and how it’s related to .NET?
David Simmons: It’s not related to .NET in any real fashion. AOS is the virtual machine that I originally developed for Quasar Knowledge Systems, a company which I founded in 1989; we developed our first version of the AOS (‘Agile Object System’ Framework) in 1991 as a multi-language backplane principally supporting QKS Smalltalk. Today it is in its 4th generation serving as S#’s native reference virtual machine and it’s pretty much a state of the art dynamic language VM.
As you probably know the Java and .NET virtual machine were originally designed for static rather than dynamic languages. A great deal has now been learned about running dynamic languages on top of .NET. To implement a dynamic language in the CLR you have to build a dynamic language layer on top of the static language architecture. But, while there are differences of opinion among the academic and technical community, my view is that to build the most efficient dynamic language virtual machine you go the other way around – I view static implementation as a special temporally phased case of dynamic. So in my AOS design I took the approach that static language VM functionality would be a subset of the general dynamic services including type services. I think that when Microsoft was designing the CLR they had broader and different technical and business objectives for choosing the path they did; Microsoft has certainly shown a strong interest in dynamic languages and there importance is well recognized – which is one of the reasons why I joined Microsoft.
Dynamic Languages and .NET
Huw: I guess the best known example of a dynamic language which has been brought into .NET is Iron Python. Has Python had to grapple with the same problems you’ve had to deal with?
Huw: But getting back to S#, can you tell me what new features you are planning for it?
David Simmons: Smalltalk has faced a number of challenges in its language design that held it back from being successful as the Internet revolution took off. One of them was that it didn’t have a file format that was human consumable. Also, Smalltalk implementations have not historically provided an easy way to plug into development being done outside of the Smalltalk environment. That’s what’s often characterised as the monolithic environment of Smalltalk.
It wasn’t easy to integrate Smalltalk with other languages such as C or C++. And finally, as Smalltalk was designed to be almost its own operating system it wasn’t designed to be modular. You have what I call a kind of ‘image soup’ – you had everything there, your state could always be saved but when you wanted to deploy anything you had to do a kind of ‘stripping’ mechanism to throw away everything you didn’t need; and that can be very difficult to determine. Smalltalk wasn’t designed to have independently deployed units that could be brought together to build systems - and that’s really the way we usually build software today. Those were all issues for Smalltalk to tackle.
Huw: So how are you addressing these issues? If I’d been using a fairly traditional type of Smalltalk such as VisualWorks, Dolphin Smalltalk or Squeak and I moved into your next version of S# what are the big differences I’d see?
David Simmons: The first difference you’d see is that you can build an application that you can deliver as set of components. You don’t deliver a single image. You can deliver DLLs which are modularized image slices. Now it’s true that there have been other Smalltalks such as Smalltalk MT that have that capability. But the footprint size you’ll see is that you can deliver a component in the 4 kilobyte range. So you can make libraries that contain Smalltalk code and you can make your DLLs accessible from other languages such as C. You’ll also see that those components can run inside another process so you can run them inside the desktop Shell, say, or inside Internet Explorer. And they support a multi-threaded model.
Huw: To what extent are we talking about doing unmanaged programming and to what extent are we talking about managed programming?
David Simmons: As I said, I believe that Microsoft is committed to making dynamic languages run well on .NET. As that capability is standardised you’re going to see a variety of dynamic scripting languages on a common infrastructure and S# will certainly look to have an implementation using those facilities, but I want to make it quite clear that Microsoft doesn’t own or endorse the S# technology and they aren’t affiliated with the work of making available a .NET version of S#. The forthcoming version of S# will be for the AOS.
Huw: The .NET version of S# then is some way into the future and is dependent on developments related to dynamic language support from Microsoft?
David Simmons: As you know, I work for Microsoft in the dynamic languages area and therefore I am aware of Microsoft activities in that regard. My answer for S# is that I will work with and help the S# community to integrate with and support whatever CLR standard mechanisms that appear for enabling dynamic language interop on a standard object model.
What I won’t do is what I did in 2000. I developed technology that layered on top of what .NET had. I built a JITter and put it on top of the CLR. It worked fine and offered a full range of dynamic language capabilities. But if you wanted to use some other dynamic language that language would know nothing about what I’d implemented. So if you wanted to have VB or Iron Python talking to S# they would have no interoperability at the dynamic language level.
Incompatible Class Libraries?
Huw: One of the problems with existing languages is the incompatibility of class libraries. Smalltalk has its class library, .NET has a different one. If you are going to bring an existing language into .NET, one of those libraries has to be sacrificed, doesn’t it? Or can they work together?
David Simmons: This is an challenge for all language frameworks. It’s a challenge for Iron Python too. You can’t get them to co-exist 100%. That’s because in each language there are intrinsic literals – things like numerics, collections, or their usage semantics, etc – and the CLR defines a mechanism for how these things work which may not always map appropriately with your language of choice.
In Smalltalk, for example, the way in which you work with strings, arrays and collections is not entirely compatible with the way the CLR deals with those kinds of objects. So either you say the programming model will preserve the language’s semantics but you sacrifice the ability to interoperate with other language such as C# or you say that I’m going to use the framework that is consistent with .NET to gain full interoperability with other .NET languages but sacrifice compatibility with other versions of my language. Since being involved with the ANSI standards process for Smalltalk in the mid ’90s, my philosophical approach has been to offer multiple libraries and you just decide which you want to use.
Huw: Are you saying that you’ll be able to mix classes from two libraries – say use some classes from the Smalltalk class hierarchy and others from the .NET class library – or do you mean that you have to decide at the outset that you are going to commit yourself to one or other of those class libraries?
David Simmons: By and large you can take a bit from each class library. The challenge is that if you want to take Smalltalk objects and you want to pass them around to .NET code, they may not know what that object is or how to deal with it. The reverse tends not to be true. You can make .NET objects for most intents and purposes behave like Smalltalk objects. The reason for that is that Smalltalk is not concerned with the structure of objects but only about how they behave. One of Smalltalk’s great characteristics is that, by and large, code does not expose the objects’ structure at all – only their behavioural characteristics.
Huw: Haven’t you still got the problem, though, that objects are derived from the two different class libraries and therefore descend from a different set of ancestors all of which have different behaviour? So while you might not need to get at the internal structure of an object, it will, nonetheless, be reliant on inherited behaviour going right back up the class hierarchy? Surely that would cause problems in trying to get objects from one class hierarchy working with objects from another one?
David Simmons: In general that’s true. But there are a lot of features in the architecture of S# to deal with these kinds of problems. It has the ability to do concrete and abstract mixins. Once you have a mixin capability you are not so constrained by that single inheritance hierarchy for exposing contracts in a consistent fashion. That’s necessary if you want to be able to extend beyond some of the inheritance constraints of the single parent inheritance systems. One of the things a dynamic language can offer is the ability to extend and alter the behaviour and structure of an existing class.
Ruby – The Challenge Of Complexity
Huw: Recently a couple of object oriented other languages have been starting to make an impact. I’m thinking particularly about D and Ruby…
David Simmons: I’m very familiar with both of them.
Huw: Those languages are increasingly attracting interest from people who may be dissatisfied with the languages they’ve been using previously. Both of D and Ruby take some features, ultimately, from Smalltalk. Ruby in particular seems to owe a great deal to Smalltalk. Why do you think these languages are generating so much interest and is that interest really justified?
David Simmons: I attended the first Ruby conference. Actually, Matz and other folks in the Ruby community had quite an extensive discussion about the possibility of porting Ruby to run on the AOS.
Ruby has brought in a number of Smalltalk-like characteristics to the LAMP  stack languages. Every language has its foibles. People may tell you that Ruby is not the most elegant of languages but what Ruby does attempt to do is make consistency for the developer a very high priority – as Matz likes to call it, “the principle of least surprise”; so what you really expect to have happen is what does happen.
Huw: Do you really think so? I must say I’m not entirely convinced by the so-called principle of least surprise. I’ve done a lot of Ruby programming recently and I am constantly surprised. Ruby frequently does things that I’m not expecting. The scoping is a bit odd and there are some things that are very strange indeed – such as methods that can poke about inside objects ‘from the outside’. Going back to what you said earlier, when you were talking about your developments of S# you said you’ve been paring away things, trying to have just one way of doing any one thing. But in Ruby there are often half a dozen ways of doing the same thing many of which have slightly different effects…
David Simmons: As a language designer with a language aiming at very much the same space that Ruby is in, I’m trying to be balanced in my response rather than just promoting my work. Thinking about your point about Ruby having many ways to do something – I see that in Smalltalk as well. It’s what I call ‘the paradox of choice problem’.
Part of complexity is having too much choice. And there’s a very difficult tension between having enough choice to give you flexibility and having that choice lead to excessive complexity when you try to solve a problem or to understand a solution. That often leads to a lot of tension in the 80/20 case – eighty percent of the time I’m going to adopt a certain pattern and so it would be nice if the language did it this particular way, but twenty percent of the time I need something else for ease of transition. It’s a balance between ease of use and an elegant architecture.
In the case of Ruby, it very much continually weighs in favour of trying to cover that eighty percent case and the cost is often what you see when they need to do subtle variations. Matz has been doing Ruby for many many years. It’s not really a new language. It’s just becoming popular but I think he started work on it in 1995.
I’ve been working on scripting and dynamic language stuff since the mid-to-late ’80s and my first exposure to dynamic languages was in the ’70s. I did a lot of stuff with Forth and APL. I did implementations of BASIC in the late ’70s and Forth implementations in the early ’80s. So I’ve had a long time to have a look at these kind of language issues, and part of the reason why S# has sat so long without my trying to push it out the door is because some of these problems are very hard.
You have to think them through and you have to experiment. If you get a big user base and you put stuff out, it’s very hard to remove features. I think Microsoft understands this problem well. Within LAMP stack languages we see this type of ‘feature history’ challenge arising too. As they try to go forward and add more features they are recognising that they are carrying with them a lot of baggage from their earlier designs.
This is typical of patterns that happen with versioning in Just In Time integration. And unless you have a solution to that problem that can address the versioning from the point of view of the person who wrote the code getting what they expected to happen, you have a problem.
The way that I solved that problem is that when I choose a method that I want to select from each of those sources, one of the factors I take into account is: who is asking for the method? This is much like with dynamic binding languages where you ask ‘What is the object on which the message is being invoked?’ and ‘What is the name of that message?’. If you have multi-method capabilities like S# you have to ask, ‘What are the types of the arguments?’ Another predicate to that question is to ask: ‘Who’s asking for an implementation of this method?’ In the research community this “who’s asking” approach is now known as subject-oriented programming. By incorporating the ‘who’s asking’ question, I can bring in a lot of extra things to address versioning. Which has also enabled S# to support dynamic security and sandboxes.
Trends In Web Development
Huw: The dynamic languages we see these days seem to be used predominantly for web development. Is that where S# is heading?
David Simmons: When I began on my first implementation of Smalltalk in ’91, it was because I had been doing so much commercial work over the years with integration. The web changes the pace at which integration happens. It used to happen in the order of months. On the web it’s instantaneous. In many cases you are bringing in web services and other components on the fly. The web requires the ability to handle schema changes that may happen between classes or methods. And if you think about the way that dynamic languages work, they are designed so that the developer might be changing the way that a class behaves at any given moment. They are pretty agile at handling those kinds of changes. So it should be no surprise to find that dynamic languages are very effective in environments with a lot of turbulence. They are just not as brittle or fragile in the face of that kind of change happening.
But that alone is not enough to have made Internet success happen. Otherwise Smalltalk and LISP would be dominating the Internet space.
Huw: You are saying that these new languages have come along and stolen Smalltalk and LISP’s thunder?
David Simmons: Yes I probably am. Those newer languages were actually solving the problems that people were facing. One of the things that happens when you sit down to write a script is that you don’t want to say a lot but you still want to be able to declare a whole program. A lot of scripting languages make that very easy.
Earlier we were talking about the fact that Smalltalk doesn’t have a mechanism to declare a function. But look at all these scripting languages: in the matter of just a few characters – often just a line or two of code – I can easily declare a function or a class.
In the case of a language such as LISP, were you can certainly define functions very easily with lambda expressions and so the problem isn’t that you can’t declare them; it’s a problem that for the prototypical mainstream user of scripting languages the semantics and program source/forms are hard to understand.
With a scripting language, often a newcomer can look at it, see the keywords, experiment a bit and pretty soon they can more or less intuit what’s going on. You can’t underestimate how much that’s worth. And there are also good libraries for those languages. If I want to build a blog, a community web site or Wiki, I can pick up a PHP system and, with the minor hassles of maybe getting MySQL set up and Apache, in a few hours I can get a full web site up and running and I can just tweak it. That is very compelling for many people.
Huw: Before we wrap up, the thing I’d like to know is when the next version of S# will be available. And will there be a commercial version?
David Simmons: It’s premature to give you a hard date. I can say it will be out in the Fall. It’s likely that there will be a commercial ‘piece’ to it. The actual core language elements and the basic set of tools will remain free.
One of the important things about the LAMP stack languages is that they are not just free but they are free on multiple platforms. You can’t really build software today in the world of the Internet if you can’t serve it up in some way to an Apple machine, a Linux machine and a Windows machine. Depending on your business model you either have to be able to produce output that can be displayed on those machines or, if you’re doing client side work, to have it actually have it able to execute on the client of each of those machines.
Huw: Does that mean then, that when you go towards a .NET version, you will be cutting yourself off from all that? I realise you have two versions of S#. But for other people who are developing for .NET, they are cutting themselves off from multiple platforms aren’t they…?
David Simmons: I want to make it clear that I’m keeping on my Smallscript hat here and I am not speaking as representative of Microsoft. In short, I don’t think what you said is really true. The issue is that on the server side the important thing is that you can produce output that will display properly on browsers on those other machines. And you can absolutely do that with the CLR from .NET.
- David Simmons
Smallscript web site: www.smallscript.org
| David Simmons has been involved as language and frameworks implementation architect and designer within the dynamic language community since the late 1980s. As the founder of SmallScript Corporation in 1999, he served as CTO and continues to be actively involved in development of the 4th generation of Agents Objects System common dynamic language runtime and S#, a superset dialect of Smalltalk for the AOS CDLR and also for the Microsoft .NET CLR. He previously founded Quasar Knowledge Systems, Inc (QKS) in 1989 to develop a next generation platform for integration of distributed Agent and Object technologies. QKS operated as a Smalltalk vendor until the close of 1998. He served as QKS lead architect on the development of Agents Object System (AOS (r)) multi-language runtime and QKS Smalltalk for Macintosh, Win32. QKS was a principal party in the ANSI Standard for Smalltalk.|
By the late ’90s he was exploring the evolution and rise of community, scripting languages and their impact on the internet and began to re-shape Smalltalk into the S# language. During this period he worked on a variety of commercial projects ranging from development of Desktop and WinCE device applications for GPS mapping and data entry for site-surveys and resource mapping, to multi-media music players for LockStream, to VB-like IDE and debugger systems for WonderWare (Invensys) corporation’s migration of their COM technology to .NET.
In March 2005 David joined Microsoft as a Senior Software Architect to work on Community, Scripting and Dynamic language experiences and tools within the Developer Division of Microsoft. The focus of that work has been on pro and non-pro developer experiences in the context of LAMP languages, VB, JScript, and CLR runtime capabilities.