Dynamic Swift • Hacker News Board

Re: Dynamic Swift

#21

Post by comex » Mon, May 23, 2016, 5:49 AM UTC

catnaroek wrote: post #19

comex wrote: post #12

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 = serverObj…

> It's certainly slower. 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.

Actually, I feel a bit silly and maybe confused, as the 'setProperty' I mentioned at the end of my last post is... just reflection. Which Swift already has, in the form of Mirror. The only reason the Objective-C runtime is needed for that example is that Mirror apparently only allows you to get the values of properties, not set them, but that just sounds like an implementation limitation that could easily be lifted - clearly built-in reflection is considered within the scope of Swift.[1] So it's a bit odd for Brent Simmons to put this in a list of things he's "nervous" won't be possible in the future, and not even mention reflection. Most of the other things in the list seem like they really aren't possible without Objective-C or, in its stead, new Swift features. (They could still be done with macros!)

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...

Re: Dynamic Swift

#22

Post by pjmlp » Mon, May 23, 2016, 6:35 AM UTC

refulgentis wrote: post #8

chris_7 wrote: post #6

Not sure I see what's going on here (it's just a blog post linking to other blog posts?), but is this arguing that Apple should turn the safety of Swift back into the unsafe mess of Objective-C? Horrifying stuff like swizzling, respondsToSelector tricks, etc.? That's what Swift is trying to get away from! Some of the classes in Apple's frameworks need to be overridden, some of them cannot be overridden, some of them…

The Objective-C old guard has had a very hard time dealing with Swift. For a couple years now, every 3 months they have another blog post hand-wringing about what they used to do in Objective-C, how they can't in Swift, with the implicit warning this is worrisome and _needs_ to be reimplemented in Swift, or Swift isn't a serious contender long-term. Most of the of the community seems to have moved on, with the unders…

Many geeks seem to forget that development time equals developer time, expressed in money per hour.

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.

Re: Dynamic Swift

#23

Post by Someone » Mon, May 23, 2016, 7:21 AM UTC

comex wrote: post #12

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 = serverObj…

"For example, he states that the following code is tedious to write and error-prone"

Error-prone, indeed:

    if localObject.bar != serverObject.bar {
      localObject.*foo* = serverObject.bar
      changeDictionary[barKey] = serverObject.bar
    }

:-)

Re: Dynamic Swift

#24

Post by alehander42 » Mon, May 23, 2016, 9:13 AM UTC

supster wrote: post #5

adamnemecek wrote: post #4

"Great web frameworks like Ruby on Rails, for example, can’t be built without relying on a more dynamic language." You don't necessarily want dynamism, you want metaprogramming.

Interesting, could you provide some examples?

A lot of Rails/Ruby magic hides in the dynamic "generation" of code and in the nice DSL-s. However you can typically achieve the same using e.g. macros (which work on compile time) and which can be even statically typed.

The DSL thing is orthogonal: it's more related to the language syntax than to the type system.

Re: Dynamic Swift

#25

Post by dottrap » Mon, May 23, 2016, 10:42 AM UTC

chris_7 wrote: post #6

Not sure I see what's going on here (it's just a blog post linking to other blog posts?), but is this arguing that Apple should turn the safety of Swift back into the unsafe mess of Objective-C? Horrifying stuff like swizzling, respondsToSelector tricks, etc.? That's what Swift is trying to get away from! Some of the classes in Apple's frameworks need to be overridden, some of them cannot be overridden, some of them…

What's going on here is Brent Simmons has been posting a series of blog articles expressing concern that very useful dynamic features used in Obj-C to great effect cannot be currently done in pure Swift. And many of the old guard that is knowledgable in how Obj-C+Cocoa is implemented and have built their own powerful things on top of it are also expressing their same concern that Swift has not addressed how these things are going to be done without Obj-C.

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.

Re: Dynamic Swift

#26

Post by drewcrawford » Mon, May 23, 2016, 10:46 AM UTC

refulgentis wrote: post #8

