Language Design Tradeoffs - Kotlin and Beyond, by Andrey Breslav

1,331 views

Published on

Published in: Technology, News & Politics
  • Be the first to comment

  • Be the first to like this

Language Design Tradeoffs - Kotlin and Beyond, by Andrey Breslav

  1. 1. Language   Design     Trade-­‐Offs   andrey.breslav@ .com is  
  2. 2. Simply  Universal  
  3. 3. Full  of  Shortcuts  
  4. 4. Simply  Universal  
  5. 5. Full  of  Shortcuts  
  6. 6. Trade-­‐Off  #0   Elegance   Convenience  
  7. 7. Time   Complexity   1968  
  8. 8. Cool   PracHcal  
  9. 9. Clever   Readable   Simple   Fast   Shiny  New   Good  Old   Ground-­‐Breaking   CompaHble  
  10. 10. Shiny  New   Good  Old  
  11. 11. As  Java  Evolved…   Foo<? extends T>! new Foo()! new Foo<T>()! new Foo<>()! SAM-Conversions! Default! methods!
  12. 12. Lambdas  &  SAM-­‐Conversions   void foo(Function<? super Bar, ? extends Baz> g)! SAM-­‐type   foo(g -> new SubBaz(g));!
  13. 13. CompaHbility   is  a  drag,   son…  
  14. 14. Simple   Fast  
  15. 15. Boxing  for  Primitives   new Foo()! The  Age  of  (Auto)Boxing  
  16. 16. Language   RunHme   JIT   x86   amd64   ARM   GC   x86   amd64   ARM   Threads   Linux   Windows   Mac   Don’t   touch  it!     Hard   Very   Hard  
  17. 17. Ground-­‐Breaking   CompaHble  
  18. 18. JDK Collections interface List<E> { E get(int index); E set(int index, E value); } Read-only /** read-only */ List<Foo> getFoos() { return unmodifiableList(l); } Errors At Runtime
  19. 19. Cool Collections interface List<E> { E get(int index); } interface MutableList<E> extends List<E> { E set(int index, E value); } Read-only List<Foo> getFoos() { return l; // may be mutable } Errors At Compile Time
  20. 20. Safe   CompaHble   Cool Collections JDK Collections catch  errors  early   self-­‐documenHng  code   no  wrapping/repackaging   exisHng  API’s  work   IntuiHve   ?  extends  Foo   print(List<? extends Foo> foos)print(foos: List<Foo>)
  21. 21. Iterable<out  T>   CollecHon<out  T>   List<out  T>   Set<out  T>   MutableIterable<T>   MutableCollecHon<T>   MutableList<T>   MutableSet<T>   java.lang.ArrayList<T>   java.uHl.HashSet<T>   Kotlin Collections JDK Collections
  22. 22. Rare   luck   Kotlin  CollecHons  =                                &   Safe   CompaHble   Co-­‐variant  
  23. 23. Java String s = null; s.length(); Errors At Runtime Kotlin val s: String s.length() val s: String? = null s.length() Errors At Compile Time = null Nullable   type  
  24. 24. Check and use val s: String? = … if (s != null) { s.length() } Check and exit if (s == null) return s.length() Rock’n’Roll s?.length()
  25. 25. JAR  File   class Foo { String getName() { … } } Nullable  or  Not?   A  hell   of  a  smart   tool   <XML/>   @NotNull   KAnnotator  
  26. 26. Dynamic   StaHc  
  27. 27. Library   Locked   *UHl  class  
  28. 28. Util class Collections2.transform( Collections2.filter( list, (foo) -> foo.isValid()), (foo) -> new Bar(foo))); No Util Class scala.collection.Iterable[T] declares 116 methods
  29. 29. Ugly  Interfaces   Ugly  Code  
  30. 30. Java static char last(String s) Usage “abc”.last() C# static char last(string this) Kotlin fun String.last(): Char { return this[this.size - 1] }
  31. 31. Access privates No Virtual No Owner Package Many Applicable Overloading error Member Clashes Member wins =  staHc  uHlity  
  32. 32. Theory   PracHce  
  33. 33. Java new List<String>() Collections.<String>emptyList() Why different? Scala new List[String]() emptyList[String]() arr(0) Why square brackets?
  34. 34. foo(bar<A, B>(x + 1)) foo(bar < a, b > (x + 1))
  35. 35. Java Familiar (from C++) Sometimes ugly Scala Always pretty Unfamiliar C# and Kotlin Familiar Always* pretty emptyList<String>() * foo((bar < A), B > (x+1))
  36. 36. PracHce     is  nicer  than     Theory   This   Hme  
  37. 37. Language   Design     Trade-­‐Offs   andrey.breslav@ .com is   kotlin.jetbrains.org  

×