Joshua Marinacci's Blog

Community Archives

Competition and the Java Ecosystem: why Sun launched the PDF Renderer and Scene Graph projects

I'd like to take a second out of my usual technical blogging to discuss something important. Sun recently launched two new open source projects: the Scene Graph and PDF Renderer projects. In both cases some readers wondered why Sun felt the need to start new projects rather than contribute to or recommend existing open source and commercial projects. Is Sun opposed to commercial Java software vendors? Do we insist on reinventing everything ourselves? The answer is an unequivocal no. Each new project inside Sun goes through a rigorous vetting process to determine what projects to start and how. Today I'd like to let you see inside our brains and find out why we launched these new projects.

the code came first

I'll start with the PDF Renderer. There are many existing PDF renderers out there, some open source and some closed; some written in Java and some in C. So why did we decide to start a new open source renderer when there's already a bunch out there? The answer is: we didn't!. We didn't sit down one day and decide to launch a new difficult project. The reality was much different, and stranger. The code came first.

Several years ago researchers inside Sun Labs created a PDF renderer because they needed an all Java PDF viewer for content created by Open Office. The library had to be written Java instead of a C wrapper because it had to work on every platform (and JNI wrappers have their own problems). It had to work under a license compatible with Sun's internal projects, so GPL was out. It also only had to read Open Office output so writing it would be easy (isn't that how they always start!). Given these constraints it made sense to write a new library.

Now fast forward a couple of years. Sun Labs has finished the internal project and doesn't need this library anymore. Since it was graphics related they asked the Swing team if we would like to use the code for our own projects or open source it. Richard Bair and I immediately said: yes, we want it! We had received numerous requests for a PDF renderer as part of SwingLabs (I think Rich even started on his own library at one point).

For two years Rich and I worked to get the code released, following up on all possible patent issues and finding resources to support the new project. Because we specifically didn't want this to be another "throw the code over the wall and forget it" exercise we decided to launch only if we could find a non-Sun employee to run the project. If there was enough interest for the community to run it, then we would open the code. If there wasn't enough interest then it was best to just let it die. Fortunately, Tom Oke from Elluminate expressed both a professional and personal interest in the project, so a few weeks ago I went back to the approval board and received the official go-ahead.

I don't expect the PDFRenderer project to compete with some of the high quality commercial solutions already out there. Many have done a terrific job of supporting every PDF file and feature they can get their hands on. There is enough room for more than one PDF library in the Java ecosystem. In fact, diversity and creative competition is what makes the Java ecosystem thrive. I wouldn't change it for the world.

the need came first

While the PDF Renderer was created because the code came first, the Scene Graph library was created because the need came first. The need was JavaFX Script (which is targeted toward a different audience). While I love the fact we have open sourced the scene graph and can code against it with Java, the primary reason for it's existence is JavaFX Script.

In the world of scene graphs there are many options. In fact JavaFX Script was originally built atop one of them: Jazz. We considered continuing to develop Jazz or it's successor Piccolo, but decided against it because they didn't fit the following constraints:

• Have a clear history of all copyright and patents in the library so we can indemnify Sun's customers.
• Have a license compatible with eventually moving it into the core JRE (which we hope will happen one day).
• The ability to transform Swing components, both input and drawing.
• Be smaller with an API tuned to the needs of JavaFX Script.
• Have internals compatible with the heavy duty graphics tuning we have planned (think pixel shaders). We need something very high performance to compete with the other emerging RIA platforms.

It turns out that the initial implementation of a scene graph isn't very difficult. You could build an initial version in a few days thanks to the support provided by Java2D. The tricky part is getting the API right. Even though we didn't adopt the code from Jazz or Piccolo (or even the NetBeans Visual Library), we did learn a lot from their APIs and how people use them. There are clear influences. It was not our intent to supersede those existing projects. We built what we needed for JavaFX Script. In the future, I hope that enterprising developers will build bridge layers allowing existing programs to use a new implementation built on the Scene Graph.

So there you have it. Two different open source projects created for two very different reasons. In both cases we actively support diversity and competition in the Java ecosystem. It's what makes Java great. Have a happy 2008!

A nice Java evening with sour cherry beer

After a several hour trek through Prague Castle and the Cathedral I arrived back at my hotel with around 400 photographs. It's going to take a while to go through them but here are some highlights.

