Lebeaupin on Swift
Nested block comments do not work. They cannot be made to work (for those who care, I filed this as rdar://problem/18138958/, visible on Open Radar; it was closed with status “Behaves correctly”). That is why the inside of an
#if 0/#endifpair in C must still be composed of valid preprocessing tokens.[…]
Little did I know that not only Swift method calls are not more dynamic than Objective-C method calls, but in fact don’t use
objc_msgSend()at all by default! Look,objc_msgSend()(and friends) is the whole point of the Objective-C runtime. Period. Everything else is bookkeeping in support ofobjc_msgSend(). […] Apple is trying to convince us of the Objective-C-minus-the-C-part lineage of Swift, but the truth is that Swift has very little to do with that, and much more to do, semantically, with C++. This would never have happened had Avie Tevanian still beenaliveworking at Apple.[…]
I find it very odd that there is no description or documentation of threading in Swift. And yes, I know you can spawn threads using the Objective-C APIs and then try and run Swift code inside that thread; that’s not the point. The point is: as soon as I share any object between two threads running Swift code, what happens?
[…]
I don’t like: the lacks of a narrative, or at least of a progression, in the book. Where is the rationale for some of the less obvious features? Where is the equivalent of Object-Oriented Programming with Objective-C (formerly the first half of “Object-Oriented Programming and the Objective-C Programming Language”)? This matters, we can’t just expect to give developers a bunch of tools and expect them to figure out which tool is for which purpose, or at least not in a consistent way. Providing a rationale for the features is part of a programming language as well.
[…]
Swift seems to go counter to all historical programming language trends: it is statically typed when most of the language work seems to trend towards more loosely typed semantics and even duck typing, it compiles down to machine code and has a design optimized for that purpose when most new languages these days run in virtual machines, it goes for total safety when most new languages have abandoned it. I wonder if Swift won’t end up in the wrong side of history eventually.
[…]
Swift, with its type safety, safe semantics and the possibility to tie variables as part of control flow constructs (
if let, etc.), promises to capture programmer intent better than any language that I know of, which ought to ease maintenance and merge operations; this should also help observability, at least in principle (I haven’t investigated Swift’s support for DTrace), and might eventually lead to an old dream of mine: formally defined semantics for the language, which would allow writing proofs (that the compiler could verify) that for instance the code I just wrote could not possibly crash.
1 Comment RSS · Twitter
For me I find Swift confusing. It has some interesting things but I find it a constant knee jerk. Very much like working in somebody else's C++ code base.
I really don't get the hate out there for Objective-C which I find comfortable and clear. Easy to read. It also makes working with C libraries a breeze. I also like C even though it can be hard looking at old C libraries. Fitting those to Swift seems like a lot of work. In fact, since Cocoa is C and Objective-C based everything feels forced in Swift, like objects in JavaScript or PHP.
I am still giving Swift a chance to wow me but for real stuff I continuall find Objective-C to be whether it's at.
