Scala - A Scalable Language
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 70 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/39552 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 200927 / 70
3
4
6
16
17
18
19
20
21
22
23
24
25
26
27
29
30
31
32
33
35
40
41
44
46
47
48
50
51
54
55
57
58
59
60
62
65
67
68
69
70
00:00
ScalabilityProgramming languageBoom (sailing)SoftwareProgramming languageBitDifferent (Kate Ryan album)Logische ProgrammierspracheIntegrated development environmentProcess (computing)WebsiteProblemorientierte ProgrammierspracheJava appletClient (computing)TowerTelecommunicationMereology5 (number)Figurate numberDatabaseWeb browserSoftwareComputer fileConfiguration spaceXMLComputer animationLecture/Conference
01:27
ComputerScalabilityProgramming languageData typeScripting languageBoilerplate (text)Letterpress printingProgramming languageType theoryOpen sourceTelecommunicationMereologyFluid staticsNetwork topologyDynamical systemProblemorientierte ProgrammierspracheReading (process)Interactive televisionLibrary (computing)Extension (kinesiology)Computer programExterior algebraPhysical systemError messageMoment (mathematics)CompilerGroup actionSoftware developerCartesian coordinate systemLevel (video gaming)Lecture/Conference
03:37
Java appletCellular automatonSystem callProgramming languageMaxima and minimaManufacturing execution systemMoving averageConvolutional codeMIDIJava appletProgramming languageEnumerated typeInterface (computing)System callProgrammschleifeSocial classRight angleStatement (computer science)ExpressionInterior (topology)Parameter (computer programming)Library (computing)Mixed realityType theoryForm (programming)Operator (mathematics)Module (mathematics)Line (geometry)Computer programEquivalence relationElectronic mailing listAbstractionWeightInheritance (object-oriented programming)MultiplicationDescriptive statisticsDirected graphSoftware frameworkComputer fileConfiguration spaceAdditionInjektivitätScripting languageLoop (music)Letterpress printingComponent-based software engineeringReading (process)Level (video gaming)Different (Kate Ryan album)QuicksortBitSoftware architecturePattern matchingSingle-precision floating-point formatObject-oriented programmingConstructor (object-oriented programming)Cartesian coordinate systemSpring (hydrology)AreaPrimitive (album)Online helpTerm (mathematics)CASE <Informatik>Functional programmingPredicate (grammar)Multiplication signResultantModul <Datentyp>Communications protocolSelectivity (electronic)Integrated development environmentProcess (computing)Algebraic closureSoftware testingComputerMereologyNetwork topologyEndliche ModelltheoriePlastikkarteOpen sourcePhysical systemFluid staticsInterpreter (computing)Potenz <Mathematik>Real numberArithmetic meanCausalityInformation overloadCodeComplete metric spaceField (computer science)WebsiteTape driveSubject indexingRun time (program lifecycle phase)Modulare ProgrammierungFitness functionMatching (graph theory)Lecture/Conference
12:47
Regulärer Ausdruck <Textverarbeitung>Philips CD-iRippingSingle-precision floating-point formatSpring (hydrology)Parameter (computer programming)Object-oriented programmingType theoryCartesian coordinate systemSocial classStatement (computer science)Operator (mathematics)Matching (graph theory)Programming languageInstance (computer science)VarianceTypinferenzLogical constantPattern languageInitial value problemSystem callLibrary (computing)Constructor (object-oriented programming)Java appletField (computer science)PhysicistComplex (psychology)Interior (topology)CompilerExpressionWritingFactory (trading post)Game controllerFluid staticsFunctional programmingDifferent (Kate Ryan album)Inheritance (object-oriented programming)Cheat <Computerspiel>Electronic mailing listString (computer science)CryptographyDoubling the cubeAlgebraic closureExtension (kinesiology)BitDecimalImplementationInterface (computing)Line (geometry)CodeReduction of orderComputer programLie groupSound effectSampling (statistics)Mixed realityCondition numberRight angleProcess (computing)2 (number)Correspondence (mathematics)Digital photographyDampingMoment (mathematics)Exterior algebraWordComputer configurationInferenceProduct (business)Software testingComplex numberNoise (electronics)Pattern matchingArrow of timeLecture/Conference
21:57
Data typeJava appletMathematical singularityData structureControl flowEmailJava appletParameter (computer programming)Instance (computer science)WritingSocial classException handlingSpecial unitary groupBlogProgramming languageFunctional programmingControl flowType theoryData typeLibrary (computing)Interior (topology)Game controllerIntegerExterior algebraOperator (mathematics)Point (geometry)Goodness of fitFerry CorstenBlock (periodic table)ComputerObject-oriented programmingComputer programReduction of orderLine (geometry)Revision controlStandard deviationGeneric programmingLimit (category theory)Utility softwareElectronic signaturePoisson-KlammerAngleOvalSystem callData conversionBitExecution unitCompilerImperative programmingAnalytic continuationDrop (liquid)Electronic mailing listComputer clusterComputer fileResultantCodeAdditionQuicksortProduct (business)Algebraic closurePeer-to-peerSineLoop (music)Closed setFactory (trading post)Buffer solutionCASE <Informatik>Multiplication signProcess (computing)Open sourceRow (database)Template (C++)Thomas BayesInformation overloadInferencePhysical lawScaling (geometry)DivisorRight angleRootStatisticsLecture/Conference
31:07
ScalabilityPunched cardBit rateObject-oriented programmingParameter (computer programming)Functional programmingRootComplex (psychology)FunktorRow (database)Element (mathematics)Matrix (mathematics)Level (video gaming)Social classCodeInterior (topology)Object-oriented programmingComputer programState observerQuicksortImplementationINTEGRALMereologyInstance (computer science)Data conversionBoilerplate (text)Line (geometry)MassAbstractionPrimitive (album)Table (information)Arrow of timeOperator (mathematics)LengthImperative programmingBitProcess (computing)Library (computing)Metric systemType theoryJava appletProgramming paradigmCASE <Informatik>Pattern languageBlock (periodic table)Power (physics)Hash functionCompilerCartesian coordinate systemProgramming languageRule of inferenceException handlingData typeAlgebraTypsichere SpracheCombinational logicBuildingVulnerability (computing)Different (Kate Ryan album)NumberIntegerArray data structurePolymorphism (materials science)Parametrische ErregungCellular automatonMenu (computing)Pay televisionMultiplication signIdentity managementFluid staticsPhysical systemBit rateDynamical systemExtension (kinesiology)WebsiteHazard (2005 film)Dressing (medical)Task (computing)Arithmetic meanSoftware testingResultantSound effectSubject indexingThread (computing)Point (geometry)Covering spaceError messageComplex systemHypothesisPrice indexRight angleCausalityLecture/Conference
40:17
Erlang distributionE-learningNP-hardExecution unitKeilförmige AnordnungMessage passingWeightCalculationData miningPattern languageFile formatBitPressureNumberProgramming languageLoop (music)SummierbarkeitQuicksortRevision controlFlow separationGoodness of fitLibrary (computing)Line (geometry)Level (video gaming)Thread (computing)MereologyProblemorientierte ProgrammierspracheScripting languageJava appletObject-oriented programmingType theoryCartesian coordinate systemComputer programFunctional programmingMultiplication signBlock (periodic table)ResultantPartial derivativeSemiconductor memoryCache (computing)Process (computing)Interactive televisionAbstractionExpert systemComplex (psychology)Social classError messageCompilerInterpreter (computing)Hash functionDifferent (Kate Ryan album)Lokaler KörperCodeOcean currentElectronic mailing listEmailTrailBoolean algebraPredicate (grammar)Queue (abstract data type)Element (mathematics)Special functionsPhysical systemLatent heatBoolean functionPattern matchingRegular graphCuboidWordAreaMatching (graph theory)Group actionImplementationEndliche ModelltheorieSineCASE <Informatik>Form (programming)AeroelasticityInstance (computer science)Field (computer science)Concurrency (computer science)Right angle40 (number)Constructor (object-oriented programming)State observerDemonService (economics)Inheritance (object-oriented programming)ConcentricWritingOperator (mathematics)Lecture/Conference
49:27
Object-oriented programmingMultiplication signSemiconductor memoryInterpreter (computing)Social classType theoryComputerComplete metric spaceLine (geometry)Computer fileCompilerLecture/Conference
50:21
Inclusion mapInterior (topology)Programming languageSoftware testingCASE <Informatik>Social classComputer programCurvatureForm (programming)Object-oriented programmingCategory of beingFunctional programmingPerformance appraisalSinc functionDifferent (Kate Ryan album)Direction (geometry)WritingFerry CorstenType theorySeries (mathematics)CausalityTouchscreenMereologyDependent and independent variablesElectronic mailing listEmailComputing platformUsabilityPlug-in (computing)Special unitary groupPhysical systemNumberExecution unitParameter (computer programming)Data conversionGroup actionMultiplication signSoftware frameworkUltraviolet photoelectron spectroscopyProjective planeTwitterRevision controlCodeProcess (computing)Integrated development environmentComputerSoftware developerQuicksortOpen sourceBlock (periodic table)Line (geometry)SpacetimeWebsiteDigital photographyGame theoryBlogRight angleWeb 2.0Java appletNatural numberMiddlewareGraphical user interfaceLecture/Conference
57:41
XML
Transcript: English(auto-generated)
00:07
So, I think we can start. Thanks for coming. I'm Martin Wieske. I'm from EPFL in Lausanne. That's the logo down here. And I have been working for the last five years or so
00:22
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,
00:42
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.
01:01
If you're in a Java environment, maybe you have JavaFX 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 cover all this together with usually a generous helping of XML
01:23
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
01:41
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 of this
02:01
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,
02:21
very low-level things such as XML trees or even trees or even strings, and then typically that's where the errors 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
02:40
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
03:01
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,
03:22
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.
03:45
Let's just go through one. Oops, no, it goes away. Why does it go away? Yeah, why do I, sorry, I should have set this up before. And here we have on the lower part, we have our Scala interpreter, and I could, for instance, just write one plus two,
04:00
or I could say list of one, two, three, for each, or map plus one, and that gives me a list which is two, three, four. So I can just interact with these things interactively
04:22
with a read eval print loop like what you are 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.
04:40
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,
05:00
these features in Java 8, 9, or 10. It compiles to .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.
05:23
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,
05:41
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
06:02
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
06:23
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.
06:42
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,
07:01
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. There's virtually nothing that doesn't work completely without any protocol. So you don't need any glue code,
07:21
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 that reason, it's also the case
07:40
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,
08:04
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,
08:20
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.
08:42
So you might ask with all that, don't you get a huge language, 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.
09:01
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
09:20
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 area 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.
09:41
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.
10:01
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 mix and 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.
10:22
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.
10:42
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
11:03
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
11:22
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? A Scala code, sorry. Oh, okay, quite a few. Written, written, who's written?
11:40
Oh, much, 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.
12:01
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,
12:21
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.
12:42
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 val instead of var.
13:01
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, is it applicable?
13:20
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,
13:43
with the expressions, so a method call looks basically in exactly the same way as in Java. So you write object dot 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
14:01
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 then else, very much like in Java, but because in Scala every statement is an expression, we only need one if.
14:21
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.
14:41
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,
15:01
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, which is much shorter. It's much shorter because
15:21
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
15:41
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.
16:03
Okay, finally, traits. So on the right hand side, you have a 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. So you can give them some implementations
16:21
that then are inherited, and you can even define fields, like down here. And instead of having a interface implementation like that in Java, you just write in Scala class C extends, and then you have what we call mix-in composition. You take the superclass and all the traits,
16:41
and you mix them in together with this with keyword. So overall, it feels like a cleaned up Java a little bit. The syntax is usually much more lightweight and concise. In my experience, if you don't change the program a lot,
17:01
you will still get a reduction in 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 lightweight, and then you can make use of extensible APIs,
17:22
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
17:41
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,
18:02
and 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 done, 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,
18:22
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.
18:42
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.
19:01
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 hashmap, 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,
19:22
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 it's a value you're defining,
19:43
x tells you it's x you're defining, and then this thing here, you might often even infer, you don't need to write at 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,
20:02
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,
20:22
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?
20:43
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? The alternative, of course, is to let the users
21:02
grow their 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.
21:21
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 hat, right? Every language can do that, in particular object-oriented languages. So, of course, in Java, you can also define big-int.
21:41
In fact, it has been defined. It's called java.math.big-integer. 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 interact
22:03
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 big-int, which is in the Scala library.
22:20
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
22:42
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,
23:02
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,
23:21
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.
23:43
Yeah. Very good, 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.
24:00
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
24:22
to make these things work. I didn't want to go into that because it goes a bit too deeply, but that's essentially how it's done. There's 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?
24:41
So 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.
25:00
That means I want to open it and do something with it, and then close it automatically. 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 create a resource,
25:21
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 null, 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.
25:41
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.
26:01
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 null, you close it. But let's have a look at the signature of using here. So using, the first thing it has to do
26:21
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 close 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
26:40
where they write sharp brackets. But otherwise, it's the same thing. No, we write brackets where they write angle brackets. 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 close method. It must be a type that has a close method. So that's the second approach.
27:01
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.
27:20
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
27:42
because we say they're a bit imperative. Typically you need to break and continue to get out of a very tangled control structure. 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.
28:02
What if you were to 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't do break and continue perfectly well with just libraries. So here's what you now would do. In fact, so you would import something
28:20
from a class called Scala util 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,
28:41
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,
29:00
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 a lowercase break exception. And now breakable, that was the breakable operation.
29:24
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,
29:42
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?
30:02
Good point, good point. 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.
30:21
I have done 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,
30:44
and he also wrote a blog about that, that modern VMs, they can optimize this thing in so much a way 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
31:02
with this trick with exceptions. So question is, if we look now at the Scala design, what is the root of the scalability? And I think there are many factors. There's strong typing, there's inference, which means you don't get weighed down
31:21
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
31:41
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 high-order functions, algebraic types and paramatching, parametric polymorphism. Object-oriented programming, on the other hand,
32:02
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,
32:24
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 the two together. It would always be easy to just say, well, let's throw the functional parts here and just add the object-oriented parts as well.
32:41
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?
33:01
Okay, so from the object-oriented side, 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.
33:23
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.
33:42
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, well, essentially there are two definitions of functional. One is sort of the bondage discipline,
34:02
which says that a function you 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
34:22
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 very rich ways to express functions. You can have anonymous functions, you can have currying, you can nest functions.
34:41
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
35:01
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
35:21
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-alls into the array classes so that we dress them up there. Okay, so now you could say,
35:42
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 scara.function one of s and t.
36:00
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 subtyping.
36:21
It's co-variant 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 int x and it returns x plus one.
36:42
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 it takes the x and it returns x plus one. So that's what it does.
37:03
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 sub-classed. That's something you have on the object oriented side, not on the functional side. On function programming,
37:21
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, it's nothing but a function from ints,
37:40
some sub-range 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
38:01
like elements and exists and for alls that we have seen in the metrics 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.
38:21
When we 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?
38:41
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
39:01
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.
39:21
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,
39:40
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.
40:01
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 the Java threads, we use the modern concurrent libraries by Doug Lea, a lot of that.
40:20
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.
40:42
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,
41:01
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 principal constructs,
41:21
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 the send is asynchronous. That means you send off the message and then you do other things, and the message will be buffered in a mailbox, and when the receiving actor is ready, it will process it.
41:40
And there's receive then, which is of this form, so it is a number of cases, so like 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,
42:00
and then acts on this message. So here's an example of an actor. Check some calculator. The 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,
42:21
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.
42:43
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.
43:02
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.
43:22
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.
43:42
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.
44:02
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.
44:21
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
44:41
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,
45:01
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.
45:23
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 Erlang-style actors, but every time you look at the actual implementation,
45:42
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 Erlang. People can't do it in functional languages. Either because a function is a function is a function. You can't have special functions like partial functions and those we need here for the dispatch.
46:01
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,
46:23
at least upwards. You can go into stratospheres 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.
46:41
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 interoperate operation, and have many different languages. But on the other hand, the problem is the .NET language format
47:01
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.
47:22
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 got 12 minutes. 12 minutes?
47:40
Wow. I thought I had to finish at five. Mine says 4.48. 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.
48:03
So 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.
48:23
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 liftoff in May 2008. And we also have regular talks and conferences like Fostem
48:42
or the next two will be at QCon in London for 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.
49:02
There's a faster version of this, which is sort of a compiled daemon, 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.
49:22
That actually uses this trick with the fast compiler. So when I write, 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.
49:42
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 will load the class file into the interpreter and execute it.
50:01
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.
50:24
Where is my, ah, here we are. Okay, okay, there's a web framework which is quite active. I think they have 700 people on the mailing list which is called Lyft, which is sort of
50:41
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,
51:00
Scala test 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
51:20
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
51:41
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 and to 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
52:03
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
52:21
development on the Eclipse plugin that's been taken over now by EDF trading in London. They support that. There's IntelliJ, an IntelliJ plugin rapidly coming along which is done by JetBrains people. There's the NetBeans plugin done by Kayan Deng under support of Sun.
52:40
So here 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.
53:01
One third use Emacs or VI or things like that. I must say I still mostly use Emacs but that's just because I'm old, I think. Okay, so who's using it? Open source projects. I already mentioned Lyft. There's some movement in Wicket to use it.
53:21
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 SPD. The Isabel Theor Improver has its GUI and code extractor are now based on Scala. One version of its code extractor based on Scala.
53:42
Companies are also warming up to it. So Twitter has based essentially their 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.
54:00
SAP community has an ASMI, that's an intercompany messaging system that's written in Scala. Reactor was voted Europe's best small and 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.
54:20
EDF Trading, I already mentioned, they support the Eclipse plugin. So this thing here, that's not the Scala community. This photo was first sent with Twitter in the world. I think Twitter was the company that somebody took it with his iPhone, sent it to Twitter and they transmitted it.
54:41
So I would guess that there was some Scala code involved to bring this photo to you. Okay, thanks. Sorry? Not in the iPhone, no. So to learn Scala, what I would recommend to get started there's a website called artima.com
55:02
and they have a Scala zine still in its infancy with Scala articles. And there is a good one called First Steps in Scala, which is essentially how do I deploy it? How do I start up the REPL? 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
55:20
called Scala for Java Refugees by Daniel Spivak. I can highly recommend that. So if you want to continue a more determined then we've written a book called Programming in Scala published by artima.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.
55:43
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 Prags and Apress and there's another one by O'Reilly but I couldn't find the, I haven't seen a screen,
56:03
a 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
56:21
and have helped with this. Question.
56:46
For variables? For a variable? Oh, right. So for a val you mean? Yeah, yeah. So there's a difference. So the question is why not have, well, do we have something to write?
57:02
So we can write def f equals that and the answer, the question was why do I have a val x equals like that? So the difference is there's a difference in evaluation. The function will be evaluated every time I write f. I use its name.
57:20
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 val definition it's like a variable initialization I evaluate when I write the val. For a function I wait until the function is called. That's the difference.