“They've added a fixed-size inline-stored array type to Swift as well as the dynamic heap-allocated one? Why must they make it so complicated, unlike Objective-C" is a form of irony I have been enjoying lately.
There's lots of #Swift content at #FOSDEM this year, starting with @dgregor79 on the main track at 12:00 CET talking about Swift's incremental adoption approach to memory safety.
If you didn't make it to Brussels, you can stream it here:
And later @ktoso will be talking about #Swift / #Java interoperability in the Java room, including how Swift is using the new Project Panama technology for native interop.
Kicking off our #FOSDEM#Swift devroom, @paris has some exciting news. Apple is open sourcing the Xcode build system, with cross-platform support, as swift-build.
The #Swift team at Apple is hiring Windows engineers!
We have a number of roles focused on improving the experience of using the Swift language and tools on Microsoft (and other) platforms. These roles would be based in our City of London office, with two days remote.
Now I'm fully aware that there are plenty of people who still believe this code is better than Swift. But at this point I think they're a tiny minority.
This screenshot demonstrates to me the fundamental core of why Swift strives to be a low-ceremony language. Not because all the ceremony shown here is a hassle remember or type, though it is.
It's that the ceremony drowns out the core of what the code is trying to express: the business logic that is the actually important part.
Over on Blue Sky, @dimillian posted a screenshot of code that stopped me in my tracks. It was just normal Objective-C code that he was considering rewriting in Swift. As he says, "it's not complicated, it's just verbose”.
But Swift still has plenty of ceremony. And it continues to evolve. Generics for example started off much more verbose. Swift 1.0 didn't even have protocol extensions. There's more that could be improved though. It would be lovely to just write `var body: View` and have it do the right thing (i.e. not return an existential). And again, there would be concern that's too "implicit”. That that `some` is load bearing. That the right landing place is you always have to state `any` or `some`.
Every line, almost every other keyword, has examples. Even the dropped trivia, like unnecessary semicolons and parens, has complexity and downsides, that the grammar and parser do an excellent job of hiding from you.
The most celebrated appear on the second line: type inference means you wouldn't need to explicitly type `NSInteger cellIndex =`, just `let cellIndex =`. But still, type inference has its detractors. Much better to be explicit. Much safer. Much more readable.
But the most dominant technique on display is the most controversial one: implicit defaults, that let you drop more syntax.
You see if from the very first character, because Swift's default visibility is internal, so you don't need to mark internal methods with a sigil or keyword.
And in almost every case, there is a very reasonable objection to that implicit rule. In this case, that internal methods might allow unintentional exposing of private invariants to other parts of your code.
Swift has a lot of techniques for reducing ceremony and increasing readability that you can see in action if you think about what the equivalent code would be. That includes things like string interpolation, and a built-in concept of mutability and value types so you don't need NSMutable variants. And of course it does away with pointers in most cases. It has optionals so there's one way to spell “not found”, with sugar for handling them.
Evolution can go the other way too. The `any` keyword for existentials for example (hopefully as a step towards swapping `any` and `some` to give us `var body: View`).
But attempts to add back in ceremony in pursuit of clarity are usually heading in the wrong direction. Take the proposal to require explicit self on member access. The rejection quotes @inthehands: "anything that is widely repeated becomes invisible”
I would go further though. Anything repeated gets in the way, reduces clarity.
Another evolution that I love is the `if let x {` shorthand, instead of the (common) boilerplate `if let x = x {`. It simplifies and clarifies this common idiom.
Once you know about it – each one of these is a thing for a newcomer to learn. But you learn a language once, then use it for years. Over-optimizing for beginners is the wrong trade-off. These simplifications aren't complex to explain and remember. And Swift's clean look attracts users from both high- and low-ceremony languages.
America might sleepwalk into bizarrely voting for something that's bad for everyone next week. There's still time to reach out to someone in your life who might be wavering, and convince them to go vote for Harris instead of staying home, despite misgivings.
The news about how General Milley and Matthis–old white dudes they'll respect–genuinely think he's a fascist and a threat to America maybe hasn't broken through to them. They think another Trump term will be OK like the last one because people will keep him in check, so it'll be fine. It's different now. There'll be no Gary Cohns or John Kellys. Full on fascism is bad for business.
Remind them split ticket voting is a thing. They can vote D for President, and R all the way down after that.