Dynamic Swift
mjtsai.com
mjtsai.com
Some of the classes in Apple's frameworks need to be overridden, some of them cannot be overridden, some of them don't both to call their overridden accessors - it's a mess! You can only discover this stuff by reading the documentation (if it's even there), when it ought to be enforced by a strict compiler.
Most of the of the community seems to have moved on, with the understanding that of course you can't reimplement performSelector/KVO/(insert dynamic, non-type safe feature that usually just bites you in the ass in the long run) from scratch, but we still have Objective-C that already implemented those features, and we will have it for years, if not decades, to come. Maybe Apple doesn't have to open source UIKit to prove their commitment to Swift (a short, albeit slightly unfair, summary of a blog post last week from another member of the old guard)
There seems to be a general lack of imagination, and lack of understanding that Apple would never rewrite UIKit or other large, existing frameworks in Swift. But, once Swift is more stable in a year or two, maybe you start thinking about new frameworks being written in Swift, with Objective-C compatibility, instead of vice versa.
Maybe you can't write Rails in Swift, but by god, why would you ever write Rails again? There's been two heavily up voted stories here in the past two weeks describing how awful it is to have a career dependent on a framework so dependent on dynamic untyped code. That matches exactly with my experience being pressed into service writing Rails code for a couple months - the development experience felt like the Stone Age compared to Swift, even if I could write a method ~20% faster.
Me, too. At work, I am on two different projects at the moment: an SDK and application written in Swift, and a run-of-the-mill Rails app.
Going back to the Rails app is frankly gut-wrenchingly bad. Every aspect of coding and debugging — and especially refactoring — is so much worse when doing it in ruby.
The strength of Swift type system makes the tools so much better, and at least for me, it's easier to code in it and reason about it effectively (even if yes, you do type more letters).
But, I want to point out: the same is not true of Objective-C. Even though it has a lot of dynamism under the covers, coding in Obj-C in Xcode is much closer to coding in Swift than Ruby. It's only in 'special cases' that you would really use an untyped object reference. So the compiler is able to catch a huge number of errors at compile time, the editor knows what type your variable is so autocomplete is intelligent, etc.
I do like Swift better, but coding in Obj-C is much closer to Swift than Ruby in terms of the tooling experience, and in terms of how much dynamic untyped code there actually is in a program. Modern Obj-C is "mostly typed", and swizzling and weird object casting are seldomly done (usually only in a tricky situation, which is when you appreciate the ability).
Because it just feels good, is never a business value to spend money on.
Yet, every company gets criticized for not doing "it feels good" development to replace a framework that is stable and doing its work.
I don't do Apple platforms professionally, but on my side of the fence, other companies get that same time of bashing.
Yet given the amount of Swift vs Objective-C content at WWDC 2015, and now the upcoming WWDC 2016, Apple is more than fully committed to Swift.
From my vantage point it seems to be the opposite of your analysis. While it is true that ObjC's dynamism has all kinds of problems we want to avoid, we're also running into lots of cases where the obvious solution is dynamism, and the other solutions aren't obvious.
One concrete example I can offer you is NSCoding, which is being reimplemented right now in corelibs-Foundation. That API pretty much needs a way to look up classes at runtime, (there's really no other sane way to provide the feature). You could argue that we don't need NSCoding (in fact that was argued), but ultimately, we decided we needed NSCoding more than not. So Swift 3 adds a `_typeByName` API which does dynamic lookups of classes by string. It landed, it exists, the ship has sailed.
Another concrete example that may be interesting is XCTest. The way XCTest works is your unit tests are written as functions on a class, and we "discover" the tests by enumerating the functions at runtime. But oops, Swift has no way to enumerate functions at runtime, so we can't find any of your tests. The solution to this problem is actually pretty interesting: the latest proposal is to do sourcecode analysis from the compiler to enumerate your test functions, dump that somewhere, and then generate a second program that uses the dump to call the enumerated functions.
Now that is very interesting, and certainly less dynamic than ObjC (e.g. no method_exchangeImplementations and other nonsense), and I would argue quite a lot saner for the scope of the XCTest problem. But it follows easily that as soon as we do that we could emit a program that uses that same function enumeration to emit a giant switch statement that does dispatch-by-string. Of course it would be opt-in, so only callers that wanted it would use it, but there's nobody to stop you.
All of that to say, I think what is actually happening inside Swift is we're coming up with more structured kinds of dynamism, rather than a knee-jerk reaction against the ObjC philosophy. ObjC's model certainly has its issues, and we have gotten surprisingly far without really much dynamism at all. On the other hand, Swift constantly hits cases that are "solved" by ObjC's dynamism, those are definitely real (doesn't get more real than the core libraries), and dismissing them out of hand would be stupid. Meanwhile it takes time to come up with solid "structured" approaches to all the various cases people use dynamism in the wild, so it will be a long process of enabling more and more kinds of dynamism over time.
As for the ObjC runtime, we will not actually have it for years. Maybe on Apple platforms. But the decision has been made not to ship it for Linux, and Linux is of course the next big frontier for Swift. All code that wants to run on Linux (or run on both platforms) better not use the ObjC runtime for anything ever. So this places increasing pressure on designers to figure out what our answer to all the dynamic usecases will be, because there is no seatbelt to save you on one of our platforms.
Basically, I would very much not be dismissing these critiques out of hand. They are not (other than a few) arguing for a return to ObjC. But they are raising issues not seriously solved by Swift at present, and we need to be uncovering those and putting in the design effort to generate solutions for them.
If you want a Swifty testing framework, just pass a bunch of test functions to a function, or define a test case protocol. Similarly, a coding-style protocol can be represented as an encoded associatedtype and encode/decode functions. Plus, you can throw in the decode instead of having to return nil with no explanation.
Linux compatibility. As long as Foundation is written in Obj-C it can't be ported.
What I meant to communicate was that there's a histrionical air to most of the commentary that is unfounded. We don't need to be able to reimplement Rails, or KVO, or Core Data – we need to come up with new ways to solve those problems with an approach like you're seeing working in practice, a more structured dynamism. And for what it's worth, all of those problems deserve another try at an answer. They're some of the most tricky parts of the platform.
Speaking narrowly about the XCTest case:
* It doesn't actually require runtime dynamism (since you have a finite number of tests that can be statically enumerated). Following the principle of least power, don't do it if you don't have to.
* A runtime-dynamism-based solution would require `dynamic` sprinkled on function definitions which would be a departure from source compatibility with Darwin XCTest which relies on the superclass and @objc inference on methods.
* Mirror offers reads but not writes, and there is some sense that offering the ability to mutate through Mirror is uncharted design territory.
Then there is debate about whether other "dynamic" cases can also be solved with static analysis. I am in the "probably not all of them" camp, but that still leaves some of them, and it would be good to study that boundary condition in more detail.
With sufficiently robust static analysis you "can" implement your mirror trick for example (by code-generating a bigass extension to Mirror that just returns statically-analyzed data). Somebody will do that, and so I think upstream will be following how well it works out for them and letting the larger community build the case for or against the feature.
When there is widespread discussion of a certain topic in the Mac/iOS programming community, Michael Tsai is well known for posting collections of links to important discussion of that topic, as he has done here.
These are mostly grizzled Objectrive-C veterans writing. They have dealt with the messy legacy for years, but they also leverage the dynamism of Obj-C/Cocoa to solve a ton of real problems.
Personally, I really like Swift. After 15 years of Objective-C programming, I probably won't do more than few more hours of it over the remainder of my life. But, I understand where these guys are coming from, and it's interesting to read about the problems they are having.
This totally isn't a "language war", but if you look at it that way, it is one of the most fascinating ones.
It's not just comparing and contrasting two programming languages arbitrarily, in theory; it's an energetic discussion among accomplished working programmers about real-world work in the only two languages that can feasibly be used for the platforms they are on. Super interesting.
Quotes:
"many of these dynamic features are definitely hacks, with various issues"
"[Objective-C] is a bad design, as far as metasystems are concerned"
"The solution to bad metasystems is not to ban metasystems, it is to design better metasystems that allow these things in a more disciplined and more flexible way."
"The point is that these problems will need solving in a possible future world without the Objective-C runtime. These kinds of problems should be considered as that world is being designed. The answers don’t have to be the same answers as Objective-C — but they need to be good answers, better than (for instance) writing a script to generate some code."http://inessential.com/2016/05/18/what_im_doing_with_these_a...
There are key technologies in Cocoa like the Responder Chain, NSUndoManager, Key-Value-Coding/Key-Value-Observing/Cocoa Bindings, Core Data, that are made possible due to Objective-C's dynamic features which allows for easy coding and also impressive decoupling.
The concern is that some developers actually need to develop things like this and Swift doesn't offer anything comparable. Additionally, as Swift enters new platforms where Obj-C doesn't exist, or if Apple kills off Obj-C support, there is no obvious replacement for those who want/need to build systems like Cocoa. For right now, Swift is a good consumer of Cocoa, but not something you could implement Cocoa with.
Protocols, or even a superclass.
> NSUndoManager
Closures. Even Apple has moved away from target/selector for new APIs in favor of blocks.
> Key-Value-Coding/Key-Value-Observing/Cocoa Bindings
An equivalent is easily implementable in pure Swift, see ReactiveCocoa's PropertyType/MutablePropertyType, and I'm sure someone has packaged something similar as a µframework so that you don't need to add all of RAC.
> Core Data
This one is actually hard, as it relies on dynamic generation of implementations, instead of using that to solve a different problem, as is the case with KVO. I'm willing to toss Core Data overboard to gain the safety and productivity of Swift, but YMMV.
Here's two on just the Responder chain: http://inessential.com/2016/05/17/responder_chain_followup http://shapeof.com/archives/2016/5/dynamic_swift.html
The bigger point (which is in that first Brent Simmons link) is that people have built all sorts of frameworks and tools over the past 20 years depending using of the dynamic features of Obj-C. Some are Apple's like all the above plus others like Interface Builder and XCTest, but other people have built their own things too that rely on the same concepts. How do these people move forward in a Swift world?
None of these people are arguing that Swift is terrible and going back to Obj-C. They are trying to use Swift. They are only interested in solving the problems they have (and well). When Swift fails to solve a problem or is far worse than its predecessor, there is a problem.
Not everybody can nonchalantly throw their stuff overboard like you are willing to do with Core Data.
UIResponder can have implementations of all the methods that return NO. You override whichever you want to, and return YES. Then, instead of checking if a selector exists and then invoking it, the system just calls the method, and if it returns NO, it moves on to the next responder in the chain.
What am I missing?
What these posts talk about is the expressiveness of a metasystem, and they are generally agnostic about whether this metasystem is static or dynamic, just that it should not be less expressive than the current dynamic one.
I suspect the solution is something as simple as a "DangerouslyCallMethodByName" method.
if let method = classInstance.methods[methodKey] {
//Put some ugly method argument checker thing here
method.execute()
}
You don't necessarily want dynamism, you want metaprogramming.
The DSL thing is orthogonal: it's more related to the language syntax than to the type system.
https://msdn.microsoft.com/en-us/library/dd264741.aspx
C# does an excellent job of bridging dynamism and hard types.
The use of the dynamic keyword ensures that you know you are bridging to an area where the "." is not type checked, and is strictly evaluated at runtime.
There may be too many hooks into the reflection area of C# / .NET, however that can be mitigated in other ways within the confines of Swift.
Could even have an 'if ... let' Swift scheme that attempts to conform an object to a specific dynamic protocol. Example: Define an expected interface as a protocol, then do a 'dynamic if..let cast' which will ensure that all members from the protocol are present on the Swift object.
That's not entirely true; libobjc2[0] exists, for example, and is fully compatible with objc4.
Swift is not a perfect language, there's a lot of low hanging fruit (some of which is being dealt with in Swift 3), but it's lack of support for dynamic behavior is not one of those problems.
Unless safety and reliability come at the cost of some other metrics that you consider more valuable?
Currently - at least in the HN bubble - it appears that the pendulum is swinging towards static typing and away from dynamic language features. It is surely premature to conclude this is a permanent trend.
I don't tend to agree with those arguments (at least for now, I reserve the right to change my mind again) but I don't think that it's useful to just dismiss them based on their basic shape.
The big trouble with inflexibles types is that work against data manipulation. Data using maybe not, but is a mile easier to do database development in python than in F#.
My ideal setup is a strict-types first and dynamic optional, so I can do:
row = MakeRow()
row?first_name = "Jhon"
row?last_name = "Doe"
row?fullName = fun row:Row -> row?first_name + " " + row?last_name
But still keep the type system everywhere!
fun sum(a, b:Int):Int -> a + b
That infuriate me about F#. I do python, and in both basic code "look the same". But I hate that F# know the types of things but do not tell me! (without a IDE!) and I still need to track down the flow of code to figure out things.
Type inference must be local, imho. Or not at all...
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
}
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));
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.)
That's the least of problems, since nowadays we have smart runtime systems that dynamically optimize running programs. It's not elegant, but it works. A more fundamental problem is that this approach to programming leads to brittle code, and when it breaks, it doesn't warn you until it's too late.
I guess reflection fits into the general category of dynamism even if it is essentially an existing Swift feature.
In any case, to respond to your point: Objective-C does not have a JIT, and since there are a lot of advantages to a pure ahead-of-time compilation model (see the mailing list post linked elsewhere in this thread), as a language mainly focused on static compilation, Swift is unlikely to get one in the future just to deal with hypothetical dynamic features. Anyway, even in the relatively small set of languages that are both highly dynamic (going beyond simple reflection) and well-optimized - there's JavaScript, and LuaJIT I guess? and maybe some less common ones, there's PyPy but I don't call that well-optimized - if you actually use the dynamic features it's easy to fall off the JIT happy path and make your whole function unoptimizable. See [2]. But that's getting off topic.
[1] In making that thinko I showed my lack of Swift experience: in Rust reflection is done with macros.
[2] https://github.com/petkaantonov/bluebird/wiki/Optimization-k...
Error-prone, indeed:
if localObject.bar != serverObject.bar {
localObject.*foo* = serverObject.bar
changeDictionary[barKey] = serverObject.bar
}
I have to agree that there are some pain points with Swift:
- I developed a persistence layer (not Core Data), and had to rely on a "translation layer" that all clients must implement in order to use it. It ends up being about 100+ lines of glue code for each model we want to persist. Not ideal. - Retrieving data from API services and converting the data (JSON) into models results in a lot of glue code... A ton it. - I've frequently had to hack my way around the lack of Generic Protools (using base classes instead). - Compile times suck. Feels like I've been thrown back a decade in this regard.
Despite these issues, not a single one of us would go back to objective-c. Overall, the velocity of our team has only gone up since we started using Swift:
- Type safety and Optionals have removed an entire class of bugs in our app, freeing up more time to write features. - Generics have added a level of clarity to the code base that wasn't even possible before. - The code base is easier to understand, easier to maintain and easier to modify. - Oddly, the need to write Unit Tests and use Swift has literally "forced" us into protocol-based programming...a good thing IMO. I'm seeing much better software architecture as devs can't lean on automatic mocks, forced instead to create protocols and keep classes/types separated and injectable. To be clear, it's more difficult to write that kind of code, but the quality of code has gone up since we switched to Swift.
I've noticed that some of the complaints about the lack of dynamism in Swift don't seem as valid. For example: Responder chains. This is easily done using a protocol (something we did for deep linking within the app).
Other issues, like observability, can be solved by things like React, and using Observables. Not only is React more powerful than KVO, but it's obvious where it's being used in the code base (because you're using an Observable).
I can't deny that there are places where having dynamism would certainly remove a lot of glue code. But my experience is that the "old guard" (me included, really) relied too much on the dynamic nature of objective-c to solve problems that could have been better solved in another way.
While I would like to see dynamism come to Swift, I would NOT want to see it imported wholesale from objective-c, but instead conservatively placed and annotated in such a way as to say to those of us who use it: "Here be dragons...proceed at your own peril".