On Jun 12, 2015, at 19:32 , Carl Hoefs <newsli...@autonomy.caltech.edu> wrote: > > Okay, so now there's Swift. Ugh. At first glance it looks like a throwback to > Basic (let x =), so it make me shudder.
Trust me, that feeling goes away in a few days. > I suppose I'll hold my nose and learn it, but the main question would be why? OK, I’ll bite. > Is there some glaring irredeemable deficiency in Obj C that will end its > days? I don’t recall anyone clamoring for a new language… Actually, yes, we’ve been clamoring for improvements to Obj C for years, and got very little syntactically. My guess is that the biggest enhancement, ARC, was added to Obj-C mostly because the technology was being developed for Swift anyway. > What problem/issue/deficiency is Swift intended to address? There are old-school reasons and new-school reasons. One of the biggest old-school reason is source duplication. You have to write everything “twice”, once in @interface, once in @implementation. This has been mitigated somewhat over the years, but Obj-C is literally twice the number of files as Swift, and (in my experience so far) twice the number of source lines to do the same thing. Second is C-ness. Because Obj-C *is* C, it’s stuck with decades-old C limitations. We tolerated this because C is familiar and standard, but it’s still … old. (A quick example: enums in C are “really” just ints, with some slight pragmatic improvements over the years. The interchangeability is a source of programming errors.) To paraphrase an old joke, 1978 kept calling and asking for its raw bits back. Amongst new-school reasons, there are things that you might not see as compelling because they’re unfamiliar, such as associated values in enums. Or better switch statements. Or optionals. Then there’s a game-changing focus on value immutability as a programming paradigm. This seems like a drawback at first (“you’re gonna keep *copying* my arrays when I pass them around??”) but it ends up having very deep good consequences. (There’s a WWDC video on this, which I haven’t watched yet.) Then — especially in Swift 2 — there’s a game-changing focus on protocol-oriented programming. If you’ve suffered through C++, the sales pitch for Swift might be “base classes done right”, though I think there’s more too it than that. There’s a WWDC video on this, too, which I have watched and recommend, but keep your finger near the Pause button, since you’ll have to stop and think a lot.) Lastly there are some new things, which *might* have been added to Obj-C but weren’t. For example, error handling. Perhaps it could be (and perhaps it even will be), but perhaps C-ness gets in the way of doing that. OTOH generics did kinda cross over into Obj-C, but again (I suspect) only because Swift exists. > The mindset I use when programming in Obj C is “pure and simple object > orientation”. What mindset am I to adopt in learning Swift? It’s the same, really. The difference is that software-writing technology has actually advanced in the last 50 years. In some ways, it’s harder (and we’re tackling harder projects), so the language needs to be deeper. I’ve been thinking, this week, that the problem with C++ is that over the 50 years it’s tried to deal with this by *adding* stuff, time after time. Swift feels more like stuff is getting *removed* in each version. I dunno, but I think for anyone who used Swift 1, Swift 2 feels simpler. > I’m having a hard time getting a “feel” for Swift's orientation. It seems so… > syntaxy. Yes, I agree that’s a drawback, especially for those of us who are used Obj-C. There are people out there who enjoy the fact that you can write Swift code that’s reminiscent of Lisp (to some degree), but I think it’s possible to write in an Obj-C-like vernacular if you prefer, and *still* write only half as many lines of code. In this connection, I’d draw your attention to the discussion that Roland & I just had on the ugliness of case patterns, and point out that even in Swift we still have the damn curly braces, and still can’t agree on what line to put them on. <sigh> _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
