How Scala is different
•Download as PPTX, PDF•
0 likes•304 views
Introduction to Scala for object-oriented programmers. Comparing Scala to languages such as C# and Java.
Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
How Scala is different
- 1. Today
- 2. Why Scala?
- 3. Not Today • Sales pitch – “Selling Scala to your boss” • Ecosystem – Distributed computing – Web applications
- 4. Scala Features ≈ Functional • First class functions • Type inference • Case classes • Pattern matching • Immutable state • Nested functions • Laziness • Implicits ≈ Object Oriented • Singletons • Traits
- 7. Case classes
- 10. Immutability II
- 11. Singleton
- 12. Nested functions
- 13. Traits I
- 14. Traits II
- 15. Laziness I
- 16. Laziness II
- 18. Implicit Parameters I • Ten different implementations
Editor's Notes
- Combines features from many programming languages. Looking at Scala gives you more insight into other languages. Show you what’s possible with more functional programming. We’ll be doing some direct comparisons with Java and C#.
- Won’t be trying to sell you Scala. There’s an excellent presentation on that “Selling Scala to your boss” that I’d recommend to Milan. Also won’t be discussing the ecosystem surrounding Scala. Distributed computing; Web applications. Hadoop is at the moment the standard in distributed computing. More than half of the Fortune 50 use Hadoop. Spark is the successor to Hadoop and is written in Scala.
- These are the Scala features I’ll be talking about. They’re mostly functional cause you all know object oriented programming. Start with the basics. You might already be familiar with these. I’ll try to go not to fast. Traits, laziness and implicits are the most interesting features. I’m saving them for last.
- Squares concept uitleggen. Java 7. Java 8 daarbij kan je een lambda gebruiken, en Scala vergelijkbaar met Java 8. Don’t want to talk about first class functions. I think you know them already. Every modern language has them: Java 8, C#, Scala, F# There are differences but this is out of our scope. “expression bodied members” is coming to C# 6.0
- Type inference is common in modern languages but previously was mostly in functional programming. Here are some samples of sumEevenNumbers in different languages. Silly example. Takes a list of the numbers one to three, and sums only the even numbers. Sommige talen doen meer type inferentie dan anderen. Type inference on - lambda’s - local variables - fields - method return types - constructors.
- Left, looks like a lot of code right? Well I didn’t write it. Only wrote about one line of code. Not ideal, when I change something I have to generate all the code. I can’t make any changes to the generated code or I risk losing them. Scala moves this type of code generation from the IDE to the compiler. The Java bytecode of the Java and Scala implementation is the same. In the Scala example, the parameter ‘miles’ of the class Car definition creates the field and the constructor. Adding case generates the hashcode, equals and the get. C# already has automatic getters/setters, allowing you to combine the field and the getter. C# has some features coming that relate to this: - Getter-only auto-properties, 6.0 - Auto-property initializers, 6.0 - Primary constructors, not in 6.0 F# has what Scala has.
- Leg uit wat driveCar doet. Anyone recognize this pattern? Disadvantages? Clunky. Not very type safe. There’s a pattern to prevent this. What’s it called? How does this look in C#? You can write it more type-safely by using an ‘as’ cast. Functional languages like Haskell and Scala have pattern matching. It’s like a switch on steriods. The example is simple but there are many more features. C# has a similar feature “type classes” on the wishlist.
- Wat is immutability? In het linker voorbeeld zie je dat je vaker aan de variabele x kan assignen, maar niet aan y vanwege final. Who uses immutability? Advantages? We don’t use immutability that much but many functional languages are fully immutable. Final in the left example. Can you do this in C#? Who uses final/readonly on fields? I’m not always sure it’s worth the extra syntax. Scala val syntax is light. I always use val when I can, which is often. In Haskell you can leave away the val.
- You can’t write a program without datastructures. Scala has immutable data structures, and also mutable ones. The immutable variants are in the default scope, so they’re sort of recommended.
- Who knows the singleton pattern? Do you like it? In Scala, statics have been replaced by making singletons a language concept. In this sense it is more OO than Java / C#. Enums don’t exist but can be mimicked with objects.
- In a functional language like Haskell you don’t have classes. Often part of your hierarchy is created by nesting functions. Scala has nested functions. The concept is simple, nested function have access to the scope of the function they are in. The example. It’s not a lot of code but it can be hard to read. What is depth first traversal? Would you like to go over the example to get it?
- You all know inheritance. Who of you works with multiple inheritance? Do you feel like you need it? Here’s an example of the PEARL code base where we could have used multiple inheritance. There’s lots of duplication here. We have many more of these report classes. Someone actually used copy paste to put the same kind of time series functionality in all of these time series variants. So what could we have done to improve the situation? Decorator pattern. Java and C# have interfaces. In Scala interfaces are replaced by traits. A trait is somewhere between an interface and an abstract class. They provide a method of doing multiple inheritance since traits can contain behavior and state.
- This is the typical diamond problem which is the canonical issue with multiple inheritance. Suppose we inherit from both DoublingQueue and IncrementingQueue. What gets put in the queue when we call push? Java 8 has default methods. Can you use those to create this situation? No, Java 8 has ‘unrelated defaults’ exception. Java 8 mixins can only be used to combine unrelated functionality. Also mixins can’t contain state. Default methods were made only as strong as required by their goal: backwards compatibility. In Scala the order in which you mix in the traits determines who’s victorious. Suppose you want to have DoublingQueue and IncrementingQueue interact. Use abstract override. How is this in C++? The diamond problem gets really confusing when you think about constructors. Scala traits have no constructors so this simplifies it compared to C++. It’s a matter of taste but Scala Traits cover the main criticism of C++ inheritance.
- In Java 8 the Optional class was added. The concept of Optional is that tries to help deal with the null value. It wraps around a value that might be null. If you have an Optional you can try to get the value out of it but you have to provide a default. Java 8 has two methods that both implement this concept. In Scala there is only one method. Trick here is that the method argument is lazily, so it’s automatically wrapped in a lambda. Syntactical advantage from two sides.
- Some more cool stuff that you can do with laziness: infinite data structures. cons we can use to construct a stream. It starts with a head value, and after that come the other values, the tail. Stream is similar to a list but uses laziness. AllNumbers is a stream of all the numbers from 0 to infinity. Defined using allNumbersFrom
- Suppose we want to add functionality to a class from outside the class. In Java we can’t really do this. Best we can do is a extensions class. In C# we can do better with extension methods. In Scala we can define extension methods and add interfaces.
- Let’s look at the sum function on sequences of numbers. Skip the Java implementation to save us some tears. Let’s look at C# first.
- Calling sum in just as simple as in C#. Ignore the [B >: A] type annotation. Definition of sum is located in the traversable trait. foldLeft is also in traversable. It abstracts over the loop over list pattern. This is called the type class pattern. It is used to add interfaces to classes that did not declare them.
- I didn’t cover the really advanced features: - Higher kinded types - Macro’s - TypeTags for dealing with type erasure