Scala Introduction - Synerzip
•Download as PPTX, PDF•
0 likes•180 views
The document is an introduction to functional programming concepts using Scala presented by Sujith Sudhakaran. The presentation covers imperative programming styles and their limitations in dealing with concurrency and parallelism. It then introduces functional programming concepts like immutability and pure functions. The document discusses Scala's features as a unifier of object-oriented and functional paradigms and covers key Scala concepts like higher-order functions, traits, pattern matching and popular Scala frameworks.
Recommended
Recommended
More Related Content
Similar to Scala Introduction - Synerzip
Similar to Scala Introduction - Synerzip (20)
More from Synerzip
More from Synerzip (20)
Recently uploaded
Recently uploaded (20)
Scala Introduction - Synerzip
- 2. https://in.linkedin.com/in/sujithsudhakaran Agenda ● Imperative Programming ● Renaissance of Functional Programming ● Scala Intro ● Concepts ● Popular frameworks
- 3. https://in.linkedin.com/in/sujithsudhakaran Agenda ● Imperative Programming – Understanding our usual style – Bottle neck – Moore's Law – Concurrency and Parallel Programming ● Renaissance of Functional Programming ● Scala Intro ● Concepts ● Popular frameworks
- 10. https://in.linkedin.com/in/sujithsudhakaran Concurrency & Parallel programming Really HARD to get it RIGHT
- 11. https://in.linkedin.com/in/sujithsudhakaran Agenda ● Imperative Programming ● Renaissance of Functional Programming – Non determinism and side effects – Functional programming ● Scala Intro ● Concepts ● Popular frameworks
- 12. https://in.linkedin.com/in/sujithsudhakaran Non-determinism var x = 0 async { x = x + 3; println(x)} async { x = x * 5; println(x)}
- 16. https://in.linkedin.com/in/sujithsudhakaran What we learnt so far... ● Immutability ● Pure functions
- 19. https://in.linkedin.com/in/sujithsudhakaran Agenda ● Imperative Programming ● Renaissance of Functional Programming ● Scala Intro – Scala as unifier – Class hierarchy – Keywords used – Scala being concise ● Concepts ● Popular frameworks
- 20. https://in.linkedin.com/in/sujithsudhakaran Scale Language - Introduction
- 22. https://in.linkedin.com/in/sujithsudhakaran Scala – keywords used in the examples ● val: to declare a immutable variable ● var: to declare a mutable variable ● def: to define a function ● println: to print out line ● trait: similar to interfaces in java ● sealed: keyword used to specific classes locally only ● object: keyword used to instantiate a singleton object ● extends: used for inheritence ● with: used while doing multiple inheritence ● match: keyword for pattern matching ● case: used for pattern matching ● override: used to override a behavior of an interface ● =>: used to show the some input mapping to output
- 27. https://in.linkedin.com/in/sujithsudhakaran Scala being OO... Every value is an object – Eg: 1 // Yes, its an object – 1.toString // method can be called – 1 + 2 + 3 is equivaled to (1).+(2).+(3)
- 28. https://in.linkedin.com/in/sujithsudhakaran Agenda ● Imperative Programming ● Renaissance of Functional Programming ● Scala Intro ● Concepts – Call by value/Call by name – Higher order functions – Tail recursion – Traits – Abstract Types – Partial functions – Pattern matching ● Popular frameworks
- 29. https://in.linkedin.com/in/sujithsudhakaran Call by value/Call by name Call by value
- 30. https://in.linkedin.com/in/sujithsudhakaran Call by value/Call by name The problem we may face...
- 31. https://in.linkedin.com/in/sujithsudhakaran Call by value/Call by name Call by name
- 32. https://in.linkedin.com/in/sujithsudhakaran Functions ● First class values ● Function type S => T is trait Function1[-S, +T] { def apply(x: S): T } ● def sum(x: Int, y: Int) = x + y ● sum(1, 2) ● (x: Int, y: Int) => x + y // What is the use of this function?
- 33. https://in.linkedin.com/in/sujithsudhakaran Higher order functions What’s common in this two programs?
- 35. https://in.linkedin.com/in/sujithsudhakaran Higher order functions ● Examples: map, filter, reduce etc.
- 36. https://in.linkedin.com/in/sujithsudhakaran Tail recursion What's the difference in these programs? > f (21 == 0) 14 else gcd(21, 14 %21) > if (false) 14 else gcd(21, 14 %14) > gcd(21, 14 %21) > gcd(21, 14) > if (14 == 0) 21 else gcd(14, 21 %14) > gcd(14, 7) > gcd(7, 0) > 7 > if (5 == 0) 1 else 5 * fact(5-1) > 5 * fact(4) > 5 * (4 * fact(3)) > 5 * (4 * (3 * (fact(2)))) > 5 * (4 * (3 * (2 * fact(1)))) > 5 * (4 * (3 * (2 * (1 * fact(0)))))) > 5 * (4 * (3 * (2 * (1 * 1))))) > 120
- 37. https://in.linkedin.com/in/sujithsudhakaran Tail recursion What's the difference in these two example? > f (21 == 0) 14 else gcd(21, 14 %21) > if (false) 14 else gcd(21, 14 %14) > gcd(21, 14 %21) > gcd(21, 14) > if (14 == 0) 21 else gcd(14, 21 %14) > gcd(14, 7) > gcd(7, 0) > 7 > if (5 == 0) 1 else 5 * fact(5-1) > 5 * fact(4) > 5 * (4 * fact(3)) > 5 * (4 * (3 * (fact(2)))) > 5 * (4 * (3 * (2 * fact(1)))) > 5 * (4 * (3 * (2 * (1 * fact(0)))))) > 5 * (4 * (3 * (2 * (1 * 1))))) > 120
- 39. https://in.linkedin.com/in/sujithsudhakaran Tail recursion The Problem!! StackOverflowError Exception
- 41. https://in.linkedin.com/in/sujithsudhakaran Traits - Mixin class composition ● Share interfaces and fields between classes ● Can be extended but NOT instantiated ● Use the keyword with to extend from multiple traits ● Traits with code are known as Mixins ● Abstract and concrete fields
- 42. https://in.linkedin.com/in/sujithsudhakaran Traits – Multiple Inheritence(Diamond Problem) Diamond Problem Staff Person Student Teacher Student Teacher
- 43. https://in.linkedin.com/in/sujithsudhakaran Traits – Solving Diamond Problem Linearization
- 44. https://in.linkedin.com/in/sujithsudhakaran Traits – Solving Diamond Problem Linearization Derived B C Base AnyRef Any A Base AnyRef Any
- 45. https://in.linkedin.com/in/sujithsudhakaran Traits – Solving Diamond Problem Linearization ABCDerived Base AnyRef Any
- 48. https://in.linkedin.com/in/sujithsudhakaran Pattern matching ● How we used switch statements? ● Generalization of switches
- 49. https://in.linkedin.com/in/sujithsudhakaran Pattern matching ● How we used switch statements? ● Generalization of switches
- 50. https://in.linkedin.com/in/sujithsudhakaran Pattern matching ● How we used switch statements? ● Generalization of switches
- 51. https://in.linkedin.com/in/sujithsudhakaran Pattern matching – More examples
- 52. https://in.linkedin.com/in/sujithsudhakaran Pattern matching – More examples
- 53. https://in.linkedin.com/in/sujithsudhakaran Partial functions ● In FP, Input => Output ● Form: val divide = new PartialFunction[Int, Int] { def apply(x: Int, y: Int) = x / y def isDefinedAt(x: Int, y: Int) = y != 0 } ● def collect[B](pf: PartialFunction[A, B])
- 54. https://in.linkedin.com/in/sujithsudhakaran Partial functions - Example Guess the type
- 57. https://in.linkedin.com/in/sujithsudhakaran Pattern matching & Partial Funtion More examples
- 58. https://in.linkedin.com/in/sujithsudhakaran To summarize... ● Compatible ● OOP ● Functional ● Concise ● High level abstractions over data structures ● Compose functions ● Statically typed ● Extensible
- 59. https://in.linkedin.com/in/sujithsudhakaran Agenda ● Imperative Programming ● Renaissance of Functional Programming ● Scala Intro ● Concepts ● Popular frameworks
- 60. https://in.linkedin.com/in/sujithsudhakaran Popular frameworks ● Apache Spark ● Akka ● Play Framework ● Other trending projects in scala
- 62. https://in.linkedin.com/in/sujithsudhakaran References ● Martin Odersky, "Working Hard to Keep It Simple" - OSCON Java 2011 ● Martin Odersky: Scala with style ● DSL: Writing web framework router ● State you're doing it wrong ● Origin of scala
Editor's Notes
- - Introduce myself - My background - Share my learning and head start Questions: - Java backgroung - worked on func language - My journey with Scala - Realization - Point out the difference and similarities
- - Brief idea about the things to cover - Talk about the things from the slide
- - So lets dive in
- - Question: what is IP? - Show the image - What is to be computed is interwined with how it is to be computed - Focus is on how the program operates - Consists of commands for computer - Always try to think w.r.t to time
- - Show the examples - I think everyone one of us might have written such code Haven’t you? Typically, IP - Changes the program state - Assignments, for/while loops, goto, conditional statements - Carrying on the legacy - Eg: C, C++, Java, Go, Python, Ruby etc. - 3rd example: Any problem? - We’ll about the problem later - why are we doing this?
- Next question: - Why ? - HW limitations made us to be imperative - Optimize code - No extra memory - Review comments - Since memory on chip was less and very expensive - Inherently Imperative - Why things have changed now?
- Question: How many of you know what’s Moore’s Law Gordon Moore 1965 - Number of transistors per square inch on integrated circuits had doubled every year since their invention Show the graph Explain the graph - It’s become dead - More cores Questions: Are we taking advantage of such Hws? Not the HW we have asked for Difficult to unlearn the things which we were doing in IP Thoughts from Martin Every IP languague has tried to take adv Next slide
- Before the image Question: - What is concurrency? - Way to acheive faster programs - No dependency on order of execution - Has it’s own problem - Show the image - deadlocks, race conditions etc Q & A So, How does scala achieves it? - Actor model Typically 4 ways Shared state Software Transaction memory Message Passing Dataflow concurrency
- Before image Question: - What is Parallel programming? - Execute programs faster on different hws - Programs can be sequential in nature - Show the image - Its very good when we have such infra; but are we ready to take the problems while this is getting built - So, we have the multi-core Hws - Are we able to take advantage of it - Difficult if left to developers - Extra baggage of imperative style - Its difficult to handle synchronization - Languagues should be inherently design to make use multi core hws - Scala does it with the help of mutable Hws - We can simply call .par function on the collections - Provided we follow principles of FP which we will talk about in a while
- - So, if we stick to our conventional IP - Its really hard to get it right - You will definitely lates nights debugging production issues
- - FP is not something which is new - It was there all this time and was more popular in academics - But now we are seeing rebirth of FP in various languaes like - Haskell(Best) - Lisp - Erlang - Scala etc. - Lets try to understand the building block of FP
- Question: Can we be certain about the outcome of this code? Why? - The problem is the shared state - Mutex, locks etc - But, why make our lives miserable - Culprit - Why not get rid of the culprit itself - Immutability - Lets have a look at the next pillar
- - Remember this eg from previous slide - What’s the problem - How about this example? - They have side effects
- - They both are impure functions - Anything which changes some state outside it’s scope - So, understanding and debugging such a fuction requires knowledge about context and its possible history Question - Production bug scenario? - Developer cannot reproduce
- - Pure functions makes systems to be - easier to understand - easier to analyze - Easier to test - Easier to optimize - From the previous example, Isn’t this code more convinient to test - Scala doesn’t restrict side effects it advocates to be - explicit - declarative - rather than allowing users to assume - So, that’s the ideology we should keep in mind
- - As we saw from last couple of side - Immuatability & Pure F are building blocks for FP - Stick to this 2 pillars to build any sort of complex concurrent and parrallel apps
- Question: What is this? - Show the image - Functions should be mapping input values to o/p not change any state - Why do I have a octopus kind of creature here? - Just to depict the scenario that it’s very simple to use with parallel programming - Primary concepts - Immutability for data structures - Pure functions without side-effects - Auxiliary concepts - Recursion - First class and higher order functions - Type systems - Referential transparency - So, if we follow this style, eventually our code becomes - elegant - readable - concise - Free from side effects or inconsistent results - So, why should we do this? - CPU are not getting faster anymore and memory is getting cheaper - Simpler reasoning principles - Better modularity and abstractions - Transparent concurrent code - More maintainable and bug free code - New perspective for problems - Leave all these reasons aside, It will be a new weapon to your arsenal
- Before the image Question - How many of you like OOPs? - Advantages: - Abstraction - Modularity - Code reuse - Clear defined interfaces - Easy to maintain - Suitable for larger projects
- So, we have talked about Imperative, Functional and OOP. Now, we are going to see where does Scala fits in all of this FACADE
- History before the image Pizza before Scala 3 features from FP: - Generics - Higher Order functions - Pattern matching - This formed the basis for Generics in Java 5 - Current era, one size doesn’t fit all - Hence, Scala has taken an hybrid approach - Show the image - Explain the image - Express common programming patterns in a concise, elegant, and type-safe way. - It's an attempt to acheive smoother integration between FP ana OOP - Martin Ordersky, 2004 - Statically typed - Mix of OOP and FP - Runs on JVM - Inter-operable with Java - Concise - High-level
- - All values have a type - Including numerical values and functions - Any: supertype of all types - AnyVal -> value types - AnyRef -> reference types - This corresponds to java.lang.Object - So that’s how Scala maintains inter-operability with Java classes
- - Read it out
- - Before the images - Omit certain type annotations - Compiler can deduce the type from the type of the initialization expression - Same implies with function return types - 1 Exception though, Recursive functions - Show the java example - Show the Scala example
- - Emphasize on how it’s written in Java and Scala - Next slide is also about high level
- Q & A: - How many of you like to write the access specifiers in other languaes and other boiler plate code - Atleast, now I don’t - Scala, has made my life way simpler
- - All the advantages we talked about OOP is readily available with Scala - Every value is object - As in the examples We can have things like: - Classes - Objects - Abstract classes - Traits - Case classes etc - But don’t use the Scala classes as java classes - Object: instantiated once, singleton, all members static - Abstract classes: similar to java, only subclassed - Traits are akin to Interfaces - Case Classes: immutable data holding entities that are used for pattern matching; no new keyword; has companion objects that are automatically crated which serve as the extractors; apply and unapply methods - That’s how elegant is Scala in OO domain
- - next we’ll talk about the concepts which i have used and felt interesting - There are many other concepts like - Currying - Self types - Annotations - Generics etc - We won’t be though them in this session atleast
- - Before the image -Doing this for quiet some time now. This is still the same in Scala. - So, every value is evaluated when they are passed around - In IP, we had taken it further by having pass by reference. But, we are not going to talk about it here - Scala being expression oriented language, it promotes pass by value too - Show the image - Explain what's happening in the program
- - Before the image - But there is a catch!! - Lets look a problem which we may encounter when we use pass by value Since, in scala everything is value. Right? - show the image - Discuss the problem
- With only 1 image - Take a look at this scala code - Talk about the notation(syntax) - Show the 2nd image - Talk about the side effect now because of the t variable - There is a catch in this function. This version is not a pure function - Either way works for Scala provided - Reduced expressions consists of pure functions - Both evaluations terminates - Call by value - Represented like a val - Every function argument is evaluated only once - Call by name - Represented like def - Argument is not evaluated if the param is not used
- - Since every value is an object - They are objects with apply method - As we pass x and y to the sum function; we can pass around the sum function too - Show the anonymous functions - since its a value we can assign it to a variable - Question: - What is a diff between methods and functions? - Techincally, they are considered differently in scala, I haven’t told you how? yet, - Guess representation for funciton and method - Reason, since if we use def it’s an object and it’s like calling apply method on that obj
- - Before the image - HOF are functions that take or return an another function - Lets look at some example where we will use them - Show the image 1 - Talk about the example - Show the image 2 - Talk about the example - Question - What’s common - functionality of addition is common - What’s different - What needs to be added - Design Principle: “Separate what cahnges from what stays the same” - So, lets try to do that
- - Expalin the example Question: - Can we do better?
- - Explain the example - Means for abstraction and creating new control structures - What I have learnt is that it's far more easier to take in a function rather than returning a function - Next concept which we are going to see is from the family of Recursion
- - Before the images - Ask about how many like recursion? - Personally I never liked it; difficult for me - show the image - Talk about the example; exapsion - Show next image - Talk about the example; exapsion Quetions: What’s the difference - We add 1 more value to our expression - last statement of the function is a call to itself - then the same stack frame can be used and such calls are know as tail calls - Executes in constant space - The stack frame size is not increased by adding another function jump
- So, with the GCD example compiler is able to figure that out - Hence, it says, tail recursive - Whereas, factorial is recursive call - So, what’s the harm? It should be fine.
- - Explain the 1st image - Show the problem in the second image - the problem here is because of the JVM stack frame size - Go to next slide
- So, now what? - Do I have to always explode my programs? - No, so now we write tail recursive calls - Go to next slide
- - Explain the example - This is all good but I agree that it make your code a bit complex. So, if you know for sure you won't hit the max stack frame size of JVM then it's always better to use normal recursion
- - Read the points from slide - Similar to the Java interfaces - Offers more than interfaces - only normal constructors - Can't have auxiliary constructors - We'll see example and usage of Abstract type - Use Scala traits as Java Abstract class
- - Before the rigth image - Talk about the diamond problem - Talk about various approaches in other languages - using virtual in C++ while inheriting - Application for a college with various role - Helps in having multiple inheritence - We'll see how it's done in Scala
- - Scala has created strict rules for multiple inheritence - Class hierarchy creates a acyclic graph of inheritence - Because of such strict rules there is no confusion in which function should be called
- - The graph here is for just illustration only - Linearization has a lot to do with the order in which the traits are mixed - Prev example: Derived was extending A and C - Explain the acyclic graph formation - Explain how it will be reduced and then just show the image on next slide
- - Ask if any questions?
- - So, I told that we would be talking about abstract types. Right? - Lets look at this problem here - Explain the problem - Talk about the solution by Anil
- - Explain the solution here - There is more to the abstract types/generics with variance and covariance - I think you get the gist of what Scala can offer in generics - Covariance +A -> pass any subtype of A - For some class List[+A], A is subtype of B then List[A] is a subtype of List[B] - Contravariant -A -> we can pass any parent - Writer[-A]: A is subtype of B, then Writer[B] is a subtype of Writer[A]
- After 1st point Question: - How many of you like switch statements? - if-else/switch - Wherever possible i use cases; reason it looks somewhat good and get rid of extra equality check - Clatter when variable name is large - Traditional for constant value only - 2nd point - Show the examples - Match is a keyword and used as an expression - Must yield a result - No case matches, exception(MatchError) - Go through the slide to show the examples (2 slides)
- - Explain what’s happening
- - Explain what’s happening - Talk about case classes: - Almost like classes with some extra properties - No new keyword req - All case classes have so called companion objects; automatically created - They have apply and unapply methods - If using abstract class like in the example - How to ensure all cases are covered; someone can extend this class anywhere else - Sealed classes: - Need to mention in that file only - cover all possible classes
- - Explain the example - Talk about pattern guard - We will get back to this example later too
- - Truth table for tuple classes - Imagine you writing if-else for this truth table - Code is more concise, clean and readable
- - Question before content - Any idea what do they mean? - Pure Functions work on their argument and yield a result - What if there are result for only range of input - Use if-else but we have to return something for that range right? - show the next content - Talk about the example - Talk about the collection function - Comes in handy for data analysis programs - Various types of data; for the program we are concerned about very specific type - Can’t go on adding if-else right?
- - Guess the type - Explain the example - Show the type Question - What will happen when I uncomment the map function?
- - Error! - Why Error, explain - Lets see how can be do it in a better way!
- - With collect being a PF - I have defined my function only for Ints; Hence the result would be a list of Int - Now, the multiple option is available on Int; hence the result
- - Just for illustration only - Defiining a PF - Last arg is the return type - Remember the example on list, where we had to handle all the cases of Nil and non empty
- - Scala is compatible with Java and it can make use of the vast extensive Java libraries - Being OO, all the advantages are available for us but with a pinch of salt - Usage is different from that of traditional OO Being functional, we have an opportunity to create clear, transparent and complex concurrent applications - Our code becomes: - short - easier to understand - less boiler plate code, type inference - extensive abstraction over data structures - Compose and make your own abstractions and control structures - Being statically typed - Sure about refactorings Scala provides opportunities to build your own DSL - Design you own constructs
- Actors For comprehension Generics Extractors Annotations Self types(cake pattern) to remove DI(Dependency Injection) Currying Type system Type specialization XML Literals DSLs Scripting with Scala Etc.
- - Spark: - It's an OS cluster computing framework - API's to program with implicit data parallelism and fault tolerance - They have this concept of RDDs(Resilient distributed dataset), which are immutable in itself - All you can do with the dataset is to transform it or apply some actions on it - Hence, they are inherently parallel and fault tolerant - Generally, used in Data analysis needs - Akka: - If your business needs is to have many concurrent tasks and they have to synchronize between each other, then AKKA is you one-stop destination - Set of OS libraries to design scalable, resilient systems that span across cores and network - Gone are the days of low level mutex, atomics or locks - All the overhead of handling concurrency is taken care by it - Their core concept is Actor model, adhering to some simple pattern we are easily able to write transparent and concurrent code - There are many packages - FSM (I'm using this in my project) - Akka Routes - Akka Cluster - Akka Persistence - Akka Streams - All of them are based on Actor model - So, you guys go and read about Actor model - Play - How many of you have build Java web applications? - This is something for you guys to explore - Framework for building web applications using Scala and Java written in Scala - It's also builtN on Akka - It's totally stateless - Integrated unit testing; support for JUnit and Selenium
- - There are many big players who are using Scala - So, if you look at the future of Scala, I think It's just warming up before the actual the actual game!!