The posts in the first linked series (
http://inessential.com/2016/05/) seem to mostly focus on how dynamism can avoid the need for boilerplate. For example, he states that the following code is tedious to write and error-prone:
if localObject.foo != serverObject.foo {
localObject.foo = serverObject.foo
changeDictionary[fooKey] = serverObject.foo
}
if localObject.bar != serverObject.bar {
localObject.foo = serverObject.bar
changeDictionary[barKey] = serverObject.bar
}
But there's another language feature that can replace boilerplate,
without dynamism and its associated performance and type safety penalties. A feature that's reviled by many, and was omitted from Swift, but serves this purpose perfectly: macros. What if you could write this?
macro_rules! merge {
($localObject:expr, $serverObject:expr, ($($prop:ident),+)) => {
$(
if $localObject.$prop != $serverObject.$prop {
$localObject.$prop = $serverObject.$prop;
changeDictionary[stringify!($prop)] = $serverObject.$prop;
}
)+
}
}
merge!(localObject, serverObject, (foo, bar, baz));
Actually, this is valid Rust code, as you might have guessed if you know that language. I picked it because it has similar syntax to Swift and a powerful, hygienic macro system. (This case is simple enough that a C macro would also work fine without any ugly arcane stuff - you'd have to have a separate macro invocation for each property, but whatever. But Rust's system scales better to slightly more complicated scenarios.)
Admittedly, not everything you can implement with dynamism is as easy to replace with macros. Many things are essentially impossible with the simple pattern matching language used above. In Rust, there is also the option to write a compiler plugin that can do arbitrary-ish things with ASTs, so almost anything is possible with enough work, including things you can't implement with dynamism, but fiddling with AST transformations is hairy enough that boilerplate looks a lot more attractive, relatively speaking.
Even so, I bet macros would satisfy most of the people advocating for "Dynamic Swift". And for the people who hate them - do you really think doing crazy things at runtime is any safer or easier to understand? It's certainly slower.
(By the way, you can implement dynamism with macros. For example, you could autogenerate functions like 'setProperty(name: String, val: Any)' that switch on the name and do the appropriate casting and such. Though depending on your attitude, you might consider this crucial enough that it should be built into the language.)