Why Neptune?

Lately I’ve been writing a lot about the neptune language, the replacement for smalltalk on the OSVM platform. I’ve tried to focus on the technical aspects both because there’s lots to write about but also because when you’re blogging about work, keeping it technical makes it less likely that you’ll accidentally write something, shall we say, career limiting. In this post I’ll take my chances and write about one of the less technical aspects: why we made the switch from smalltalk to a different language, and why we decided not to use an existing language but design our own. It is not about the strategic business decision of changing the language — for that you’ll have to go through the official channels — but my perspective on the switch as one of the people developing the platform.

I’ll start off by explaining a bit about OSVM and why we used smalltalk for the platform in to first place.

Why Smalltalk?

To give some context I’ll start of by describing what OSVM is. The OSVM platform is basically a virtual machine targeted at memory-constrained embedded devices. The platform has been designed with several goals in mind. It should be very simple in order to make the runtime as small as possible, since memory is limited. It should never be necessary to restart the system — if you’re dealing with software for applications security or medical equipment you want the system to be able to run without any interruptions, ever. If an error occurs, and of course they do, it shouldn’t kill the system; rather, it must be possible to diagnose and fix the problem in the field. That’s not always possible but there’s a lot you can do to make it more likely that the system will survive an error. Finally, it must be possible to update the running program in the field, both to fix errors and to install software upgrades. Being able to diagnose a bug in your program is no good if you can’t update the software to fix the problem. This, in short, is what OSVM is all about.

These requirements didn’t pop out of thin air. When you’re used to working with smalltalk this is what you expect from your platform: robustness, flexibility and the ability to interact directly with running programs and to update code on the fly. The smalltalk language and environment were developed together, which means that language was designed with all the issues that are important to us in mind. This is not the case with any language I know outside the smalltalk family, which makes it uniquely suitable for our use.

But using smalltalk is not without problems.

Why not smalltalk?

The languages most used in writing embedded software is C and C++. If a company considers using a platform like OSVM instead they not only have to consider the direct cost of buying the system from Esmertec. They also have to consider the indirect cost in time and money to train their employees to use the system, before they get actually writing software.

C++ is a object-oriented programming language (let’s be generous and call it that) but other than that, C++ and smalltalk are completely different. In order to use smalltalk, a C++ programmer would have to learn everything from scratch: how to declare a variable, how do write an if and while statement, how to write a string or character literal, everything. Since most embedded software is developed in C and C++, that means that there is a considerable indirect cost associated with using smalltalk with OSVM.

The pragmatic programmers recommend that you learn a new language every year. I think learning new languages, both programming and natural, is a great hobby. If I have a deadline, however, “broadening my thinking” by learning a new programming language is not my top priority. Imagine that you were writing a book and had the choice to either write it in English using a primitive ASCII text editor, or in Danish using a state-of-the-art graphical text editor. Assuming that you don’t speak Danish, what would you choose? Or, perhaps more realistically, what would your boss choose for you?

Even though the OSVM system is very much inspired by smalltalk and the smalltalk environment, what is important is not the language itself. The important thing is the properties of the language: robustness, flexibility, serviceability, etc. The goal of the neptune language is to retain all the important aspects of smalltalk but to adapt the less important ones, like the syntax, to make it easier to learn and use by programmers who are used to more mainstream programming languages. That is not to say that syntax is not an important part of smalltalk but it is not essential for its use as a part of OSVM.

I may give the impression that I think smalltalk is the pinnacle of programming language design and any change is a change for the bad. That is not the case: I think there are plenty of ways to improve smalltalk. In changing the language we’ve tried to address many of the quirks and shortcomings of plain smalltalk to get a system that is all-round better to use and not just easier to learn for C or C++ programmers. I won’t go into any details about how I think neptune improves upon smalltalk, though, since that’s a touchy subject that I don’t want to obscure the point I’m trying to make here.

Why Neptune?

Why design a whole new language instead of using an existing one? The whole point is to not force people to learn a new programming language and if we design a new one we can be absolutely certain that no one knows it.

