Showing posts with label Scala. Show all posts
Showing posts with label Scala. Show all posts

Saturday, 13 June 2015

Monads - Asking the Right Question, with Pawel Szulc

On Monday, 1st June, I went to an evening presentation given by Pawel Szulc at Skillmatter regarding Monads in Scala (the videocast of it is here).


It's an obscure subject and not one I really understand, and this presentation didn't help much (too many cognative leaps, like reading a technical book with most of the pages stuck together).

Monads are a kind of contract or pattern, encapsulating a data type in a consistant interface. The interface consists of two functions: a "bind" or "flatMap" function that, given a translation function, allows another monad to be created from the first; and a unit function which creates the monad from the original type in the first place.

Pavel's got a thing about monads and tried to explain how they can be used as a design technique, but I think it's something that going to take a bit more than a presentation to explain. A monograph on the subject, perhaps. Clever bloke, though.

Friday, 14 November 2014

Scaling Business Application Development with Play and Scala

Yesterday evening, I went to see a presentation by Peter Hilton at Skills Matter on using Scala and Play for small-scale development.


In an affable and down-to-earth manner, Peter went through two case studies that his company had handled, both small scale web developments in Holland, where he is based. This is somewhat unusual for Scala in particular and any JVM-based language in general: normally much "lighter" technologies, such as ASP.Net or PHP, are used.

He highlighted the use of a stack of technologies: Play, Scala, Slick (for database connectivity and access), PostgreSQL and MySQL for the database and Bootstrap for the website layout. In particular, he went through the use of Slick, which he recommended, as it has an unusual, more SQL, feel compared to other ORM's.

He also emphasised the speed of development and that the amount of code needed was much smaller than previous applications he'd developed: the first application was ~4000 lines and the second ~2000, which are both a lot smaller than the applications I've worked on. It was interesting to see how his team short-cutted: using social media for security (why not?) and Excel spreadsheet integration for record maintenance.

Overall, it was a good presentation about using Scala in a different way.

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.