Scalawags #25 - Interview with Martin Odersky

thescalawags's podcast

Scalawags #25: Interview with Martin Odersky

YouTube link: https://www.youtube.com/watch?v=uP-m8j8ZN-Q

Your hosts this episode: Daniel Spiewak, Heather Miller, Seth Tisue.

Daniel returns to the show, puts on his enterprise hat, and confesses his dark fetish!

Our guest is Martin Odersky, creator of Scala.

Intro (0:00)

• Josh-less, Dick-less, music-less. our guest this week better be good

Scala eXchange (1:50)

• London. 600 people, standing room only
  • https://skillsmatter.com/conferences/1948-scala-exchange-2014
  • Daniel remembers early on when it was 50 people in a basement
• intro talks, advanced talks pushing the limits of the type system. hopefully not too big a gap in between
• Martin: "the community as a whole is becoming more specialized". Scala plus this or that library

Typed trees and binary compatibility (5:00)

• Martin's keynote at Scala eXchange
  • slides: http://www.slideshare.net/Odersky/scalax
• binary compatibility: it still pesters us
• why don't other languages suffer as much from this?
  • Java is much closer to the JVM and much more conservative about making changes
  • most other languages build from source
• should Scala build from source?
  • but with what build tool?
  • reproducible builds are hard to attain
• new idea: distribute Scala software as partially compiled "typed trees"
  • "it's very simple to go from typed trees to bytecode" or some other back end like Scala.js
  • typed trees compiled from Scala 2.n could be remapped for 2.(n + 1)
  • typed trees are "in a sense a Scala-specific bytecode format... that capture Scala semantics better than Java bytecode"
• where/how will the trees be stored?
• other tools could take advantage of the trees, e.g. optimizers, analyzers, bug finders
• Daniel puts on his enterprise hat: what about code obfuscation? he's also concerned about performance whenever extra information is being carried around
• Seth: perhaps one day, distributing binaries alone will come to seem strange. it should be an optimization, not the default
• Heather: in web development we already have original JavaScript vs. compressed, stripped, optimized JavaScript
• everyone is a bit confused about attributes and annotations

What's it like being Martin's student? (26:15)

• beware Heather, answer carefully!
• all agree: grading sucks
• Daniel rescues Heather by recalling a class assignment to write a Scala compiler in C (?!)
  • and confesses his "dark fetish" for C
  • https://en.wikipedia.org/wiki/Cool_(programming_language)

Scala.NET and Scala.js (34:55)

• will Scala support .NET again?
  • (viewer question from Pablo Perez)
• Martin: "It depends on the community."
  • for the old Scala.NET effort, "there was no community... in the end it became sterile"
• Martin: "I'm in awe" of the Scala.js community, what they've achieved and how much fun they're having
  • http://www.scala-js.org
  • "they even have a really nice book" (by Haoyi Li)
    • http://lihaoyi.github.io/hands-on-scala-js/
• Daniel: the hard part is semantic mismatches between the JVM and other targets
• Martin: one language addition is needed for Scala.js: different handling of pattern matching for numeric types, to reduce boxing
• Seth: why hasn't FP gotten that much traction yet for client work, for UIs?
  • Martin agrees it's a historical accident
  • functional reactive programming ftw
  • Heather: popular JavaScript libraries increasingly reflect functional ideas, e.g. React from Facebook
    • http://facebook.github.io/react/
  • Daniel: on iOS, Cocoa "increasingly approaches FRP"
• Martin: can we sell types to the front-end people?
• Daniel likes the record polymorphism in JavaScript (and OCaml)
• not only doesn't JavaScript have types, it doesn't have a culture of testing, either?

Typelevel Scala (47:35)

• will changes from Typelevel Scala be merged into main Scala?
  • (viewer question from Dan Osipov)
  • http://typelevel.org
• Typelevel's policy is not to break backwards compatibility, so why not?
• "we are working together very well" -- Typelevel can prototype things fast, standard Scala changes take years
• Daniel: Typelevel is discovering how hard it is to change anything without breaking compatibility
  • example: Erik Osheim's work on byte literals
  • example: type lambdas
  • "everything has been hidden behind flags"
• Martin: the Scala community build (1.4 million lines of community code) can help decide whether a corner case is an issue in practice
• popular features in Typelevel Scala could become natural candidates for inclusion in standard Scala

Scala online courses (53:40)

• will there be more Scala courses on Coursera?
  • (viewer question from Jatin Puri)
  • previous courses: https://www.coursera.org/course/progfun,https://www.coursera.org/course/reactive
• potential third course on "parallel programming, parallel transformations". including the distributed computing, Spark. "very early stages, we're not sure yet" when or if
• data parallelism as opposed to reactive

Community issues (55:10)

• Heather: what should the Scala community be doing, what are we not doing, where is the community and where is it heading?
• Martin: it's bigger, there's been some drama, ...
• direction: "transparent, open collaboration" on "fast-moving open-source things"
  • meanwhile, Typesafe is the "backstop" for the enterprise
• comparison with Spark community
• Typesafe's efforts to modularize the standard library to facilitate contributions
  • Martin: hey Daniel, how about that Anti-XML thing?

Modular staging (1:05:05)

• Tell us about lightweight modular staging. Will the Scala.meta project give us staged compilation?
  • (viewer questions from Rúnar Bjarnason and Gabriel Campero [sp?])
• Compilation at runtime, for efficiency
• Lightweight modular staging uses the type system heavily
  • Issues: fragile implicits, slow compile times. Ongoing efforts to improve
• Scala.meta attempts to make these techniques "more digestible". In flux, no clear winner.

Conclusion (1:09:15)

• thanks Martin!