After the castle I had dinner with Sébastien Letélié and Doug Matthews, two Java developers who live here in Prague and contacted me through my blog. We got a chance to discuss the latest developments in Netbeans and open sourcing Java, as well as the history of the Hapsburg Empire and the fall of the communists. This discussion was aided by glasses of local sour cherry and coffee pivo (the Czech word for beer) I must say that no matter where I have gone, members of the Java community have been funny, intelligent, and very friendly. Perhaps Java really is the universal language. Thanks for a great dinner guys.

That's it for this weekend. I'll have more to write next week.

- Josh

Java people in Prague

If there is any other Java people living in the Prague area who would like to go out for dinner, drinks, or do some general site seeing then just let me know. I'm going to be here for three more weeks and I don't know anyone yet. I'm reading through my Rough Guide book and it looks like there's lots of cool things to see here.

Thanks!

LA-stravaganza

One of the great things about my job is that I get to go speak to customers and other groups of Java developers. Even more amazing than the fact that Sun pays me to do this is that people actually show up to listen to me. I'm sure you've all had those times where you feel like you are still the dumb kid who just graduated and somehow you have to make everyone around you think you actually know what you are talking about. While I know that I'm a Java expert and have interesting things to say, a little part of me is still scared. What if I say the wrong thing? What if someone asks me a question that I can't answer. What if I walk into a room full of SWT lovers?! The agony!

No one? Hmmm. Maybe it's just me. :)

Anyway, last week Richard Bair and I drove down for a cheap, whirlwind tour of LA to visit five customer sites and two Java Users Groups. I am pleased to say that our trip went very well. We had an engaging and exhausting week meeting with some great Java developers, dispelling myths and out of date information about desktop Java, and seeing how people use desktop Java in the real world.

I won't go over every stop we made, but I will cover the highlights and lessons we learned.

• Our presentation got better as we went along. This is no surprise of course, but interesting. Our last presentation of the week: to the OC JUG, was much better than our first: to the LA JUG. After giving it seven times we knew the material, knew what to focus on, and most importantly knew what to skip over.
• Java 5 adoption is going great! When I spoke at the LA JUG a year ago I saw about 25% using Java 5 and 75% using 1.4. Last week the numbers were reversed.
• A lot of people don't know about Java Web Start. This surprised me because I've known about it for years (and written several different articles on it), but at most sites the developers didn't know about Webstart or only heard a few details. Clearly we need to do more to get the word out.
• Developers who use WebStart love it. At one customer site, where they use 1.5 and WebStart for everything on the desktop they said "Java Webstart has been a huge win for us". The developers are in LA and the customers are in New York. They can fix a bug in the afternoon, push out a new version that evening, then the customers are updated the next morning. That's what we like to hear!
• Most people don't know about Matisse for Netbeans 5.x. A lot of developers had tried Netbeans in the 3.x series and never touched it again. We demoed Matisse running in Netbeans 5.0 and really turned some heads. I think we are making headway.
• Developers want two way editing of GUI code. Matisse, like every successful GUI builder I have ever seen, saves the UI definition to a non-editible store of some kind. Several developers asked about two way editing of existing code. This is a question for you guys: is two way editing really what you need, or would a standard, cross-tool, XML format address your concerns?
• Trusted Solaris is cool! I've never heard of this product, but apparently we (Sun) make a version of Solaris that is very secure and can isolate applications from each other based on their security level. You could have one window that is classified as Secret and another as Top Secret. It can even manage what you type and copy to ensure you don't accidentally give out classified information (assuming I understand how this works). Obviously this is not something most people need, but if you need then it you really need it, and we make it.
• Everyone loves Aerith. Aerith is probably the best demo we've ever done. Everyone we show it to loves it and wants to learn more about how to do these types of tricks. It's really turned a lot of heads.
• I need to learn Flex. On several occasions someone mentioned Flash/Flex. We have a lot to learn from them.
• Swing is making headway. The speed, look and feel fidelity, and feature improvements (like SwingWorker) in Swing are being noticed. We don't see SWT making the inroads that it was a couple of years ago. This is a sign that we are doing the right things.
• We should do more road trips. It's exhausting but rewarding work. I wish we could take more trips like this to meet with developers in the real world. But then we'd never get any real work done. Always a balance, it is.

So I'd say the trip was successful. We received lots of great feedback and made people excited about desktop Java, Netbeans, and Java 6. So where should we go next?

