Swift Mailing Lists Are Self-Selecting

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.

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.