The Sapphire Programming Language - The Fundamentals
In the few days since we announced the Sapphire Language project there has been quite a bit of discussion and speculation on various Internet forums. People have been wondering what Sapphire is exactly - is it a ‘type of Ruby’, or is it more like Python? Is it strongly typed, will it be exclusively for .NET and so on..? Here I’ll try to give a few more details which, I hope, will clear up a few misconceptions...
What is Sapphire?
Sapphire is a dynamic, object oriented programming language being developed by SapphireSteel Software.
Is Sapphire a fork of Ruby?
No. Sapphire is a new programming language. It will use a Ruby-like syntax but it is not a ‘type’ of Ruby or a ‘fork’ of Ruby.
What are the main characteristics of Sapphire?
Clarity and lack of ambiguity
Deep object orientation
‘Black box’ encapsulation: data inside objects is always private
Dynamic programming with a class’s explicit ‘consent’
Incremental testing via type assertions
Is Sapphire a strongly typed language?
No. Sapphire variables may take on any type and a single variable may be assigned different object types (no coercion required!) - just as in Ruby. Type declarations are neither necessary nor are they enforced. Type assertions are optional. They give the programmer the ability to assert that, at critical points in a program, a certain variable is expected to have a specific type or fall within a specific range of values. Method return values may be asserted in a similar way. Type assertions facilitate incremental testing to verify the correctness of a Sapphire program. They do not cause a variable to be instantiated to the asserted type.
What platform, will Sapphire run on?
The Sapphire language is not platform-specific. SapphireSteel Software’s implementation of the Sapphire language will target the Dynamic Language Runtime on .NET. We will be happy to assist other developers who wish to implement Sapphire for other platforms.
Is Sapphire a proprietary language?
The Sapphire language will be defined by SapphireSteel Software. We shall publish a full Sapphire language specification describing both its grammar and semantics. This specification will be made public and other developers will be able to use it to implement the Sapphire language.
Is Sapphire ‘like Python’?
Not particularly. Sapphire is an orthogonal language characterised by a small, unambiguous syntax. Some people have suggested that this makes it similar to Python. In fact, Sapphire is not greatly influenced by Python and the two languages have few points of similarity. For example, unlike Python, Sapphire implements ‘black box encapsulation’, single inheritance, it has no procedural programming capabilities (it is 100% OOP) and indentation is not significant. In short, Python and Sapphire are not close relatives.
Is Sapphire like Smalltalk?
There are many points of similarity between Sapphire and Smalltalk. Both languages are deeply and consistently object orientated and implement thorough encapsulation with data-hiding. However, there are also many differences. Sapphire’s syntax will be much more familiar to most programmers. It has familiar constructs such as for loops and if tests. For example whereas Smalltalk’s message passing mechanism requires multi-part messages to be sent to an object like this:
(a = b) ifTrue: [^'ok'] ifFalse: [^'error'].
Sapphire uses the Ruby-like syntax:
if ( a == b )
Is Sapphire a competitor to Ruby?
No. The two languages are very different and are best suited to different type of application. Ruby’s rich and varied syntax and the fluidity of its dynamic capabilities make it a very adaptable language for scripting, prototyping, research, AI and metaprogramming. Moreover Ruby is a wonderful language for implementing dynamic frameworks such as Rails. By contrast, Sapphire’s principal goal is to implement an unambiguous, highly modular programming language in which the security and reliability of a program’s runtime state can be tested and predicted in the process of incremental development.
When will Sapphire be available?
Sapphire is currently in the early stages of development. We have not announced a final ‘release date’. We propose to make a preliminary release of an experimental Sapphire grammar in the near future and we will publish revisions of the Sapphire specification as it continues to be developed.
I like the idea very much, but I am still unclear as to its ultimate purpose and intended audience. For instance, can you envisage a time when developers might forsake their favourite development language (Python/Ruby/...) for Sapphire? And if not, then why. What, in the collective mind of SapphireSteel, is likely to be the best outcome of your efforts to develop and promote Sapphire?
Let me be honest: I am sure that the developers of any language would like to think that it will attract users from other languages. That said, we are not trying to compete with any specific languages such as Ruby or Python.
The motivating idea behind Sapphire is to create a programming language and environment to implement a fully object oriented, dynamic language which has a familiar, accessible syntax and provides the ’safety’ features that people expect from statically typed languages. In other words, this is not so much about giving people a choice between Ruby and Python or Sapphire - more about having a choice between C#, Delphi or Sapphire. We aim to provide programmers with type and range verification mechanisms to validate the correctness of their code (as they would expect in C# or Delphi) while simultaneously fully implementing dynamic typing. We want Sapphire to be a really safe language - one with rigorous encapsulation and first rate error handling/recovery. When talking to developers coming to Ruby from other (non-dynamic) languages it is clear to us that many of them give up on Ruby at an early stage for two main reasons: 1) they feel that Ruby is not ’bulletproof’ and 2) it does not provide them with all the capabilties needed for creating standalone desktop apps.
Our implementation of Sapphire will address both of those issues. While it will not require or enforce type-declarations, it will perform type verification. Its version of encapsulation/data-hiding will be very thorough to ensure reliable re-usable class/object creation without side effects. It will implement dynamic programming including runtime metaprogramming but it will have mechanisms to do so only by the consent of each class or (for complete runtime security) with the consent of the Sapphire system itself. Moreover, it will implement fully visual event-driven application design and programming and will also be supported by a dedicated coding environment called Amethyst (about which we’ll have more to say later).
I applaud your aspirations, and wish you well. As a professional Delphi developer, I have taken a personal interest in Ruby for several years but have never fully committed myself to it. Though elegant in many ways, it simply did not appear to be in the same league as Delphi in terms of IDE and applicability to desktop applications. As I see it, Sapphire will target these specific issues. Just as importantly for me, Sapphire is looking to find a place on the podium alongside such notables as Delphi and C#. That being the case, I look forward to the day when I can seriously consider Sapphire as a viable alternative to Delphi. Additionally, I truly believe that you guys can make a go of it - if anyone can! You can be sure that I’ll be "looking in" over the coming months with great interest.
Thanks for the vote of confidence!
I am a long term Delphi programmer myself (ever since the beta version of Delphi 1) so I think I understand your feelings. It’s early days for Sapphire and you’ll see quite a few other (hopefully fairly interesting) things from us before ’Sapphire In Steel’ finally arrives. As you can see, we are pretty active bloggers so we’ll be giving quite a lot of information to keep you informed of developments on Sapphire.
Any further progress on Sapphire, Huw?
This has been put back to allow us to push forward in the development of our Flash Platform IDE, Amethyst, which has proven to be a huge and very time-consuming endeavour. While we made good progress on the early work on Sapphire, I can’t see us having the time to complete this in the near future. If we have more news, I’ll post it here.