 So, I think we can start. Thanks for coming. I'm Martin Rezky. I'm from EPFL in Lausanne. That's the logo down here. And I have been working for the last five years or so on basically nothing else but the Scala language about that is this talk today. So I'm here to tell you a bit about what it is, what you can do with it, and what its design philosophy is, how it's different from other programming languages. So if you look at the software landscape today, then I think it resembles more and more a Tower of Babel with many little or sometimes not so little languages playing together more or less well. So a typical setup would be that you have, say, JavaScript in the browser on the client and you would have some language for server-side scripting, Perl, Python, Ruby, Groovy, whatever. If you're in a Java environment, maybe you have Java FX for the UI that's still very new, but it fills out its niche there. You would have maybe Java for the business logic or something else, C Sharp, C++, whatever, SQL for database access. And then you'll need to cobble all this together with usually a generous helping of XML configuration files and so on. So that's the situation today and it's both good and bad. So the good part of it is that with all these little languages, each one can specialize on what it does best. You can have really specialized tools for these things. The bad part comes when you have to do a large amount of cross-language communication because that tends to be complicated, in particular for deployment, tends to be fragile, and it tends to be a large source of misunderstandings if the conventions in these languages don't quite play well together. And the underlying, or one of the underlying problems with this is that usually for languages, you have type systems, quite strong type systems, either static or dynamic ones, but type systems that catch you out. Normally when you do cross-language communication, you don't have that anymore. Instead, you communicate with very conceptually very low-level things, such as XML trees or even strings, and then typically that's where the arrows creep in. So it's a major hassle. So the alternative would be to say, well, let's look at languages that are more scalable, so that are more suitable for both very small as well as very large programs. And the idea would be to have a single language in which you can do the heavy lifting on the one side and the extension scripts on the other side. So if you have specific needs in your application, then instead of an external domain-specific language or a scripting language, you would create an internal or hosted domain-specific language which is implemented just as a library in your host language. And the requirement for that then is that your host language is very, very expressive that it can do these things. So in Scala, we've shown that this approach is in fact possible. So one way to look at Scala is to say, well, it's a scripting language. In fact, it has an interactive read-eval print loop. You can infer the types and you don't have a lot of boilerplate. So that's a typical setup of a Scala script. You have a Scala prompt. Wow. Just to show that this is real. Let's just go through one. Oops, no, it goes where? Why does it go away? Yeah, where I do it. Sorry, I should have set this up before. Here we have on the lower part, we have our Scala interpreter and I could, for instance, just write one plus two or I could say list of one, two, three, for each map plus one. And that gives me a list, which is two, two, three, four. So I can just interact with these things interactively with a redeval print loop like what I used to from a scripting language. And that's just another script here. Another way to look at Scala is to say, well, it's the Java of the future. It has basically everything Java has now, sometimes in a slightly different form, but it's there. It has closures, which have been proposed by many for Java 7, but in the end rejected for Java 7. It has things called traits and pattern matching. I'll tell you a little bit about that later. And I wouldn't be surprised to see them. These features in Java 8, 9 or 10. It compiles to dot class files just like Java does. It's completely interoperable and it's about as fast as Java. So if you switch from Java to Scala in your application, typically you won't see any difference in execution speed. It's sort of the same things. So here you see a typical Scala program, which highlights some of the things that are the same and also some of the differences. You have an application, it's called Object App, and it has a main method, much like Java has a main method. And then it's not just a Hello World program because that would be too trivial, but it's the next simplest program. So I guess don't know whether you can read that. So it asks whether in our argument array there is an argument such that the lower, if you convert the argument to lower case, it reads help. So it looks for arguments where the user wrote help in either upper case or lower case, and if that's the case, then it will print the usage and otherwise it will process the arguments. So that just shows you how something very Java-like, a main method arrays goes together with something like here, which is in the end very functional. So you don't go through the loop step by step with an index, you just ask the whole array whether there exists something which satisfies a given predicate, and this predicate here, which is given in these parents, that's a function that's treated as a first class function in Java, and the parameter of that function that goes here where the underscore is. So you say the parameter, you slot every argument into this parameter, you ask, convert it to lower case, ask is it equal to help, if yes, then we have a match and the exists method here will return the result. Okay, so to look at interoperability, the whole thing fits seamlessly into a Java environment. You can call Java methods, select Java fields, inherit Java classes, implement interfaces, and so on, and so on. That's virtually nothing that doesn't work completely without any protocol. So you don't need any glue code, interface, description, nothing. In the end, a Scala program or Scala application is just another Java library. It combines, it compiles into class files, it gets deployed as jars, and at the runtime there's virtually no difference between the two. And for all that reason, it's also the case that the performance is usually on a par with Java. Okay, yet another way to look at it is to say Scala is a language for programming in the large software architecture language or composition language. In fact, it embodies a completely new approach to the modularity problem, to module systems. So in Scala, a component is a class, or a trait, a trait is something in between a class and an interface. You can mix several traits together, and the composition is done with this mixing composition. And you have very powerful ways to abstract, to hide details through parameters, through abstract members, and through self-types. And all this gives you something for which nowadays you need tools, dependency injection tools like Spring, you could say that's already embodied in the language. It lets you do the same thing already in the language without actually having to do additional configuration files or frameworks or whatever. So you might ask with all that, don't you get a huge language, a kitchen sink language that includes everything? I mean, if you go from scripting to architecture description. And in fact, we have worked very, very hard that this is not the case. So in terms of feature counts, Scala is roughly comparable to today's Java, I would say, and it's certainly smaller than C-sharp or certainly much, much smaller than C++. The difference is that where other languages are broad, that means they have many different features side by side, we try to go deep. That means we try to concentrate on ways to give you new ways to abstract and compose so that you can create the things you want yourself rather than relying on what's already there as primitives in the language. And the other principle that helped us keep the language reasonably small even though the application error is huge is that we from the start decided we would have the same sort of constructs work for very small as well as work for very large programs. So it's all objects from a single line program to a million line system. It's all expressed as simple objects. There's no further layers of modules or packages or whatnot. So if you compare Scala to Java, then what we add is a pure module system. So everything is an object, operator overloading. So operators are just method calls. We add closures that comes from the functional side. We add new form of composition which is called mixing composition which is essentially a modern form of multiple inheritance. So it's more general than the single inheritance plus interfaces that you see in Java or .NET. And we add on the type side interesting things like existential types, abstract types, and we add pattern matching. That's quite a list. But on the other hand, we also remove quite a list from the things that you see in Java. Not so much that we are against them but typically because there are other ways to do the equivalent things in Scala. So we don't have static members of classes. They're a big source of headaches. We don't have primitive types. They're all objects. We don't have break and continue in loops. I'll show you how to get them back later. We don't treat interfaces specially. They're just traits, simple traits. We don't need wildcards. We can model them in a more correct way with existentials. And we don't have raw types and enums. Enums are among the several other things that are modeled in Scala libraries. So the libraries take up a lot of the slack of what's not in the language. And that's possible because the language is much more flexible and malleable so that you can in fact write these libraries and have them used in a pleasant way from your users. So now I should really tell you, well, who has already seen or written some Java code? Scala code, sorry. Oh, okay. Quite a few. Written, who's written? Oh, much fewer. Okay, so for those who haven't seen anything, I just take you through a little cheat sheet to just tell you how to read some Scala. How is it different? So first thing here is you have a method definition. On the right side, you have the Java one. And on the left hand, you have the Scala one. So you see that there's a special keyword called def which starts a method. The parameters, the type of the parameter is reversed. So it's x colon int instead of int x. And you don't need to have a return instead. Every expression on the right hand side, the last expression of the statements on the right hand side is automatically returned as a result. And there's a slight right form of functions that don't take any parameter at all. That's this one here where you just write a function that when you mention the name fun, it will compute result for you every time you do that. Variable definitions, so that's the Java form int x equals expression. In Scala, you write var x colon int equals expression. And if you want it to be immutable, which is the functional way, then you write var instead of var. So that means you have a variable that you will not assign to later on. The initial value is also the final value of that variable. So that would correspond in Java to final string x equals expression. Yes. You mentioned type inference. Yes. I can, no, I can, yes. Repeat the question. Yeah, okay. The question is with type inference, maybe I take it, I get to type inference later on. So there was a question, what does type inference do here? And I'm gonna take that up later on in the slides. Okay, so if you go through the cheat sheet further on with the expressions, so a method call looks basically in exactly the same way as in Java. So you write object.method of some arguments. There's a shorthand in Scala which lets you drop the dot and the parents. You can just write object method argument and that means the same thing. It's also a method call, but the method is used there as an infix operator. The conditional expressions, there's the if and else very much like in Java, but because in Scala every statement is an expression, we only need one if. So in Java you need two ifs, that one for expression and that one for statements in Scala. You use the same if for both expressions and statements. Instead of the switch, you have a match here, but in fact the capabilities of the match are basically more powerful than the switch. We'll get to that because it lets you do general pattern matching, not just test on some simple constants. If you look at objects and classes, so that's the typical thing. You would write a class in Java. You write class sample and then you introduce for instance here a private field and a public field P and then you need a constructor that initializes these fields and there you have two methods, one instance and one static. So on the left-hand side, on the Scala side, you see the exactly equivalent program, so which is much shorter. It's much shorter because instead of writing a separate constructor, you can write the parameters of the constructor directly behind the class. It goes here on top. And the instant method goes into the class. There are no statics, but instead of statics, you have a separate object. An object is basically just a class that is already pre-allocated for you exactly once. So in this object sample, you say you put the static method and that then becomes an instance method of this object. So in that way, Scala is much purer because it sets its objects all the way down and it doesn't have this idea of static members which is really not an object-oriented concept at all. Okay, finally traits. So on the right-hand side, you have an Java interface. It has abstract methods only. You can do the same thing in Scala. In a Scala trait, you can write abstract methods, but you can also add concrete methods. You can give them some implementations that then are inherited and you can even define fields like down here. And instead of having an interface implementation like that in Java, you just write in Scala class C extends and then you have what we call mixing composition. You take the superclass and all the traits and you mix them in together with this keyword. So overall, it feels like a cleaned up Java a little bit. The syntax is usually much more light white and concise. In my experience, if you don't change the program a lot, you will still get a reduction lines of code of about two. And that's due to the fact that we infer a lot of things. We infer most trivially semicolons at the end of lines are optional in Scala. We infer a lot of types. Our class syntax is more light white and then you can make use of extensible APIs, closures as control abstractions and so on. So it feels like a cleaned up Java, but with one major difference and that's that we write x colon int instead of int x. And that's actually what I've been most criticized on by overall why do you insist on writing x colon x instead of int x? It would be so much easier if you didn't do this. So we must have very good reasons to do it. And in fact, we didn't really do this just out of a whim to say, well, we just like it better. So there are two reasons for this. The first one is that quite often in fact, usually in Scala, you will not write the type int at all. You will just write var x equals zero and the Scala compiler will infer the type for you. And this type inference is a bit limited so it's done in a local way. So from the right-hand side, from the type of the expression, it will figure out that the zero is of type int so there's no need to declare the variable x with the same type int explicitly. The compiler can figure that out. So that's the first reason. And the second reason is that I think this prefix type int x syntax, that worked great in the days of early C and it stopped working so great afterwards. So in the days of early C, most of your types were ints, floats, structs. That was about it, right? So in that sense you could say, well, int, it's great. It already gives you the type of a variable. No noise, no fuss, nothing. No, you don't need another keyword. But nowadays our types have gotten much bigger and much more complicated, more complicated than that and they have gotten much more user definable. So you wouldn't write often int but you would write something like public final hash map string of pair of string of list of car, blah, blah, blah, x and then you say, okay, you have to parse all this to get to the really important thing, namely what is the variable you're defining here. Maybe you're not even interested in the type at this moment, you're just interested in the name. So I think this syntax, the traditional C style syntax has outrun its usefulness when we have types like this. Whereas over here you write val x. So that tells you what, so it tells you well it's a value you're defining, x tells you it's x you're defining and then this thing here you might often even infer. Maybe you don't need to write it all and if you write it it comes third because it's third as important as the other things and not the most important thing. Okay, so if you want to be scalable then one of the important things is to be extensible as a language. So why is that so? Well it's because we don't foresee everything that users want to do with our languages. Every user has different demands and different ideas what they want to do. So one example of that very concrete is numeric data types. So in today's languages you have int, long, float, double. Question is should we also support big ins? Well they're very useful, very applications that absolutely demand big ins. How would you do cryptography without? Big decimal, business wants big decimal. How can they count all the pennies and cents? Complex numbers, physicists absolutely require complex. Rational, interval, polynomial, they all have really important usages. But if you had a language that combined all these as numeric types in the language it would be really huge. So what do you do? You, the alternative of course is to let the users grow the language according to what they need. So here's an example of what you can write in Scala. If you have the type big int, then you write a factorial like this. That's the way you would write factorial. Big int is not a type that's primitive in Scala. It's that somebody had defined in a library. If it hadn't been in a library you could define it yourself, everybody. There's no special magic to big int whatsoever. So you could say well, defining new types that's old, old hat, right? Every language can do that, in particular object oriented languages. So of course in Java you can also define big int. In fact it has been defined. It's called java.math.biginteger. But to interact with it you have to write that. So you write factorial of this big integer and then you have to test. So that's the very same factorial function. It clearly doesn't look like you're interacting with a built-in type, right? It's completely different whether you add, you interact with something that's in the language or outside the language. So the question is how in Scala you achieve this syntactic elegance and brevity. So here's how we do it. So that's an excerpt of the class of the class big int which is in the Scala library. So it actually, it doesn't do much. It uses Java for most of what it does. It imports the Java big integer. And here you define the class big int. To get a Scala big int, sorry, you essentially wrap a Java big integer. And then in the class big int you have methods that are called plus and minus and so on. Remember from a couple slides back, the alternative method syntax that you could write receiver method argument. Well, here you can write X minus one. That's an instance of that. X is the receiver, minus is the method, one is the argument. So the only thing that we needed to do that is to say, well, you can have a method whose name is plus. Plus is a legal method name. And in fact, it is in Scala. So that's not a big deal. So that means that infix operations like A plus B is the same as A dot plus B. Or here, I just played on that to say, you can of course do that also when you call Java methods. So here the add method, that's a Java operation on big integer, but you use infix syntax on that just to show you that it's possible. Yes, there was a question. Yeah, very good. Very, very well observed. Yes. So what do we do then? So we could do two things. So the first one is we can give you an overloaded version of plus with integer only. That works for X plus one, but it doesn't work for one plus X. That's the harder part. Because if you say one plus X, you invoke the plus method on the integer one with a big int argument. So then you really have a problem. There's something called an implicit conversion in Scala. So you can define your own conversions and the compiler will apply them when necessary to make these things work. I don't, didn't want to go into that because it goes a bit too deeply, but that's essentially how it's done this. An implicit, together with big integer, you define an implicit conversion from integer to big integer. Okay, so that's data types. What about control structures? So a new line, if you want to extend your language with new control structures also, I guess. So here's an example of what's also been proposed for Java 7, a sort of using construct where you say, okay, I want to have a resource, in this case, a buffered reader, and I want to use that. That means I want to open it and do something with it and then close it automatically. So that I can't, the idea of this construct is that users shouldn't fall into the trap to forget to close it. In fact, the closing, so that's the previous idiom where you say you open it, you do your creative resource, then you do something with it, and then you have a try finally, which catches, under all, every eventuality, will say, well, if this thing is not now, then close it in the end, this sort of thing. So that's nice, and in Java it has been proposed as a syntax addition to something to add to the Java 7 language. But of course, there's no reason for that if you can do it yourself in the libraries. So here's how you would do it in Scala. You would have, using would be a method, a def, and what would it do? Well, what the code block is was virtually the same thing as before, only before you dealt with a file F, now you're dealing with an abstract resource which could be almost anything. So you invoke a block of operations on a resource and then finally, if the resource is not now, you close it. But let's have a look at the signature of using here. So using the first thing it has to do is it has to take a type parameter to say, well, this thing should be general, it shouldn't just work with files, it should also work for other kinds of resources that have closed methods. So the T here is a type parameter, which says it works for any type. If you know Java generics or C++ templates, then it's the same thing as they, only that we write angle brackets where they write sharp brackets, but otherwise it's the same thing. Now we write brackets where they write angle brackets, sorry. Okay, so T is a type parameter. And then we have to say, well, we have to know something about T. So what we know here is that T must support a closed method. It must be a type that has a closed method. So that's the second approach. And then our resource that we deal with, that must be of type T. And then the block that we, that's the block of operations, that's now a closure, that's a function that takes the T, that operates on the T, and in this case it just returns a unit. Unit is for Scala is the same thing as void in Java, so it's a block that doesn't really return an interesting result. So that's how you do it. So now let me get back to break and continue. So break and continue, they were in our list of missing features from Java and Scala doesn't have them. So why did we drop break and continue? Well, originally we dropped break and continue because we say they're a bit imperative. Typically you'd need to break and continue to get out of a very tangled control structure. In function, if you have a more functional programming style, then typically you don't do that. You have many more, smaller functions and the need for break and continue is much reduced. There was also an issue how they interact with closures. What if you break out of something which is really a call of a closure? But finally, the answer is they're not really needed because you can do break and continue perfectly well with just libraries. So here's what you now would do. In fact, so you would import something from a class called Scala, you till control breaks and then instead of breaking out just of a loop, you make it just explicit. You say that's the limit where you break out. So you have another construct called breakable. That's where you break out from and then you write whatever. So here's a loop, a for loop and then here you have your break which then if you invoke the break it would break out of the scope here. So how is that done? So here's the implementation of, well it isn't the Scala standard libraries from the next version on 2.8 but you see it's no big deal. If you need break and continue, now just write these couple of lines and you have them. So what you do is there was this breaks object, that's what this defines. It defines an exception called break exception and it immediately allocates the exception in a value called lowercase break exception. And now breakable, that was the breakable operation. Breakable is just a method and what it takes is this block which here is called OP for operation. That's just a block of things so which in the end will give you a unit but it will do some computation before it gives you that and then what you do is you have another try of the you execute the block. If you catch a break exception during it then you will just stop the whole thing and you will exit the breakable. So break then is just a throw break exception and that's all, yes? Good point, good point, yeah. Very good point, you could say it's very heavy. This break is very heavy. It throws an exception, isn't that slow? And there's one trick to it. If I had written here, break throw new break exception, you would be absolutely right but that's not what I have done. I have done a private private while break exception equals new break exception. So the stack that gets captured by break exception gets captured at the very beginning of the program and the program starts up. It's a completely uninteresting stack. It's a stack when this object breaks was initialized and it turns out that John Rose told me and he also wrote a blog about that, that modern VMs they can optimize this thing so much away that they turn this thing into a jump which is quite amazing. So our friends at Sun really have helped us out there and have made their own language constructs more redundant because now you can actually implement them with this trick with exceptions. Okay, so question is what, if we look now at the Scala design, what is the root of the scalability? And I think there are many factors, the strong typing, there's inference, which means you don't get weighed down by a whole mass of type annotations that you have to write. There's generally the emphasis on having as little boilerplate to make the job as easy as possible but I think the main design parts is a very, very tight integration of functional and object-oriented programming. And the observation is that they have very different strengths and weaknesses also. So in functional programming, it's very easy to build interesting things from simple parts using a lot of combinator things which let you put things together like higher order functions, algebraic types and parametring, parametric polymorphism. Object-oriented programming on the other hand, that shines when you have a big, clunky, complex system and now you wanna turn a screw here and change that a little bit. So because it lets you go in there with subtyping and inheritance, dynamic configurations, and all the tools to do code reuse in a very, very good way. So object-oriented programming is very good for maintaining, improving, evolving existing systems whereas functional programming is very, very good for doing something very quickly and very high level. And the challenge is of course how to put them, put the two together. It would always be easy to just have say well let's throw the functional parts here and just add the object-oriented parts as well and then we, but then you end up with a language that sort of is modal. You say well you program functionally or object-oriented, you can never program with the two at the same time. You can never program both. So the challenge is how can you program both functional and object-oriented in the same program or in the same lines? Okay, so from the object-oriented side is, Scala is a purely object-oriented language so every value is an object. That's what's usually required there. Every operation is a method calls and there are no exceptions to these rules. The exceptions that you find in Java such as primitive type statics, they are eliminated. So just to do the point, if I take the hash code of the number one then indeed I do get a hash code. In Java that would be a type error because it says one is not an object on which you can invoke a method. Underneath the covers of course we implement this thing with the same 32-bit integers that Java does. We have to do it for both interoperability and performance but on the programmer side the programmer doesn't see that. That's sort of a trick the compiler pulls on the programmer. On the other hand Scala is a functional language. Functional in the sense, not in, well essentially there are two definitions of functional. One is sort of the bondage discipline which says that functions, functionally program functionally only if you don't use side effects or assignments. So functional programming means I outlaw any sort of assignment or side effects. The more positive approach is to say functional programming is a language that recognizes the power of functions as first class objects and that emphasizes the power of functions. And in that sense Scala is a functional language in the second more embracing style. So it has a very rich ways to express functions. You can have anomalous functions, you can have curing, you can nest functions, you can do with functions whatever you can do with other things and the library makes a lot of use of that and in fact it does a very hard job to even dress up the old tired imperative Java data types as shiny new functional things. So here you have an array of array of int and with Java arrays you can't really do much, you can take length and you can index but here you can use here all these operations, you can say does in the matrix exist a row such that for all elements of the row the element is equal to zero. So in one line you ask whether this two dimensional matrix has a row that consists of all zeros and that's a very functional approach that you can do these things. So what we do is again with implicit conversion magic we inject these exists and for all's into the array classes so that we dress them up there. Okay, so now you could say if functions are values and values are objects it must be that the functions themselves are objects, right? And that's true. So indeed if you have a function type S arrow T that's just an abbreviation for an object type which is a class scar dot function one of S and T. So it's a class with two parameters for the argument type and the result type and here you see this class well it's actually a trait. So function one it takes the S and T parameters and it has the apply method. If you wonder what this minus and plus is it tells you how the type parameter varies with the with the with subtyping. It's covariant for this one and contra variant for the other one. If you don't know what that means don't worry. It's not important here. So here would be a concrete function in that case here we have an anonymous function. So a very simple one that takes an inch X and returns X plus one. So that's this function and it would be translated into now a Java anonymous class which gives you a new instance of this trait and with an application with an implementation of the apply method. So here we take the X and it returns X plus one. So that's what it does. Okay, you could say, well that's nice. You have compiled out functions but why should users care? Well, the idea is that since functions are classes they can be subclassed. That's something you have on the object oriented side. Not on the functional side. On functional programming a function is a function is a function. You can't ever add anything to a function. Once you treat functions as objects you can do it. So why would you want to add something to functions? Well, one example is just arrays. An array is if you come to think of it is nothing but a function from ints, some subrange of the integers to whatever the element type of the array is. Only that arrays of course have more things than functions because you can take the length of an array. You can update the array. So they are functions that you can mutate. You can change the functions and then if they are proper good arrays they also have all these useful methods like elements and exists and for alls that we have seen in the matrix example. And that's the way Scala treats arrays. So instead of array subscripting we have this apply method here. And when we write here, no actually I don't write it here. When you write here a of i equals a of i plus two then Scala will translate that into saying well that's the invocation of the apply method on my function. That's an invocation of the update method of my function and then the rest is just the implementation of these methods. So why is that useful? It's useful because it's not restricted to just arrays. Whenever the Scala compiler sees this syntax it will translate it into applications of the apply and update method. That means you define apply and update for your collection libraries, hash tables or something you get exactly the same syntax. So it's not something that is restricted to a primitive type, it's available for all library abstractions. Okay, another useful thing are partial functions. So now I have to probably switch a big, I think I have 10 more minutes so I'll speed up a little bit. I got more than 10 minutes, excellent. Okay, so I slow down. So partial functions, they are functions that are a bit less common than arrays. They have a new method which is called is defined at. So that's methods, that's functions where you can, that are not defined on all their domain. But what's more is you can find out whether they are defined or not using this method. And what Scala does is it treats block of pattern matching cases as instances of that. So we'll see an example very quickly. So what this gives us is a way to develop completely new paradigms of programming. So as an example here, I develop concurrent programming. Since Java and Scala are interoperable, of course, we could use the Java threads and we do. We use Java threads, we use the modern concurrent libraries by Daglea, a lot of that. And that works well, but it's concurrent programming on a very low level of abstraction. So if you want to be safer, if you want to write concurrent programs simpler, then you need to do something else. So threads are very, very error prone. So one example that we have done and that people use a lot is programming with Actors. Actors is a much safer way to deal with the concurrency because instead of shared memory where your threads all go to the same memory and then you have a problem how to lock some part of the memory so that only one thread can see it at a time, you communicate with messages. So it's message passing concurrency which is generally seen on a much higher level. We're not the first one to have made that observation. There's a language Erlang which exists for more than 20 years which has pioneered this in the programming language camp and which is nowadays quite popular for massively concurrent applications. So in Erlang there are two principle constructs and we have adopted both of them in Scala or in the Scala libraries I should say, you can send a message to an actor that's the previous one and to send is asynchronous. That means you send off the message and then you do other things and the message will be buffered in the mailbox and when the receiving actor is ready, it will process it. And there's receive them which is of this form so it is a number of cases so likely what you would have in a switch but instead of just a constant you have an arbitrary pattern here, a message pattern. So receive picks the first message in its mailbox that matches some of the patterns and then acts on this message. So here's an example of an actor. Check some calculator. Check some calculator, that's an actor. So actor is in this scope from here to here so it keeps a local field called sum, a local variable sum and then it goes through a loop and it receives messages which are of these two forms, data, sorry a data message sends a number of bytes and the sum message demands that the sum is computed and returned to another actor which is called the receiver here, this one here. So the loop, what the loop does is it receives messages if the message is a data message with some bytes BS then it just computes the hash of BS and adds to sum if the message is a sum with a given receiver then it will send the current value of sum back to receiver just as an example to show how these things work. Okay, so now if you have seen, if you have followed the code examples here they are syntax highlighted so whatever is a keyword is in gray and the other stuff is in this dark blue. There's not a big difference in color but I think you can see that receive is not gray, it's not a keyword, loop is not gray either and actor is not gray either. Neither of these things are gray that means they are all defined just as normal methods in the libraries. So you might say, well, how is receive defined? How can you do such a thing that does pattern matching and all these things, so here's how it is defined. So what does receive do? Well, if we look at its usage it takes a pattern matching block from here to here and that's modeled as a partial function. How is it a partial function? Well, something comes in, it gets matched by the patterns if a pattern matches then it will return a result. So in that sense it's a function but it's a partial function because some patterns might not match and if a pattern might not match then the function won't return anything and what's more you can find out from the function whether it can return something or not. The Scala compiler will compile these pattern matching blocks in this form. So what receive then needs to do is this one. It takes this partial function which is our pattern matching block. The partial function takes a message and gives you back some type T which in this example here is again open. You can instantiate it to any type you like and then it has to look currently in the currently executing actor. So that's the self. It looks in its mailbox. So that's the queue of incoming messages and it extracts the first message of this queue which satisfies a given predicate. So extract first, that's just a method on our queues which given a predicate, a Boolean function gives you the first element in the queue for which the Boolean function is true. So what is the Boolean function that we are looking after? Well, it's just if F is defined at. So if my pattern matching block is defined on the message I can handle it and I should do so. If it's not defined on the message I skip to the next message and I try this one. So here you have a very interesting example of something that you couldn't do if you were either object oriented or functional. You can't do it in object oriented programming because you don't have pattern matching, you can't deal with these functions. It's impossible. People claim that they have done Ellen style actors but every time you look at the actual implementation it's incredibly clumsy syntactically. It's not the same, not at all the same of this elegance of pattern matching that you find in Ellen. People can't do it in functional languages either because a function is a function is a function. You can't have special sort of functions like partial functions and those we need here for the dispatch. So you can't add further stuff to functions. You really need both concepts, functions and the ability to treat functions as classes and to subclass them. So that is sort of the added value that you get from that. Okay, so if we look at other approaches to scalability, I think C++ is a fairly scalable language, at least upwards. You can go into strato spheres of abstractions and complexities, it's very impressive. But on the other hand, you lose a lot of your people. The higher you go, the more expert you need to be. So if you can write boost library stuff you have to be pretty good. Scaling down is much harder for C++. .NET has the idea that you have many languages and they're interoperable. So that's by itself, it's a very, very interesting idea to say, well, let's concentrate on the glue, the interoperation and have many different languages. But on the other hand, the problem is the .NET language format really determines a lot what you can do. So in a sense, most .NET languages are very similar to each other, at least in what they do for the objects. And then Java, well, Java is sort of the lingua franca that makes it very easy to understand other people's code, but it's not easy to scale up or down. So that means you can't really write scripts well in Java. And if you want to do really domain-specific stuff, it gets very difficult. So that's precisely why we have this pressure to add new languages. Okay, so maybe I wrap up, just to tell you a little bit where we are now with Scala Community. Sorry? You've got 12 minutes. 12 minutes? Wow, I thought I had to finish at five. It reminds me of 448. Oh, okay. Okay, good. I thought I had to finish at 10 to five. That's why I'm rushing. Okay, good, so much. Okay, then I can take a lot of questions after the talk. So with the Scala Community is quite active. So we had about 50,000 downloads overall in 2008. Of course, that would be people who have downloaded several versions of Scala. So I'm not claiming we have 50,000 users. Our track system has about 300 active contributors. We have very active messages, mailing lists with more than 20 messages a day. And we had the first conference in May 2008. And so the first really Scala conference and Scala lift-off in May 2008. And we also have regular talks and conferences like Fasten or the next two will be at QCon in London of other people who will give talks about Scala. Tool support, what's available there. So what we do is we have a standalone compiler called Scala C, which has essentially the same functionality as Java C. There's a faster version of this which is sort of a compiled demon which sits in memory and you send it compiled jobs and it will do it for you and it will cache everything in memory and thereby it's much faster. That's called FSC. There's an interactive interpreter shell which you have seen and script runner that's called just Scala. That actually uses this trick with the fast compiler. So when I type a line into my shell, where is it? Ah, now it comes. When I type a line like this line, I typed here. So what actually happens is that when I do that the thing will be wrapped into an object, complete object, it will be passed into the fast Scala compiler, the fast Scala compiler will compute a class file and I'll load the class file into the interpreter and execute it. So that way the interpreter and the compiler are really the same thing. So we can have the assurance that it's exactly the same thing that gets compiled in exactly the same way and to make it work, we have this compiler sitting in the background that doesn't need to be loaded into memory every time I do that. Okay, oops, that wasn't it. Where is my, here we are. Okay, okay, there's a web framework which is quite active. I think there are 700 people on the mailing lists which is called LIFT, which is sort of in the same space as Rails or Grails or frameworks like this, sort of a do all web framework for you. Difference, of course, is that all this thing is statically typed and there are a lot of testing frameworks here, just some, they're called specs, Scala checks, Scala tests as unit and so on. The first two are very interesting because they are behavioral testing frameworks where you don't write test cases or you can write test cases, but typically you write properties of what your programs should, of your programs that you want your programs to have and the system then will generate the test cases for you based on the properties and the types of the properties. There's something like that in Haskell called QuickCheck. It's very popular in the Haskell world. So Scala check is basically a fairly direct or started as a direct port of QuickCheck to Scala and it has acquired new things since. If you're familiar with Haskell, you'll find that most of the things in Haskell you find in some often completely different form in Scala but we have tried to get a lot of the functionality of what is in Haskell into Scala only in an object oriented form. So instead of let's say type classes which are very important in Haskell and which are used for this QuickCheck tool, we have, I mentioned already these implicit conversions and implicit parameters which give you the same functionality but in object oriented form. Okay, there are also now IDE plugins for the major platforms so we have started a number of years ago development on the Eclipse plugin that's been taken over now by EDF Trading in London, they support that. There's an IntelliJ plugin rapidly coming along which is done by JetBrains people. There's a NetBeans plugin done by Kayon Deng under support of Sun. So I'm not saying that these things are already as polished and complete as the Java plugins but we're getting there. So if you try them out there, I think they're usable today. Lots of people use them. We had a poll on the mailing list, what IDE do people use? About two thirds of the respondents use one of these plugins, one third use Emacs or VI or things like that. I must say I use, still mostly use Emacs but that's just because I'm old I think. Okay, so who's using it? Open source projects, I'm already mentioned Lyft there's some movement in Wicked to use it. NetLogo, that's an environment and learning environment using the logo language so that's being ported to Scala. Processing has a Scala version of it called SPDE. The Isabel Theorimprover has its GUI and code extractor are now based on Scala or one version of its code extractor based on Scala. Companies are also warming up to it. So Twitter has based essentially they're all the new infrastructure work at Twitter is now in Scala, used to be Ruby. The Sony Pictures Middleware and Sony Pictures Enterprises is also in Scala. Nature.com the whole infrastructure is in Scala. SAP Community has an as me that's an intercompany messaging system that's written in Scala. Reactor was voted Europe's best small and middle mid-sized company to work at. It's a Finnish company, they have lots of Scala projects. Mimesis Republic does multiplayer games in Paris with Scala. EDF Trading I already mentioned they support the Eclipse plugin. So this thing here that's not the Scala community that's just this photo was first sent with Twitter in the world, I think Twitter was the company that it was somebody took it in with this iPhone sent it to Twitter and they transmitted it. So I would guess that there was some Scala code involved to bring this photo to you. Okay, thanks. Sorry? Yeah, not in the iPhone, no. So to learn Scala, what I would recommend to get started, there's a website called artema.com and they have a Scala scene still in its infancy with Scala articles. And there's a good one called First Steps in Scala which is essentially how do I deploy it? How do I start up the repel? How do I type my first lines of Scala? That's very good to get started. There's also a very useful series of blogs called Scala for Java refugees by Daniel Spivak. I can highly recommend that. So if you want to continue and more determined then we've written a book called Programming in Scala published by artema.com. So that's the first book up here. That sort of really explains everything you need to know from the easy part to the most complicated details. So if you really want to know the whole story that's the book for you. There are also several other more introductory books in the pipeline by the Pragues and A-Press and there's another one by O'Reilly but I couldn't find the, I haven't seen a screen title yet so I couldn't include the title in this series. So I'm at the end of the talk. Thank you for listening. If you want to try it out that's the website ScalaLang.org and should also take the opportunity to thank all the many, many people who have worked on this and have helped with it. Question, for variables? Yeah. For a variable? Yeah. Oh, right. So for a vowel you mean, yeah, yeah. So there's a difference. So the question is why not have, well, do we have something to write? So we can write def f equals that and the answer, the question was why do I have a vowel x equals like that? So the difference is there's a difference in evaluation. If the function will be evaluated every time I write f, I use its name. So it's evaluated by name, one says. The value will be evaluated here when I define it and every time I use the x, I use its value. So the difference is when are things evaluated for a vowel definition. It's like a variable initialization. I evaluate when I write the vowel for a function I wait until the function is called. That's the difference.