Language Design Trade-offs

3,208 views

Published on

If your programming language is small, you’re probably born before 1950, and your first computer was bigger than your present apartment. And even those languages are not so small. One spends quite some time to master a programming language. Why?

Because there are very many decisions “compressed” into the form of a language. Nothing limits a programmer’s imagination like a compiler, and nothing limits a language design like a real world with all of its “legacy”, compatibility concerns, performance limitations, generations-old habits and leaky abstractions.

This talk is about tradeoffs: why we, as language designers, do (or rather did) this and not that.

Published in: Technology, News & Politics

Language Design Trade-offs

  1. 1. LanguageDesignTrade-Offsandrey.breslav@ .comis
  2. 2. Simply Universal
  3. 3. Full of Shortcuts
  4. 4. Simply Universal
  5. 5. Full of Shortcuts
  6. 6. Trade-Off #0Elegance Convenience
  7. 7. TimeComplexity1968
  8. 8. Cool Practical
  9. 9. Clever ReadableSimple FastShiny New Good OldGround-Breaking Compatible
  10. 10. Shiny New Good Old
  11. 11. As Java Evolved…Foo<? extends T>new Foo()new Foo<T>()new Foo<>()SAM-ConversionsDefaultmethods
  12. 12. Lambdas & SAM-Conversionsvoid foo(Function<? super Bar, ? extends Baz> g)SAM-typefoo(g -> new SubBaz(g));
  13. 13. Compatibilityis a drag,son…
  14. 14. Simple Fast
  15. 15. Boxing for Primitivesnew Foo()The Age of (Auto)Boxing
  16. 16. LanguageRuntimeJITx86 amd64 ARMGCx86 amd64 ARMThreadsLinux Windows MacHardVeryHard
  17. 17. Ground-Breaking Compatible
  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 CompatibleCool Collections JDK Collectionscatch errors earlyself-documenting codeno wrapping/repackagingexisting API’s workIntuitive ? extends Fooprint(List<? extends Foo> foos)print(foos: List<Foo>)
  21. 21. Iterable<out T>Collection<out T>List<out T> Set<out T>MutableIterable<T>MutableCollection<T>MutableList<T> MutableSet<T>java.lang.ArrayList<T> java.util.HashSet<T>KotlinCollectionsJDKCollections
  22. 22. Kotlin Collections = &SafeCompatibleCo-variant
  23. 23. Java String s = null;s.length();Errors At RuntimeKotlin val s: Strings.length()val s: String? = nulls.length()Errors At Compile Time= nullNullabletype
  24. 24. Check and use val s: String? = …if (s != null) {s.length()}Check and exit if (s == null) returns.length()Rock’n’Roll s?.length()
  25. 25. JAR Fileclass Foo {String getName() { … }}Nullable or Not?<XML/>@NotNullKAnnotator
  26. 26. Dynamic Static
  27. 27. LibraryLocked*Util 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 NoVirtual NoOwner PackageMany Applicable Overloading errorMember Clashes Member wins= static utility
  32. 32. Theory Practice
  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 uglyScala Always prettyUnfamiliarC# andKotlinFamiliarAlways* prettyemptyList<String>()* foo((bar < A), B > (x+1))
  36. 36. Practiceis nicer thanTheory
  37. 37. LanguageDesignTrade-Offsandrey.breslav@ .comiskotlin.jetbrains.org

×