Showing posts with label Sun Microsystems. Show all posts
Showing posts with label Sun Microsystems. Show all posts

Tuesday, 23 July 2013

Real World Comparison of Scala and Clojure

Tonight, I attended a presentation by Robert Rees (the podcast available here), from the Guardian Newspaper group, comparing his experiences with both Scala (which is being rapidly adopted by the Guardian, along with MongoDB, to replace their Java/Oracle technology base by the years' end) and it's functional competitor Clojure.


I'll just write a little bit of context for those who aren't too familiar with what all the fuss is about.

Usually, when you make a piece of software that runs on an operating system, such as, say, Windows or Android, you have two pieces of software, a compiler and a linker, that turn the code into an executable, which you can then run. Most pieces of software are done like this, from my noddy little exercises in C for college up to Microsoft's Office suite. About fifteen years ago, a group of programmers at Sun Microsystems, in the U.S., came up with the idea that you can separate the executable into two halves: the first bit would be the specific code to do a particular job and the second bit to be more general that would manage the communication between the specific bit and the operating system (the idea wasn't theirs, exactly, but the way they were going to use it was). This bit, or layer, was called a "virtual machine" and it could be re-written for any operating system in such a way that the specific program could be run on any virtual machine without having to be re-compiled, what Sun called "compile once, run anywhere". Thus the Java Language and the Java Virtual Machine (JVM) were created. The Java compiler produces something called "bytecode", a sort of half-way house between code and executable, that can be run by the JVM. In theory (although not an idea immediately taken up by Sun) any language, not just Java, can be turned into byte code by a suitable compiler to be run by the JVM. Unfortunately, Sun jealously guard the definition of byte code, which is the interface to the JVM and how it works, so that no-one can produce another language which runs on the JVM (and can compete with Java, and Sun), unless Sun say so. The same also goes for the JVM itself, thus the first JVM for Linux was made by Sun, not the open-source community.

Skip a few years and up come Microsoft. They've adopted the same idea a few years earlier for their Visual Basic language, but it's not particularly well done. They have a word with Sun about creating a version of Java for Windows. Sun say "ok, but we're watching you!!" (Microsoft being a large corporation with a somewhat mixed reputation, both technically and commercially). Microsoft create their own version of Java, called J++, and a virtual machine to match, but there's a few cross word from Sun (in the form of a legal suit) as they don't like what they see (surprise, surprise). In the fallout, Microsoft create .Net, which is their collective name for both the new Windows virtual machine, the code libraries that go with it, and a load of related (and, some might say, unrelated) technologies. The .Net "VM", called the Common Language Runtime (CLR), is so optimised for Windows, and so pervasive, that almost every executable on Windows now has to use it. Microsoft, like Sun before it, also produced a Java-like (and improved) language, C#, as well as adapting Visual Basic and Visual C++ for use with this new technology.

"OK", says you, "but what's this got to do with Scala and Clojure?". Well, one of the things that Microsoft did is open up the .Net interfaces and, in particular, the definition of the .Net byte code, called Common Intermediate Language (CIL). This means that anybody with sufficient skill can implement a .Net compatible language compiler. This didn't have much of an impact, at first, but in reaction, Sun decided to go one further and open-source most (but not all) of the JVM, an almost complete reversal of the previous policy. It's a bit baffling as to why, but Sun were having financial problems at the time and were subsequently taken over by Oracle, so it might have been something to do with that. Anyway, this openness means that, like .Net, people with sufficient skill can produce new languages for the JVM, and this is what Scala and Clojure are.

Both Languages implement functional programming, but Scala implements both functional programming ideas and object oriented ideas, like those in Java, C++, C# and Delphi. Clojure, on the other hand, is an implementation of Lisp, a mathematics-based language using something called Lambda calculus (invented by Alonzo Church and the basis for functional programming) and one of the oldest programming languages.

Robert's presentation, done in a friendly and relaxed style, took us through the two languages and compared their various features. Although he seemed to prefer Clojure, he admitted that it had some problems which might be difficult to overcome in an environment where Java, or a similar language such as C#, was established. In that case, Scala might be more easily adopted, despite it's more compromised implementation of functional programming.