Java's got a Bad Rep: The Rebuttal

So it's been a week and I've seen a lot of response to my last entry. One commentor in particular asked for a point by point rebuttal; which struck me as a spectacularly good idea. Here are the bulk of the arguments and my responses.

The Arguments

• Java isn't Free / Open Source / GPL / RMS-friendly
• Why use Java when there are plenty of native languages / environments to choose from.
• Java is missing templates / preprocessors / lambda functions / other advanced language feature that only backwards cave-dwelling languages lack.
• There aren't any applications written in Java. It must be a failure.
• Java / Swing is slow, looks bad, and doesn't feel native, doesn't let me do cool stuff like animation, 3D, or sound.

Here we go.

The Rebuttal

(1) Since it's such a huge (and apparently controversial) topic, I am covering the open sourcing issue separately in this other post. However, in summary, opensourcing doesn't solve our problems and buys us very little, in exchange for a lot of new problems. Follow the link for a full analysis.

(2) Why use Java when there are plenty of native toolsets to choose from? Well, first of all, it's better than a lot of them. If you want to write an application (not a script or a device driver) then Java provides you with a good toolset, great libraries, and a clean language which learned from the mistakes of the past. It's simply a good applications language that can make your programmers more productive.

Java can also be "write once, run anywhere". For people who need to support multiple platforms, especially more esoteric ones where you could never hire a native expert (say the palm pilot, or win 98), or if you simply don't want the headache of dealing with bizarre version issues, then Java provides you with a consistent platform to code against. It's compile once, run anywhere features are especially important in the age of ubiquitous networks with code flying over the wire. Java Webstart has been a godsend to companies with locked down desktops spread over the globe. (potentially running eight different versions and patch levels of Windows).

So why use Java? Because its better than a lot of the alternatives for writing applications.

(3) Java is missing language features. This is probably more a matter of taste than anything else, but Java isn't lacking features because no one thought to add them. Nothing in Java is new. Every part of the system, from language to library to VM, was carefully considered against the 20 year history of OO languages. Preprocessors were left out for a reason. So were pointers. Java is missing a lot of the more esoteric features, but most of those features aren't used in day to day programming anyway. A few of them, like generics, are slowly becoming more mainstream, and Sun is adding them as people ask for it. Remember, computer languages evolve slower than hardware or software platforms. It took 20 years for inheritance and polymorphism to become common place (and it's till not as common as you might think). The features Java is supposedly lacking we really shouldn't miss. And if there's something you just have to have, then you can use one of many addons to provide it like XDoclet and Shark, safe in the knowledge that if it compiles to Java bytecode then everyone can use it.

(4) Nobody uses Java. This simply isn't true. Probably 99% of Java applications are either serverside (where the user doesn't know or care what the application is written in) or are made for internal corporate use. As Eric Raymond pointed out: "there is empirical evidence that approximately 95% of code is still written in-house". Most Java applications, even Swing apps, are for corporate use. In these environments the robustness, productivity, and easy of deployment more than make up for Java's other flaws. There are plenty of high quality applications that people don't know are written in Java, and that's really the problem. Especially on the desktop I'd like to see more highlighting of Java success stories (and more ways to get the word out!)

(5) Java is slow, ugly, and doesn't do modern native things. I've saved this for last because I think it's the biggest problem. Java has this impression because, well, it was slow and ugly. Back when Java debuted nothing worked properly, applets were slow to load, and AWT used a horrid subset of the available widget set on each platform, all of which looked different and ugly.

Today the situation has changed. Swing has gone through several revisions to become a powerful toolkit, if complex. The speed issues have mostly gone away from improving the libraries and a decade of faster processors. Even on my now aging iBook I run jEdit quite nicely and have written tens of thousands of lines of code with it.

Swing itself has also matured (and gotten prettier). Most of the big bugs have been fixed. Quite a few attractive Look and Feels are available from Sun and 3rd parties. A lot of the missing functionality from the early days is finall in place. It is entirely possible to make great desktop applications, even consumer apps, with Java. We just need to get people to realize it.

The plan

Despite all of my argument preceding, Java still has an image problem. People still think that you can't write good desktop applications in Java because they don't see them. So what can we do? Show them! And keep building more!

