Thursday, February 11, 2016

Swift Mailing Lists Are Self-Selecting

Jason Brennan:

Generally speaking, if you’re an active participant of the the swift-evolution list, you’re already quite bought in on Swift. This is generally a good thing, since being bought in on Swift means you care a lot about its future, and you have a lot of context from working with current Swift, too.

But by only getting suggestions and feedback about Swift’s evolution from those bought in on Swift, the Swift team is largely neglecting those who are not already on board with Swift. This includes those holding out with Objective C on Apple’s platforms, and those using different languages on other platforms too. These groups have largely no influence on Swift’s future.


And thus, Swift becomes less likeable to these Objective C developers.

4 Comments RSS · Twitter

I take Swift for a spin once a year but so far it's just not particularly appealing. It doesn't fix any of my issues with Objective C and introduces it's own collection of problems to work around.

When I've attempted to provide feedback I've found the Swift community to be disinterested at best, more typically patronising, and occasionally abusive. Whilst I appreciate the enthusiasm, the community's varying levels of hotility to people with a different perspective, whilst thoroughly human, isn't something I want to experience on a daily basis.

@Chris: The core team seems open to constructive criticism, but yeah I've encountered the fanboy types too and they are horribly rigid unimaginative groupthinkers who view any questioning or criticism of their latest messiah language as a direct attack on their egos. Folk like that are evidence that Computer Science is dead, and we should just rename it Computer Religion. They are part of the problem, not the solution.

If holdouts have something new and useful to say about Swift (and have reviewed previous discussions, roadmaps, etc to make sure it hasn't already been addressed) I think your best bit would be to spend some time working with the language yourself to understand your criticism better and check it holds up in practice, then take it straight to the dev team or those closely involved in the platform's development for further discussion, not the general user community.


As to Swift itself, it has some nice bits, but mostly it's just big and bloaty and needlessly convoluted; clearly designed from the compiler up rather than the user down. Thus while it may provide excellent entertainment for compiler devs it falls frustratingly short on UI/UX.

The biggest problem though is that it's too different to ObjC and Cocoa ever to mesh seamlessly with that ecosystem and its particular idioms and semantics, while not being sufficiently different to bring any true killer features to the table that'd justify putting up with the Swift-Cocoa impedance mismatch or even replacing Cocoa altogether.


All of which makes me wonder: Just what is the problem Apple is trying to solve here? Making a slightly better C* language, or making a significantly better OSX/iOS app development platform? Apple would've served their own interests far better by creating a far more conservative "Objective-X" applications-programming language, fusing a "safe C dialect" like Cyclone to their existing OO model, cleaning up the syntax and providing modern conveniences like type inference and full IDE integration.

I hate to say it, but Swift smells just a bit too reminiscent of the pre-Jobs2.0 Apple of the early 90s, where feudal development teams ran amok in the absence of strong board-down direction and control, cooking up thrilling new technologies for their own amusement without actually doing anything to contribute to the company's bottom line. I seriously doubt Swift would have been released under Jobs2.0's watch: he'd have taken one look and responded "That's neat, now go create a language that actually fits the business's needs". So it goes.

My guess is that while Swift was designed to work at least reasonably well with Cocoa, once it's stable Apple will begin writing a more Swift oriented framework to replace the aging AppKit and UIKit. I'm sure they're getting a lot of internal feedback from within Apple on how to do that.

Swift was never means to be a better ObjC from what I can see. So it's somewhat frustrating in the short term for those who want that. It's pretty hard to go fully Swift right now, although it is possible to do a lot in Swift now.

@Clark: Except what's the benefit to offset the huge cost to everyone in replacing all of Cocoa? Because such a massive, radical, and insanely expensive upheaval had better provide at least a 10x improvement in developer efficiency to justify itself, otherwise it's just pissing everyone's time and money down the drain.

For example, if there's one component that everyone agrees would benefit from outright replacement it's Cocoa Bindings, Cocoa Scripting and all the other brittle, opaque, interminable "glue code" crap that makes hooking Views to Models a right old PITA. Replacing all of that with a purely declarative DSL designed specifically for the job would be a major step forward, with clearly-defined boundaries, goals, and rewards that can be reliably budgeted, planned, and delivered.

That's how you move things forward, not this handwavy pie-in-the-sky stuff that makes vague promises of some abstractly brighter future while concretely devaluing the platform they have today. Ask Adam Osborne or Stephen Elop where that road ends up.

Swift won't address the View-Model glue problem any better than ObjC does, because Swift is just another imperative - i.e. "bang the rocks together" - language, by nature incapable of the very high-level automatic decision making that users functional/logic/dataflow/etc declarative languages do for free. If anything Swift takes us in the opposite direction, making it even harder to create small, task-specific languages because now everyone's going to be so heavily tied into Swift that they simply "don't have time" to do things any other way.

Languages are tools we make for solving problems. So exactly what is the problem Swift is made to solve? Because I've been using it for over half a year now and I'm still no closer to figuring out the answer to that myself.

Leave a Comment