Language Design Trade-offs
•
8 gefällt mir•6,523 views
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.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Language Design Trade-offs
Ähnlich wie Language Design Trade-offs (13)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Language Design Trade-offs
- 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));
- 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
- 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
- 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))