First, we need to show off the good apps. Get the word out. I think we need a place to highlight great applications. Perhaps a sidebar on Java.net with a new application each day. The only requirement is that it be a desktop application with a downloadable demo. This spot should have it's own RSS feed and archive. Then we have to start the publicity. Get other sites to link. Make a download.com for Java apps.

Second, create a place to collect all of the tips and tricks it takes to make a quality desktop application. I've started a Wiki node here with a framework of what we should pull together: exe packaging, good look and feels, swing tutorials and articles, how to work with different kinds of media. Contribute whatever you know. We need to fill out the missing pieces.

Third, start a contest for quality Swing applications along the lines of O'Reilly's MacOSX app contest. We should have different categories for commercial and open source, full applications and mini programs, and maybe further sub-classification (word processing, media and graphics, personal organization). We'll probably need to get a corporate sponsor for this.

We all know that Java can make great software on the server. It's time to reclaim the desktop. (Wiki Here)

An Analysis of Open Sourcing Java

I'm going to try to really tackle the issue of opensourcing Java and state my opinion of why it's a bad idea. Then I'll propose a way would could do it without all of the problems. It's a long one but please read to the end and provide your feedback. This is an issue that many feel strongly about and has the potential to influence Java's long term future. And as a career Java developer, it's something that personally concerns me.

Note, I don't want this to become a Microsoft slam. I think they have made many fine products over the years in addition to some really bad ones and some very questionable business practices. I do have to respect them for the fact that they never give up. They keep working on a good idea, even if it takes five revisions before their product is succesful. In this post I am only discussing Microsoft's actions in relation to Java. Who knows, had I been in the shoes of a VP trying to grow the desktop market (which is hard with 95% penetration) I might have done similar things.

I'd also like to mention that here I use Java and JVM interchangably. I am more than familiar with the difference between the language, the VM, and the libs that make up the runtime (and dear god, please don't make me explain again the difference between Java and JavaScript. :); but for the purposes of this discussion I will consider them all part of what makes up Java. I think this makes sense for the kind of highlevel issues we are talking about.

The Debate: Open Sourcing Java

A lot of people have been talking about the war of words between Sun, IBM, and related parties on the issue of open sourcing Java. Even James Gosling and the Slashdot crew have gotten in on the act. But what would open sourcing Java actually do? What kind of benefits would we, as a community, get?

As a Java developer, and I'm assuming that most of my audience for this post is a Java developer, I really don't care about the politics of a license. RMS may opine that without a free Java you can't implement a completely free desktop, but I really don't care about an abstract sense of free. I care about what an open source Java would actually mean, and how it would actually affect me. To me it breaks down like this.

The Benefits of Open Source Java:

• Multiple eyeballs fix all bugs
• The ability to fork Java if you want to add new features or fix bugs
• The ability to take Java (non-forked) in new directions that Sun wouldn't think of
• Keeping Java alive if Sun tanks
• The ability to make sure no one else can 'take Java away from us', ala Microsoft's embrace and extend policy

The Problems with Open Source Java:

• Multiple incompatible Javas (both language and environment)
• People from one team not listening to other teams. Standards wars.
• Someone else co-opting the entire system to make it proprietary without a large company to defend it.
• A monoculture of VMs (which is not incompatible with the idea of multiple VMs)

Now, as a developer, I don't care about competing with the Jones' (.NET, perl, C) or about the politics of freeness (RMS). I care about making and deploying great applications, and deploying them everywhere. For this reason I love the advantages of open sourcing Java. It makes Java better and lets me play with it. Still, I really hate the disadvantages. #1 on the list is multiple incompatible environments. The current JVM situation, with multiple revisions and platform specific bugs, is bad enough. Imagine if there were 10 or 20 JVMs out there each with their own idea of what "Java" is. Chaos for the developer. I think this is the number one reason that J2ME has failed. There are too many propriatary extensions and platform incompatibilities to make it easy (or even feasible) to develop J2ME software. I'd hate to see that happen on the desktop or server. That makes my life as a Java developer, (and let's face it, we are the only ones who really care this passionately about a programming language), simply hell. In the end we would still need a validation to ensure that all widely deployed Java environments are compatible, and we'd basically be where we are now, with Sun's compatibility tests and control over the spec, only with more fighting and less work getting done.

