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.

1. Language
Design
Trade-Offs
andrey.breslav@ .com
is

2. Simply Universal

3. Full of Shortcuts

4. Simply Universal

5. Full of Shortcuts

6. Trade-Off #0
Elegance Convenience

7. Time
Complexity
1968

8. Cool Practical

9. Clever Readable
Simple Fast
Shiny New Good Old
Ground-Breaking Compatible

10. Shiny New Good Old

11. As Java Evolved…
Foo<? extends T>
new Foo()
new Foo<T>()
new Foo<>()
SAM-Conversions
Default
methods

12. Lambdas & SAM-Conversions
void foo(Function<? super Bar, ? extends Baz> g)
SAM-type
foo(g -> new SubBaz(g));

13. Compatibility
is a drag,
son…

14. Simple Fast

15. Boxing for Primitives
new Foo()
The Age of (Auto)Boxing

16. Language
Runtime
JIT
x86 amd64 ARM
GC
x86 amd64 ARM
Threads
Linux Windows Mac
Hard
Very
Hard

17. Ground-Breaking Compatible

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. 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. Safe Compatible
Cool Collections JDK Collections
catch errors early
self-documenting code
no wrapping/repackaging
existing API’s work
Intuitive ? extends Foo
print(List<? extends Foo> foos)print(foos: List<Foo>)

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>
Kotlin
Collections
JDK
Collections

22. Kotlin Collections = &
Safe
Compatible
Co-variant

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. 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. JAR File
class Foo {
String getName() { … }
}
Nullable or Not?
<XML/>
@NotNull
KAnnotator

26. Dynamic Static

27. Library
Locked
*Util class

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. Ugly Interfaces Ugly Code

31. 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]
}

32. Access privates No
Virtual No
Owner Package
Many Applicable Overloading error
Member Clashes Member wins
= static utility

34. Theory Practice

35. Java new List<String>()
Collections.<String>emptyList()
Why different?
Scala new List[String]()
emptyList[String]()
arr(0)
Why square brackets?

36. foo(bar<A, B>(x + 1))
foo(bar < a, b > (x + 1))

37. Java Familiar (from C++)
Sometimes ugly
Scala Always pretty
Unfamiliar
C# and
Kotlin
Familiar
Always* pretty
emptyList<String>()
* foo((bar < A), B > (x+1))

38. Practice
is nicer than
Theory

39. Language
Design
Trade-Offs
andrey.breslav@ .com
is
kotlin.jetbrains.org