It all comes down the nature of the OSVM platform. The language has to be very simple since the runtime must be minimal. This requirement alone excludes many languages including Java, C# and python. But the real killer is that it must be possible to update the code dynamically. I don’t know of any languages (except smalltalk) where you can give a reasonable meaning to updating the code of a running program in all cases. This is especially bad in languages where the runtime behavior of a program depends on static typing. When designing a language it is very easy to make decisions that make it very hard to update code on the fly. You have to keep this kind of use in mind during the design and smalltalk is really the only language designed like that. Having decided that smalltalk is not the way to go, that means that there are really no existing languages for us to use. Hence neptune.

Designing the language from scratch also means that we’re free to adapt the language to fit our use. The result is a language that, beneath an added layer of syntax, is still very close to smalltalk, and retains many of the properties that makes smalltalk unique. An indication of how close smalltalk and neptune are is that the virtual machine is almost exactly the same as before, the biggest change being that indexing is now 0-based instead of being 1-based. On the surface, however, neptune is much closer to C++ or Java. Basic things like variable declarations, control structures, operators and literals will all be familiar to a C++ or Java programmer. When learning the language this means people will be able to use much of what they already know and will be able to be productive almost immediately, and to move on more quickly to the more advanced concepts such as traits, blocks and optional types.

Some might consider it to be “dumbing” the language down but we’ve also made a conscious effort to make it possible for people to use the language without necessarily being familiar with the full generality of it. When you’re using an ifTrue:ifFalse: expression in smalltalk it might be intellectually gratifying to know that it’s not a “magic” construct, just a method call with two block arguments. But it’s not something you necessarily want people to understand from day one in order to use the language. In neptune, we have a separate if statement but that is still just a shorthand for a call to the if method. You’re free to call that method directly, without the special syntax, to the exact same effect. The full generality of smalltalk, along with some new constructs, is still available to you in neptune but instead of having it forced upon you, you can grow into it gradually. Even though it make the language a bit less clean than smalltalk, I think that is a pretty reasonable tradeoff.