However, he also highlighted the future release of Java 8, which is puported to have Lambda extensions, and might make adopting Scala or Clojure moot. Also interesting was his theory that if Microsoft implemented similar features in C#, F#, it's functional programming language, would similarly be redundant.

Saturday, 21 August 2010

Java and C#

A recent conversation reminded me of the debate about Java and C#. The subject is not as clear cut as might appear and there are things to consider beyond the purely technical reasons for using either.

Java's Age

Java has been around for a while now, since 1995, and was one of the first major commercial object-oriented languages designed as such. C# is relatively new, released in 2002, and has features, such as reflection, that have been invented since Java was released. Java has either only partially included these new features or not at all. The reason for this conservatism in language design is that Sun has been focused on backward compatibility, even at the byte code level, and has been reluctant to implement new features that break this. Microsoft has had a reputation for being somewhat careless about backward compatibility, although this has changed somewhat as they've tried to promote .Net as an open standard.

Java's age, however, is also a head-start and there are many application frameworks and tool suites for Java, such as Spring, Hibernate, and the Apache Jakarta project, which are very mature. C#, or rather .Net, equivalents are only just starting to develop, and some of those that exist are actually ports of Java systems, such as Spring.Net and NHibernate.

Web Enabled

From the start, .Net has been designed for use in web applications. The effect of .Net on ASP, for example, has been almost revolutionary. In particular, .Net has libraries which make the development of web services and SOA much easier than before. Java, on the other hand, has had web services introduced retrospectively, through changes to J2EE and frameworks like Spring and languages like JSP.

UI Applications

Like web applications, .Net has been geared up to produce Windows applications right from the start, although not to the degree that Delphi has. Java has the Swing library, which, although cross-platform, produces very poor applications. It may be worth noting, however, that Vuze, one of the most popular bittorrent clients, is implemented in Java.

Cross Platform

From the start, Java was designed to be cross-platform. The Java slogan has always been, "build once, run anywhere" and Java applications can be built on a Linux box and run on Windows. .Net applications can only be run on Windows and .Net web applications only on IIS, Microsoft's web server. There are ports of .Net to other platforms, such as Mono, but these are not compatible with .Net to in the same way that different implementations of Java are.

The cross-platform limitation of .Net also makes it easier to take advantage of features only available in Windows and nowhere else. This is particularly true of Windows applications.

Politics

Java has evolved in a very open culture at Sun, Java going open source in 2007. Even though Sun held the licences to Java, it included interested groups in it's decision making process, what Sun called the Java Community Process. This is probably because the focus at Sun was hardware, which is where it made the bulk of it's money, rather than software. With the buyout of Sun by Oracle, this may change as Oracle are a software vendor, like Microsoft, although not development tools.

In contrast, .Net is very proprietary. Microsoft have not developed a port for .Net to Linux, for example, because of the licencing problems involved with the GPL and because Microsoft has no control over the development of the Linux operating system. In other words, if you want to use .Net, you are stuck with Windows and Microsoft. In anti-pattern terms, this is known as "vendor lock-in".

Conclusion

The choice between .Net and Java is not an easy one. There are a lot of technical factors to be considered, as well as the one's I've listed above. I tend to go for Java, but this is based on the cross-platform nature of Java, in addition to it's maturity and the vendor lock-in aspect. There are good arguments for .Net, however, including Microsoft's considerable support for it for the for the foreseeable future, and it's close relation with the Windows operating system. It also depends on the nature of the work being done. If it's going to be mostly Windows applications, then .Net is the obvious choice. With web applications, it's more complex, but, again, if it's going to be based on Windows, .Net seems to be the right choice. There are other choices than .Net and Java for the web, however, Ruby and PHP for example.

Another consideration is how much is it going to cost to move to these development languages from wherever you are now. Java and C# are syntactically very similar (the claim that C# is a clone of Java has some truth), so the jump from, say, Delphi or Visual Basic, would be the same to some extent.

A good idea is to look at other companies and see the choices they made, but understanding why they made those choices. For example, why do Google use C++, Java and Python, especially Python? Wikipedia is made using PHP, which is also cross-platform independent.

And, of course, the worst choice is one made from blind ignorance.