Swift and Dynamism | Hacker News Reader

Swift and Dynamism

blog.wilshipley.com

86 pointsdchest41 comments

People that don't use a feature (whether it's introspection, dynamic message passing, classes, FP, actors, GC, type systems, etc) saying they won't miss it, tells us something about the person but not necessarily anything about the feature.

Especially if, as was the thrust of many of the articles, they actually are using those features, and quite heavily at that. They just don't see them directly.

Kind of reminds me of the old slogan from the anti-nuclear movement in Germany: "Atomkraft, Nein Danke! Strom kommt aus der Steckdose". (We don't need no stinkin' nuclear power, electricity comes out of the wall socket)

>Kind of reminds me of the old slogan from the anti-nuclear movement in Germany: "Atomkraft, Nein Danke! Strom kommt aus der Steckdose". (We don't need no stinkin' nuclear power, electricity comes out of the wall socket)

Sounds like a hoax slogan (possible from anti-anti-nuclearists). The one I remember was "Atomkraft, Nein Danke!" by itself.

Or perhaps they know what they are doing and have decided they don't need that feature?

Yes, and that they aren't giving enough discussion to the universe of situations and whether given that universe, the trade off of feature inclusion or exclusion is worth it. There may be a fitter initial frame of discussion for language policy than focusing on your situation. At the very least, if you argue broadly, then you should give a clue about why you think your case is a sufficient proxy for the general case.

That is totally orthogonal to what the parent said.

They could know what they are doing, or they could be blathering idiots. Or, possibly, their use cases might be different than another person's.

Whatever the case, by just saying that they "won't miss feature X", they still tells us something about them but nothing about the feature.

To do the latter, they'd have to up their argumentation.

Personally I don't understand why strong reflection support has been left out of Swift.

I can understand that there is probably a problem related to ARC and garbage collection. But missing this set of features means that there are lot of things that simply cannot be implemented in Swift and thus having remain in Objective-C (Core Data, other ORMs, IoC-frameworks etc.).

That means the iOS/OSX-platform will continue to be split in two programming languages and object-models for the foreseeable future.

>I can understand that there is probably a problem related to ARC and garbage collection.

I don't think so, since Objective-C also uses ARC and is very dynamic. I'd say the typesystem/runtime of Swift might have more to do with it.

While there are almost certainly other considerations as well, ARC definitely makes Objective-C much less dynamic.

The Objective-C compiler gets significantly more strict with ARC turned on, for example sending unknown messages is an error instead of a warning. Various runtime functions that used to be quite safe also become dangerous, for example it used to be OK to send performSelector: style messages with non-object returning messages (void) and simply ignore the result. That now becomes a crash as ARC tries to retain the return value. So in order the be compatible with ARC, the "cheap and cheerful" reflection that ObjC has isn't really sufficient.

ARC is predicated on the compiler having essentially a statically checkable call-chain.

>That means the iOS/OSX-platform will continue to be split in two programming languages and object-models for the foreseeable future.

iOS/OSX has been split into multiple languages for a long time, anyway. The C/C++-based framework subsystem has produced many others..

This is a very strong endorsement:

> I am better Swift programmer after a year and a half in Swift than I was in Objective-C after 26 years.

He skipped over KVO, KVC and related reflection capabilities of Objective-C that make it so flexible.

I like and use swift, but I haven't reached a point where a lightbulb went off and I proclaimed "Hey I needed this".

> I haven't reached a point where a lightbulb went off and I proclaimed "Hey I needed this".

You don't feel more productive in swift? Like a lot more?

No.

EDIT: Just the compile times alone drive me batshit. That doesn't mean that there aren't nice aspects, certainly some of the syntax has been simplified by unifying two disparate syntaxes...but they could have done so much better, even there.

KVO is horrendous. KVC is occasionally nice but often greatly overused. I certainly wouldn't miss either one.

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

http://blog.metaobject.com/2016/05/what-missing-in-discussio...

See also: The Siren Call of KVO and Cocoa Bindings http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and...

Yea, I think KVO could be done better. As I recall, Ember properties were pretty neat, and had a nice way of specifying dependencies. A lot less awkward than a bunch of + (NSSet )keyPathsForValuesAffectingValueForKey:(NSString )key methods.

I'd also want more strongly typed keys, less strings everywhere. I do use NSStringFromSelector as much as I can, but strings are unavoidable in IB.

Also the handling of one-to-many dependencies could be made a lot more intuitive as well.

My heart skipped a beat today when refreshing my RSS-feeds. It was like a reunion with your first love. The best of new excitement & old familiarity: Wil Shipley is writing again!

It's nice to hear from someone that's been using Objective-C even longer than me who feels the same about Swift. Only 19 years here.

I must not be 100% up on my acronyms: what is ARC? it's not "Arc" as in "Lisp like language written by Paul Graham et al" of course.

Automatic Reference Counting: https://en.wikipedia.org/wiki/Automatic_Reference_Counting

nevermind, I figured it out.

He's saying that the same team that developed LLVM, clang, and ARC (which most people think are good things for the Apple ecosystem) is also bringing you Swift. So you should feel good that the language is being developed by a team with a good track record that will probably find a solution for this particular issue.

Reply on news.ycombinator.com