Showing posts with label functional programming. Show all posts
Showing posts with label functional programming. Show all posts

Wednesday, 21 August 2013

Wednesday - Lambdas: Myths and Mistakes

This evening I went to see the presentation by Richard Warburton at Skills Matter regarding the new functional features of Java 8, about which I mentioned previously.


A few words of explanation for those not familiar with the terminology.

The JSR mentioned is a Java Specification Request, which is what you create when you have a suggestion for how you want Java to change in the future. These are submitted as part of the Java Community Process, set up by Sun when they realised they had something big on their hands releasing Java. In theory it allows everyone to have a voice, but in practise it's mostly those with very extensive knowledge of the language (such as Richard), although the Adopt-a-JSR he talks about is a move to allow the average code-cutter their ten-penn'th, as well as field testing the resulting change. The JCP has been criticised for slowing down changes to Java which might make it more competitive: Microsoft just releases their software to beta without any real consultation, while Google just seems to keep everything in permanent beta, killing it off when they get tired of it.

The "lazy" and "eager" he talks about are functional concepts that are easier to grasp by watching them in action rather than talking about them, but the nearest non-programming equivalent would be the just-in-time of logistics and manufacturing (a part is ordered to arrive just in time to be used, thus eliminating the need to store it and the resulting cost of doing so). The lazy algorithm is executed when it's needed, whereas the eager one is executed completely. This is why there's a problem when the different algorithms are mixed and why the lazy ones play havoc with profilers (software that tries to work out how efficient your code is, amongst other things).

Richard was quite eloquent, highlighting the changes and giving examples of the way in which they should be used, but it became clear that Java 8 is not the radical change that everyone thought it might be. The functional features, like interfaces and generics before them, look like they've been added onto the existing features and even create conflicts with them (the "streams" and collections Richard talks about).

While it's looking as if they are not going to be usurping Scala and Clojure any time soon, the new features look very Scala-like, which does look a little ominous for the latter. Mind you, they also look a little Erlang-like as well, so make of that what you will.

Bizzare aside: While on the way home on the train, I sat opposite the reddest man I have ever seen. It reminded me of this.

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.

Thursday, 30 December 2010

Seven Languages in Seven, er, Months

A week or so before Christmas, an intriguing book popped up on my recommended list at Amazon. This was Bruce Tate's Seven (Computer) Languages in Seven Weeks (ISBN 193435659X). The idea behind the book is to teach certain programming concepts through the medium of the languages that embody them the best. Object orientation and dynamic typing are taught using Ruby, a language in which Tate does most of his work; prototyping, which I'm not very familiar with, is demonstrated through Io, a language I'd never even heard of before; functional programming is through Haskell; concurrency (using actors not threads!?!) through Erlang, and so on. There is also a chapter on Scala, which I've had some experience of, so I'm intrigued to see what he has to say about that.