Locaweb TechTalks 2015 - Seven languages in Seven weeks

Transcript

2. Part I: Why should you care?
3. • First of all.... Why does it matter to learn programming languages anyway ?
4. • First of all.... Why does it matter to learn programming languages anyway ? • I think you should learn programming languages. • But my opinion probably will not matter for you, so listen to these guys instead:
5. These guys think you should
6. These guys think you should
7. These guys think you should
9. • Disclaimer: All the languages to be presented are turing complete, i.e. you can do everything that can be done with a computer in any of them.
10. • Disclaimer: All the languages to be presented are turing complete, i.e. you can do everything that can be done with a computer in any of them. The book (and this presentation) are by no means an exhaustive exploration of the programming languages. Think of them as food for thought.
11. We are going to talk about: • Ruby • Io • Prolog • Scala • Erlang • Clojure • Haskell
12. • What I aim to achieve: – I will try to explain what composes a language and how the same problem is handled by different languages – I expect to show you that a characterization such as “it is function” or “it is object oriented” is insufficient and most of the times inappropriate – I expect you to be convinced that mutable state can be avoided and that this is key to enabling efficient and sane concurrent programming
13. We are going to talk about: • Ruby • Io • Clojure • Scala • Erlang • Prolog • Haskell Support for OOP Support for FP
14. Part 2: A brief view of each language
15. • Ruby: – Object oriented, class based, dynamically typed, strongly typed – Extremely meta-programmable – Complex syntax, complex evaluation rules – Reads like a novel – We all know and love it ;)
16. • Open classes
17. • With great powers, come great responsibilities • You can monkey-patch anything.
18. • Io: – Object oriented, prototype based, strongly typed – Extremely simple and consistent syntax – Heavy emphasis on message passing, not method call. (actually, “method” is a message that returns an object that can receive the message “call”) – Easy to create DSLs – Excellent concurrency primitives – Crazy amount of reflective power
19. • You can do some crazy stuff... Because who cares about scoping!
20. • Futures, coroutines and actors are built in to the language
21. • Scala – OOP, FP, statically typed, strongly typed – Has a powerful type system – Offers advanced FP concepts such as monads and type classes. – You can emulate non-strict evaluation with “call by name” vs “call by value“ paramater passing strategies – Suffers from the Java legacy to a certain extent
22. • Much less verbose and much more expressive than plain ol' java.
23. • Has a strong focus on concurrency
26. • Erlang: – Designed by Ericsson to build telecom software. – Alien syntax, derived from Prolog. – Functional, enforces extreme isolation and share- nothing processes. – No threading model. – Amazing support for fault-tolerant, near-real-time distributed application development.
27. • Erlang: – Offers a somewhat different form of pattern matching:
28. • Example: ultra-simple process monitoring – <code code/7langs7weeks/erlang/gunloop.erl:9>
29. • Clojure: – After Fortran, Lisp is the oldest programming language still actively used. – FP, supports OOP, strongly typed, dynamically typed. – Lisp on the JVM with modern constructs and libraries. – Allows meta-programming with macros. – Not so Lispy: no custom reader macros and no automatic tail call optimization. (schemers be mad)
30. • Clojure: – Although clojure is an strict language, you can simulate non-strictness using macros. – It's possible to define the language on-the-fly, i.e., the language is internally reprogramable (heavy influence in ruby and smalltalk) – <code @ clojure-koans/src/koans/17_macros.clj:29>
31. • Clojure: – Offers the CLOS long forgotten multiple-dispatch:
32. • Haskell: – Functionally pure programming language. – No exceptions and no mutable state (at least the way we are used to) – Extremely powerful type system with parametric types, type class, algebraic data types and type inference. – Offers the full pack of FP crazyness: Monads, Monoids, Functors, Applicatives, Foldables are common language for Haskell programmers. – Much more close to Math, simplifying the way we represent abstract and symbolic constructs.
33. • Haskell: – Currying, partial application and all that nice jazz.
34. • Haskell: – Algebraic data types (or-types): –
35. • Haskell: – Makes it impossible to use mutable state – But allows you to simulate it with Monads – <code @ scheme interpreter>
36. Part 3: An analysis of what I learned reading this book
37. • What does it actually take to learn a new programming language? – Syntax – The programming language's primitives? – Type System (strong or weak? Static or dynamic?) – Evaluation rules (precedence, strictness, etc.) – Idioms – Libraries
38. • Also important: – Meta-programming and extensibility models – Concurrency models – Library distribution – Community (of course!)
39. • Object oriented programming – You can have OOP with no classes. – OOP is about “messages and objects”, not “classes and methods”. – You can dispatch using more than one type. – Class based and prototype based object systems are actually equivalent, and you can represent one in the other.
40. • Polymorphism – Subtype polymorphism is actually pretty poor. Inheritance sucks. – Different paradigms will influence heavily the way you compose the behaviors in your program – Class based OOP lends itself nicely to program organization (one class, one file, internal classes in directories) – There is no such parallel in FP
41. • Functional purity – Buys you a lot, but also takes its toll – With a little bit of effort, you can simulate mutable state where its absolutely necessary. – Functional purity brings referential transparency, lazy evaluation, easy concurrency and makes it easier to reason and compose programs. … but – The density of the languages tend to be higher, and the intellectual load is surely higher too. Not that you can't get used to it, but still...
42. • Concurrency models – One big part of the book – Actually a pretty complex topic to discuss here – There is a lot of ways you can work around mutable state, and each one has its idiosyncrasies – The level of isolation impacts heavily the shape of your program organization and architecture
43. • Pattern matching – Is composed of destructuring + binding – Takes various forms – You can simulate algebraic data types in dynamic languages (and that was mind blowing!
44. • Constraint logic programming – Exists – I actually didn't pay much attention to it. Sorry.
45. • Meta-programming and extensibility – Plays a big role on the practical use of the language. – The more extensible the language is, its more likely that you will encounter better and easier apis in the libraries you work with.
46. Thank you.