So what else do we have here. Multiple eyeballs fix all bugs. Well, you can already download the source and fix a bug if you want to. You can even submit the fix to Sun. You just can't get the fix to your users (or the rest of the world) in a timely manner. This is a problem but one that doesn't require GPL'ing Java. In a world with Open Source Java we could still have these problems. The only solution is an active developer team with an interest in accepting feedback. (more on this down below).

Next up, the ability to add custom features. People have been doing that for years with custom JVMs and compiler extensions. GPLing won't change that. Taking Java in new directions already happens with the JCP. The process may have some problems with infighting and general slowness to decide anything, but open sourcing would mean we'd have even more people bickering about trivial issues. (And if you think that's bad, trying sitting in on a city council meeting sometime.) This would make the problem worse, not better.

Next is the issue of Sun going out of business. I think that Java would be fine without Sun. It's a language, carefully spec'd out, with multiple implementations from many organizations, some with billions of dollars. (Hint. It's a TLA). If Sun went out of business tomorrow we'd be fine. I can't say the same about MFC and Win32.

One really odd issue is the monoculture problem. We could have all JVMs derived from a common source (and why not since it's freely available, and in fact the GPL encourages a single source), so one flaw would affect them all. This is the danger of a monoculture. This is a problem even if we have multiple JVMs with incompatibilites. Having multiple implementations of a single spec helps prevent this. I like the idea that a bug in the Windows VM doesn't necessarily affect the OSX one, just as I like being immune to Outlook viruses by using a different IMAP compatible email client.

Finally, open sourcing, particularly with the GPL, would protect Java from an embrace and extend attack from a hostile company, which pretty much means Microsoft. I don't think that it would since they have already done it twice. The GPL wouldn't have stopped what they did. First was an incompatible JVM. Lawsuits happen, years pass, MS settles, and the damage is already done. The GPL wouldn't change this. Second, MS takes the good ideas of Java and makes their own in the form of C#, adding lots of cool new research. Again, the GPL wouldn't stop that. No license (or contract, or law), will stop a determined foe. Only humans with their own interests can stop other humans. Any license can be powergamed around.

So now we can see that opensourcing Java doesn't solve anything. We have problems, and I'd like to see some changes in the way that Sun handles things, but by and large they do a good job and just GPLing it all would introduce great headaches for very little gain. I urge anyone who thinks otherwise to submit an opposing analysis. This really is an important issue and I'd like to have some frank realworld discussions about it.

As a final note (and I'll stop bugging you, I promise) remember that open source excels at building software where the solution is already known (like most of the Unix utilities we take for granted. No one wants to reimplement grep) or where the advantages of customization out weigh the costs of usability, installation, or integration (like Apache). I think this may apply to some parts of Java but not to others.

So I have one suggestion: I would like to see Sun partially open source parts of Java. Development of new standards and specs are pretty well taken care of by the JCP, but I'd like to see them open up the implementation to Swing (my personal interest). I want them to basically put the whole thing into CVS and start taking patches. Make a few Sun employees the architects and lead product managers. They still make the final decision about what makes it into an official release (JRE 1.6, 1.7, etc), and non official releases can't be sold or distributed as Java, but we'd still the the advantages of faster turnaround, multiple eyeballs, and customized versions for certain situations. This would sort of be like what happens with the Win LAF, (a project created to fix the problems with Swing's built in Windows look and feel), but more official and with the ability to move Swing along faster. There's a large community of people who want to make Swing better (and soon).

Passive Tech on the Ocean

Last week I spent a much needed vacation in The Outer Banks. If you ever see a sticker with OBX in a circle on it, that's the Outer Banks. Beautiful and isolated barrier islands off of the coast of North Carolina, they provide great rest and relaxation. And also the opportunity to think about how technology fits in our lives. I've got lots of new ideas to discuss in my coming entries, but one in particular struck me: Passive technology.

Passive technology is, or at least I'm using it to mean this until I find a better word, technology that acts silently on your behalf. It doesn't require your active attention. It only makes itself known when you ask it to or when something unexpected happens. We have some of this philosophy in our technology now, but we need more.

I came to this realization when my friends and I rode on a boat out to the gulfstream for some tuna fishing. You see it's very quiet out in the ocean. Actually it's very loud. There's the lapping of waves and the roar of a disel engine. Always there and very repetitive. But that's it. Just the two constant noises with the occasional sound from a human. While there is plenty of audible noise the information density is low. I'm not bombarded with hundreds of different systems vying for my attention like I am in normal non-vacation life. It's informationally quiet and simple on the ocean. That's why it's relaxing!

The boat isn't simple though. It was a 65 foot ship with a huge engine, beds, bathroom, kitchen, and a deck specially outfitted with chairs and mount points for more fishing rods than I could count, but everything has it's place. All features of the boat are either designed to be flush with the boat itself or carefully hidden in a specific place. Rods are placed in special fittings built into the hull. All furniture is attached to the floor. All corners are rounded. They even have special cabinet knobs that recess into the smooth door, only popping out when you need to use them.

But back to technology. What we have is a system designed to be unobtrusive because the user can't have any distractions. They always need to be focused on the task at hand: sailing and fishing. Anything else is just overhead. I can only assume that this design is the result of hundreds of years of ocean fishing experience. In a world before GPS and combustion engines these considerations had to be made or people could die. Now that's some human centered design!

So why don't we see more of this in our everyday lives? Technology that just fades into the background, letting the user get on with the real task. Probably because it's expensive and takes time. Quality products always cost more. Better materials and better design simply cost more money and resources. But it also takes time for a solution to evolve. No matter how much money you throw at building the first version of a product it won't be perfect. It has to be refined as people use it in the real world. The first cars were expensive and hard to drive. It wasn't until the standardization of the steering wheel and the invention of the automatic transmission that driving became truly accessible. It takes time for a product to mature into something easy to use. Most of our gadgets are too new to be easy to use.

But what if they weren't? I'd like you all to choose an application you use today and imagine what it will be like with 10 years more development. Don't think about new features but more on how the existing features can become more passive and fade into the background. I'm going to choose email. Please post your ideas and I'll collect them in another column a week from now.

Have fun dreaming on the beach!

- Joshua

Strong vs Weak Typing: Can't we have the best of both worlds?

I've seen lots of arguments on the merits of weak typing. It encourages flexiblity. It lets me write code faster. I don't worry about the details until later. I can do cool runtime tricks.

I don't buy it. I use a strongly typed language because the code it produces is more robust. Typing solves a slew of common programming errors all at once. It ensures that my code will always do exactly what I mean, no more and no less.

And yet... I can see the advantages of weak typing too. Java is a better prototyping language than C++ but it's no where near the speed of Perl for whipping up something quick.

Why do we have strong typing anyway? I can only think of two things. First is performance. If you better specify what you want then the compiler can make faster code. The second is for people. The computer doesn't really care if this string really contains a number. It's all just bits in the end. The typing is for you, the programmer. To help you avoid mistakes. To express what you want the code to do to another programmer. It could be someone using your API, or someone modifying your code, or even yourself hacking on your own code in the future. Typing is a more detailed expression of what you want. But creating that expression can be time consuming and constraining.

But what if we could have the best of both worlds. A language that was both strongly and weakly typed, but at different times. What if I could declare at the top of each module (class, file, or package level?) how much syntatic sugar should be applied.

At it's loosest level you would have:

• no required variable declaration
• foreach, other loop constructs
• dynamic casting
• no required exception handling
• inline regex
• any indentation you want.

At stronger levels (less sugar) you have to declare everything:

• must declare all variables, and at the right location
• only standard looping constructs
• explicit casting
• required exception declaration
• all other syntatic sugar turned off
• Maybe bad indentation and no javadocs would be a compile error too.

Imagine if the forthcoming generics allowed anything to be stuffed in and out of a List in the weak mode and required you to declare the type of List in a stronger mode. Bingo! The ease of Perl with the robustness of Java.

I think such a system would help with three scenarios:

For managing long lived code. We have a pattern of sugar going down as the module stability goes up. Newer code is in flux and tested constantly so it's okay to have the compiler make assumptions. As the code is used more, and more components are dependent on it, we clamp down and explicitly define everything.

It's good for dealing with developers at different skill levels. Developers who's expertise lies in other areas (say graphic designers) do the prototype using sugar mode, not having to worry about the ins and outs of casting and exceptions. Then the real developers refactor it to be more solid if the prototype ends up being used.

You get the benefits of strong typing when you open up old 'hardened' code. Then if you break something you know right away because the compiler is very unforgiving.

The language would scale from prototype stage, through development, and on to deployment and maintenance. As the risk of breakage increases so does the strength of the typing to hold it all together.

This work is licensed under a Creative Commons License.