I'd argue that the qualifier is unnecessary. It would be uncontroversial to say that a modern car with, say, a lane departure warning system and automatic parking is more complex than the Ford Model T. A complex tool can be nonetheless intuitive to use.
However, while it may be true that an intuitive tool exposes fewer knobs to turn at any one time, to the extent that we seek to understand the tools we use--and ideally this would apply to the scenario of a programmer understanding their programming language--we do need to reckon with that complexity in some form.
Yes, exactly. In that talk I meant to say that the internals of the Swift compiler are more complicated than a C++ compiler. One example: Swift generics have dynamic/reflective ability + static optimization behavior. C++ templates are a comparatively simple preprocessor.
This design choice is intentional, because in many ways it simplifies the programming model for Swift developers. This is a typical example of "Swift compiler engineers suffering for the greater good of Swift programmers" :-) :-)
Agreed, but there are also better and worse implementations of this. To pick on Swift 1 as an egregious example, it exposed a lot of internal implementation complexity onto the user because so many things were unfinished. As the language continues to mature this will get better and less "in your face" . That doesn't neglect the need or desire of some users to learn more about the insides, but these are standard tradeoffs provided by high-abstraction tools. We just need to keep working to make it less of a leaky abstraction.
 To be clear, we still have a long way to go, diagnostics are one prominent example.
In my opinion, Apple messed up when they made Swift 'interoperate' with Objective-C. They should have delayed the release a year and written the most useful Cocoa API in pure Swift. That would have made the language evolve into what it was supposed to be instead of the bloated convoluted complex language that Swift is today. You could even have an app that uses both Objective-C and Swift - but with a much weaker (say message passing only) interoperability layer.
@tomandersen I suspect that their hands were tied to some extent. If you're in a big company and you have a bright idea to do something like move the companies development in a new direction, it's a lot easier to get the money allocated to your idea if you can offer a way to make it seem more palatable to the existing people.
I agree though that in creating a new language, it has suffered as a result of the early need to be compatible. It's still very early days for me and Swift, and having discovered how much it has evolved in just the two years I've been avoiding it, it's clear that the initial design was either compromised heavily, or the intent and purpose of the language has shifted dramatically (highlighting a possible lack of vision).
The simple act of removing something like the ++ operator shows me that the language now is heading in a different direction to what was originally envisaged (C and C++ familiarity is no longer a consideration). I like that these things have been done, but it seems a shame that the language as a construct has suffered this life of mutation. These sorts of decisions should have happened before it was released into the wild.
Swift was rushed out a bit, but most of that was done by developers rushing Swift 1.0 into production apps as fast as they were legally allowed to do that. Some because it was technically exciting... some to help CV’s ;).