Profile cover photo
Profile photo
Matej Ľach
Matej's posts

Post has attachment
+Michael Dominick I think this transition all depends on whether Google can embrace Swift "the language" and thus design "Swifty" APIs around that or whether it's just going to do what Apple did - drop Swift straight onto its Objective-C-based platform.
If Google commits fully to Swift as a first-class language, separate from the Java ecosystem and design their APIs around that mindset, it's going to be worth it.
If they're just planning to harshly translate their Java APIs onto the Swift paradigm then we'll not see much of a benefit from the transition, (this is where Cocoa is now, sadly...but there are reason and there's hope).
I mean what they did makes sense from a business perspective, Cocoa is a huge codebase and re-writing it from scratch in Swift would be a huge investment for seemingly little shareholder value + they have to support legacy Objective-C anyways, so incremental API tweaks make more sense for them, at least for now.

An all Swift Cocoa would've been amazing the same way an all self-driving cars motorway would be.
Google could avoid designing systems to avoid sloppy human drivers and there would never be any crashes because the self-driving cars would be aware of each other's precise position, speed, intention etc. and thus could react precisely - that however is not the world we live in and in the same way such an abrupt transition to self-driving cars is not possible for Google, currently the transition to an all-Swift Cocoa for Apple does not make sense.
I wouldn't let that to colour the perception I have of the language itself, especially when proposals on how to improve the situation are sent in all the time.

What makes me hopeful about the Android case, (if Google really does decide to do this), is that unlike Apple, where the Clang Objective-C compiler and Swift's own compiler can trivially co-exist and inherit from each other freely because they're both built on the LLVM backend and can "communicate" between each other even if not on the high-level language level, then on the LLVM intermediate representation, (think LLVM assembly) level, (this is why one can easily mix Swift, Objective-C, C or even C++ code in one project, they don't actually understand each other at the high/language-level, (aside from exporting a C interface), but Clang and Swift both produce compatible LLVM IR and so they understand each other at this level.)
Google doesn't have that luxury, since Java does not (in any official capacity, there's but that didn't go anywhere), run on the LLVM, (which Swift depends upon), so Google cannot just lazily map Java APIs to Swift, it has to re-do them from scratch FOR Swift.
My hope is that when they'll be doing that, they'll stop and think about the idiomatic "Swifty" way to do things.

Coming back to Apple, the way you write Cocoa in Swift today is not idiomatic at all, that's why I suggest if you want to get a good feel for the "language" Swift and not just current Cocoa in Swift, (because Swift is hardly a one-horse language), do a fun side project in Swift that doesn't involve Cocoa - suggestion: try implementing a small parser combinator library in Swift - ( - try no classes, just functions and protocols and try to avoid mutable state, have fun! :-)
Wait while more posts are being loaded