14 Responses to Why Neptune?

  1. update code on the fly… This is not the case with any language I know outside the smalltalk family
    “Erlang has been designed to make it possible to incorporate functionality for replacing a version of a module with a new version of that module, even though at the same time there are processes executing the old version of the module.” Chapter 9, Dynamics of Modules, Erlang 4.7 specification

  2. Interesting, I wasn’t aware of that. I know erlang but didn’t know that it had been designed with this kind of use in mind.

    The way they handle updates of currently executing code is essentially the same as ours. As far as I can tell, though, an update only affects functions and not data. But maybe the language promotes a style of programming where it is not a problem that the data is not updated along with the code.

    Of course, erlang is not a realistic option for us (and I guess that wasn’t your point). It’s even more different than smalltalk and would require a complete reimplementation of the platform.

  3. a style of programming where it is not a problem that the data is not updated
    afaict data in Erlang programs is fairly simple, or kept in a database

    I guess that wasn’t your point
    Correct 🙂

    Neither of us would be surprised to learn that there are Lisp implementations with this functionality, but it seems that clever folk can play tricks with SML – Hot-Sliding in ML, 1994

  4. Just tripped over this, haven’t read it yet Dynamic Software Updating

  5. Gulp!

    Practical Dynamic Software Updating for C. Iulian Neamtiu, Michael Hicks, Gareth Stoyle, and Manuel Oriol. In Proceedings of the ACM Conference on Programming Language Design and Implementation (PLDI), June 2006. To appear.

  6. Thanks for the links — it’s sort of embarassing how little attention I’ve been paying to the research on this subject.

    I think, the approach used in “Dynamic Software Updating” is particularly interesting because they deal with problems very similar to ours but have, in pretty much all cases, taken a different approach than us.

    We, like Appel, allow old code to live along with the new code until it is no longer used after which it is GC’ed. They decide against that. We transform stacks on updates, which they argue against. In our case, since we have GC, we need to be able to traverse stacks anyway so it doesn’t increase the complexity of the implementation that much. We use a form of system-directed transformation of existing data where they use programmer-directed. But unlike them, all our objects are tagged anyway because the system is dynamically typed, so implementing system-directed data updates is much less of a burden for us. Finally, we use type replacement where they use type renaming.

    I think the source of all these differences is that we use updates very differently from them. In OSVM, the update mechanism has been designed with smalltalk-style incremental development in mind. Since this means that the code is updated during development in small increments, we’ve tried not to require people to explicitly specify how an update should be applied. Instead, we want the system itself to handle updates automatically.

    The approach used in the paper requires the user to manually specify transformations, which isn’t what you want during incremental development. On the other hand they argue, and some experience with OSVM indicates, that it is what you want when applying larger software upgrades. I suspect that we might slowly be moving towards a model that at least allows you to specify transformations more explicitly, like the model in the paper.

  7. Hi!

    When will neptune be available?


  8. My guess is that the an open source version of neptune will be made available within a month or two. I can’t make any guarantees, though.

  9. Gregg Wonderly

    The telephone switching industry has been performing software updates on running systems for decades in C and C++ environments. Their simple scheme is that every function has an entry pointer. When a function is replaced, that entry pointer points to a new block of code that performs a check with the OS for what version of the software the running thread was started with. Old threads execute the old code, new threads execute the new code.

    When the update is committed, the old code is overwritten with invalid opcodes and thus any remaining, long running threads will abort when they are next scheduled.

    The software design of those systems uses a lot of state that is not programatically stored, but rather in data. Threads of execution are short, except for some very special, key threads. Those processes have a special restart procedure that allows them to be “upgraded” to run on the new software.

    The end result is that you can undo that change too to downgrade to the old code if the new code doesn’t work as needed.

    When you have complete control of the whole environment, you can do this kind of thing.

    Designing a new language to encapsulate these types of things might be a good thing. The generation of the function dispatch table and its use is a compiler thing. So, no new language was needed to do that.

  10. Gregg: I’m becoming aware that code updating is a well-known thing in C and C++. I’m curious about the scheme you’re describing; how do you deal with changes to the program’s data required by a code update? When you’ve updated a system how do you get rid of old unused code?

    We wouldn’t be able to use C or C++ though, even with a suitable model for code updating. We want a simpler language with a higher level of abstraction. We also want garbage collection, better fault tolerance and error diagnostics, and many other things that C or C++ aren’t suitable for. Basically they’re the languages we’re aiming to replace (for certain applications, that is, not in general).

  11. I’m browsing OSVM info for my work, and am totally confused. OSVM started off as Resilient, which was bought by Esmertec and renamed to OSVM. And it uses Smalltalk, but in your blog you talk about Neptune for OSVM. So is this your own flavor of OSVM or is Esmertec going to Neptune?

    Also, could you comment on the current state of OSVM as you see it?


  12. I’m browsing OSVM info for my work, and am totally confused. OSVM started off as Resilient, which was bought by Esmertec and renamed to OSVM. And it uses Smalltalk, but in your blog you talk about Neptune for OSVM. So is this your own flavor of OSVM or is Esmertec going to Neptune?

    Also, could you comment on the current state of OSVM as you see it?


  13. Okay, so here is the brief history of OSVM. Originally, the platform and the company were called OOVM. The platform was based on Smalltalk. Later the name of the platform was changed to Resilient because that was just a much better name. Unfortunately the name had to be changed again because, as I recall, ‘resilient’ had already been registered as a trademark by a different company. So it was changed to OSVM.

    Then the company, which was still called OOVM, was acquired by Esmertec and turned into Esmertec Denmark. After a while, it was decided that we should replace Smalltalk as the programming language in OSVM. The replacement was Neptune, a language we designed ourselves. In the end, however, Esmertec decided to close down Esmertec Denmark and fire everyone there, which included all OSVM developers. That was this summer and by now everyone has moved on to new jobs.

    I can’t tell you what has become of OSVM after our office closed. If you need to know more about the current status of OSVM you should contact Esmertec. Actually, if you do contact them, I’m pretty curious to hear what they say.

Leave a Reply

Your email address will not be published. Required fields are marked *