Comment by cwp | Hacker News Reader

Comment by cwp | Hacker News Reader

Parent Full thread

Yes, but...

Often better libraries and tools can only be built on a better language. That's easy to say and very, very difficult to pull off, but when it happens the result is like magic.

I recently encountered this when I was getting into the nix package manager. At first I thought it was ridiculous that they had invented a whole new language just to describe packages. It was a lazy functional language at that, obviously an exercise in academic preening. Boy was I wrong. Because it's lazy you can have a program that describes a whole Linux distribution, and only run the parts that are necessary for the task at hand: installing nginx or whatever. Outside core they use all sorts of non-trendy languages, but the core is written in a new language with carefully-designed characteristics.

The result is amazing, as much of an advance as going from manual to automatic memory management.

It seems to me that the OP's complaint is that Swift wasn't designed to make better libraries and tools possible, but rather to work well with the ones we already have.

>Often better libraries and tools can only be built on a better language.

Precisely. For example, a lot of Cocoa these days relies on dictionaries and/or stringly-typed identifiers: KVC, KVO, Bindings, Archiving, CoreImage attributes, CoreData's interface to the database etc, etc. Autolayout also uses a separate string-based language.

There are a lot of problems with this approach, not the least of which are performance, code bloat and lack of any kind of compile-time checking.

Polymorphic Identifiers[1] in Objective-Smalltalk[2] are an attempt at addressing these issues (and others). The paper shows why you actually need a small amount of language support to successfully build libraries that address these issues.

I wish I could complain about how Swift's approach to these issues is so much inferior to mine (grin), but there just isn't anything at all. If anything, support for solving these sorts of problems is thinner than in Objective-C. Yikes!

Another issue is the large-scale structure of applications...their architecture: target/action, delegates, bindings (again), notifications, view-controller segues etc. are all architectural connectors, and a large part of what makes Cocoa so powerful. However, these types of connections (-> configurations) can only be described in ad-hoc ways in code, or in a different ad-hoc way in IB. Various inspectors of a GUI builder are not really the proper place to describe the overall architecture of your program.

There have been many systems/languages for describing such high-level architectures, for example ArchJava or ACME. In Swift? Crickets.

When direct language support for a feature is not present, dynamic messaging has been a great way of making library features available as if they were built-in language features. Swift makes this harder or downright impossible.

> Swift wasn't designed to make better libraries and tools possible

Yep. In fact, it's arguably a step back even compared to Objective-C. Which is sad.

> but rather to work well with the ones we already have.

Except that it doesn't really work all that well with existing ones either. Objective-C interop seems to clearly be marked "legacy", with the default apparently non-interoperability.

[1] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...

[2] http://objective.st/

On the flipside, it could be that Apple is laying the groundwork (as they tend to do) to evolve these more advanced features into the language. One could imagine Swift becoming quite divergent from Objective-C in the future, but for the initial release it would have been foolish for any number of reasons to try to introduce anything other than a small step forward from Objective-C.

Yes, I was hoping for this as well, and yes, taking it in small steps is probably the right approach.

Alas, the steps Swift is taking all seem to be going in the opposite direction: more compile-time, more strictness, less dynamicism. As has been written before: Swift is not a better Objective-C, it is a better C++.

I really hope I am wrong about this, but given the current direction, the expressed philosophy and values as well as the predilections of the people involved, I don't see the direction changing from the initial vector.

There is no less dynamicism in swift than in objective-c. What there is, is a replacement for the C. Which is precisely what they said they were going to do. C, of course is not dynamic, and the replacement is not either.

I'm not disputing the idea that instead of replacing the C, Swift's designers could have focussed on enhancing the message passing component, but I would argue that doing so without also replacing the C would have been a mistake.

Perhaps the dynamic elements will also be overhauled over time.

>There is no less dynamicism in swift than in objective-c.

Huh?

"Requiring dynamic dispatch is rarely necessary."

"The bad news is that, by default, your objects will no longer work with KVO or swizzling. If the designer of a class doesn’t anticipate a reason for a particular method or property to be dynamic, that lack of foresight gets baked in at compile time."

etc.

See http://mjtsai.com/blog/2014/08/18/its-a-coup/

If that is not correct, I'd love to hear about it!

> Swift's designers could have focussed on enhancing the message passing component,

That would have been great.

> doing so without also replacing the C would have been a mistake.

Absolutely. But really they've replaced the "Objective" and enhanced the C. After all, Objective-C is a blend of Smalltalk and C. If you remove the C, what is left?

>Perhaps the dynamic elements will also be overhauled over time.

Maybe. So far, that "overhaul" seems to be mostly de-emphasis, deprecation and removal. :-(

Swizzling can't be mentioned with a straight face in an argument about brittleness.

But, I'll concede that KVO won't work with arbitrary properties of binary libraries you receive or that Apple builds into the platform, assuming they use swift and choose not to mark them dynamic.

So in this sole regard, swift is less dynamic.

I guess it remains to be seen whether this actually becomes a problem.

Reply on news.ycombinator.com