> I think that would be the eventual goal, Objective-C minus C. I still think that if your goal was this gradually typed language on top of a dynamic runtime,

> I think that would be the eventual goal, Objective-C minus C. I still think that if your goal was this gradually typed language on top of a dynamic runtime, it would make more sense to start anew and model your language after, say, StrongTalk or (the good parts of) JavaScript/TypeScript, rather than trying to evolve the existing Objective-C language and Clang implementation. I guess I mostly take issue with your characterization of Swift as C++ derived, or consisting of a collection of random features. The designers avoided a lot of the brokenness of C++, such as header files, copy constructors, compile-time instantiation of (what are essentially untyped) templates, etc, and when compared with Objective-C together with the C parts, the language seems mostly well-thought out and orthogonal, even if my personal preference would have been to start with less syntax sugar. I think a better assessment is that Swift is sort of an Ocaml with more C-like syntax, together with some design decisions meant to ease interoperability with Objective-C, such as the choice to go with ARC over GC. So this brings me to what I really wanted to say, which is that I feel like a gross simplification of your overall argument is that "I wanted Strongtalk, and they gave us Ocaml". I understand and respect that point of view, and don't really have a concise rebuttal to offer; it mostly comes down to personal preference. Perhaps if things had turned out the other way, we would instead be hearing a lot of feedback along the lines of, "Why is Apple ignoring the last 20 years of type system research", etc. Another thing that's mostly lost in these discussions is that people lump a ton of mostly independent features under the banner of "dynamic dispatch". In a formal sense Swift has dynamic dispatch, in that you can write a function that call methods on a protocol, passing in different concrete types at runtime. That certainly qualifies in my opinion. I think what is really meant here is the following three capabilities: 1) Write reflection. Right now, Swift actually emits more metadata than Objective-C, in the sense that all values can be reflectively inspected, whereas the Objective-C runtime only knows about classes, and not anything else. For example you can print() any value in Swift and get a sort-of homoiconic representation back, showing the enum case and associated value, or the fields of a struct or tuple, etc. This is implemented with a 'Mirror' type in the standard library which reads this metadata produced by the compiler and presents it as a keyed collection that can be subscripted, iterated over, etc. What's missing here is presenting it as a mutable dictionary, and this can be added without introducing much complexity in the language. 2) Forming dynamic calls and introspecting the methods of a class, or the functions in a module. This is a bit more difficult to design and implement, but I think it can be introduced in a clean way that's sane to use. It's really quite a shame that Java has set the bar so low for such capabilities in a statically-typed language; while all the actual features are there (and you can even synthesize bytecode at runtime), it's incredibly awkward to use, which means developers constantly re-invent frameworks on top of these mechanisms over and over again, but they seem to only obscure the basic ideas further with a soup of FactoryFactories and XML files. 3) Proxy objects dynamically conforming to protocols. Again, this can be statically-typed; starting with a set of closures that implement the requirements of a protocol, the runtime could cook up the right structures to make it appear like an "ad-hoc" instance of the protocol that's not backed by a named concrete type. With the right API this could be quite pleasant and concise. I believe all of these could be added in a clean way that's easy to use, mostly as library features without introducing new syntax or semantics. Their current absence should not be seen as an inherent limitation. Finally, I agree with your point that interactive development is important and should be more of a focus in general. I think it's a shame that since the early 90s or so, programming language research has centered on designing (mostly statically-typed) languages with batch compilers, and not complete "environments" like Smalltalk-80, Self, Lisp machines, etc. It would be good to see more projects explore the latter, and the basic ideas should apply to both static and dynamically typed languages. I like what you're doing with RunKit, by the way -- best of luck there.