chris_7 wrote: post #6

Not sure I see what's going on here (it's just a blog post linking to other blog posts?), but is this arguing that Apple should turn the safety of Swift back into the unsafe mess of Objective-C? Horrifying stuff like swizzling, respondsToSelector tricks, etc.? That's what Swift is trying to get away from! Some of the classes in Apple's frameworks need to be overridden, some of them cannot be overridden, some of them…

The Objective-C old guard has had a very hard time dealing with Swift. For a couple years now, every 3 months they have another blog post hand-wringing about what they used to do in Objective-C, how they can't in Swift, with the implicit warning this is worrisome and _needs_ to be reimplemented in Swift, or Swift isn't a serious contender long-term. Most of the of the community seems to have moved on, with the unders…

So, I'm deeply involved in Swift, in the sense that: I write the odd compiler feature.

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.

Re: Dynamic Swift

#27

Post by andybak » Mon, May 23, 2016, 12:36 PM UTC

ebbv wrote: post #16

I don't want to call someone I don't know a bad developer, but as a general rule if software is moving more towards safety and reliability and you are resisting that change that's a sign there's a problem with your habits and preferences. Not that the decisions being made are bad. 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 suppo…

> if software is moving more towards safety and reliability and you are resisting that change that's a sign there's a problem with your habits and preferences

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.

Re: Dynamic Swift

#28

Post by chris_7 » Mon, May 23, 2016, 1:28 PM UTC

drewcrawford wrote: post #26

refulgentis wrote: post #8

Earlier quoted context omitted.

The Objective-C old guard has had a very hard time dealing with Swift. For a couple years now, every 3 months they have another blog post hand-wringing about what they used to do in Objective-C, how they can't in Swift, with the implicit warning this is worrisome and _needs_ to be reimplemented in Swift, or Swift isn't a serious contender long-term. Most of the of the community seems to have moved on, with the unders…

So, I'm deeply involved in Swift, in the sense that: I write the odd compiler feature. 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…

Other than "we want to rewrite Foundation/XCTest in Swift", why do we need XCTest or NSCoding implemented in Swift? Neither is particularly Swifty - many things in Foundation that ought to be structs are classes, for example, and there's the nonsensical duplication of String/NSString/NSMutableString and the other containers.

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.

Re: Dynamic Swift

#29

Post by chris_7 » Mon, May 23, 2016, 1:39 PM UTC

dottrap wrote: post #25

chris_7 wrote: post #6

Not sure I see what's going on here (it's just a blog post linking to other blog posts?), but is this arguing that Apple should turn the safety of Swift back into the unsafe mess of Objective-C? Horrifying stuff like swizzling, respondsToSelector tricks, etc.? That's what Swift is trying to get away from! Some of the classes in Apple's frameworks need to be overridden, some of them cannot be overridden, some of them…

What's going on here is Brent Simmons has been posting a series of blog articles expressing concern that very useful dynamic features used in Obj-C to great effect cannot be currently done in pure Swift. And many of the old guard that is knowledgable in how Obj-C+Cocoa is implemented and have built their own powerful things on top of it are also expressing their same concern that Swift has not addressed how these thi…

> Responder Chain

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.

Re: Dynamic Swift

#30

Post by eunoia » Mon, May 23, 2016, 2:21 PM UTC

chris_7 wrote: post #28

drewcrawford wrote: post #26

Earlier quoted context omitted.

So, I'm deeply involved in Swift, in the sense that: I write the odd compiler feature. 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…

Other than "we want to rewrite Foundation/XCTest in Swift", why do we need XCTest or NSCoding implemented in Swift? Neither is particularly Swifty - many things in Foundation that ought to be structs are classes, for example, and there's the nonsensical duplication of String/NSString/NSMutableString and the other containers. If you want a Swifty testing framework, just pass a bunch of test functions to a function, or…

> why do we need XCTest or NSCoding implemented in Swift?

Linux compatibility. As long as Foundation is written in Obj-C it can't be ported.