Swift is designed around premature optimization. In my experience, improving programmer productivity is more important. The more time spent with compiler enforced busywork is less time in Instruments. The same goes for compile times. If you want people to write fast code then help them to iterate quickly.
One of the problems I have is that I love python, but I was hoping that swift would be like python on steroids. Instead, I can’t make the leap because python lets me iterate so freaking fast. If I could have something like that with the ability to incrementally improve my code and compile to a binary, I’d be happy. I thought awift would be it, but your comment helped me understand why it isn’t working for me.
Full disclosure, I’m not a full time dev, so YMMV.
I'm not convinced; the examples you give require _more_ work for the compiler writer, not less. In general, a stronger type systems means that the compiler has to do more.
Exactly. In Objective-C, the compiler can't do much, which is kind of a bummer if you are a compiler guy. Chris is a compiler guy.
Consider Swift a kind of public works program for your local compiler team.
If a variable is read-only, you're forced to think about that by deciding between let/var. contrast this with objc, where all vars are writable unless you do the extra work of adding the const keyword. objc makes us do more work to get the faster (and safer) behavior.
Similar with Optionals, you're now forced to decide right away if a parameter can ever be nil, whereas with objc you didn't need to declare nullability. Again, it makes the safest and fastest choice easier to make, and allowing nullability is actually more work.
Generally Swift forces you to pass as much information to the compiler as possible at compile time, and it does it with a delightfully readable syntax. This theme repeats itself throughout the language. more information at compile time is always going to result in safer and more predictable behavior.
full disclosure: i'm an iOS dev working in objc and swift. i love both languages, and i think swift is the obvious path forward.