2. Do spring cleaning on incompatibilities in Swift vs. Obj-C vs. Foundation, such as incompatible types that require casting, or bridging, or different semantics.
-- For most iOS code that I personally write, I value readable Swift syntax even more than fast toll-free bridging to Obj-C and CF. For examples, look at ints and strings.
3. Create some kind of dependency manager, to make it easier to have a Swift code that uses other Swift codebase.
-- The current approaches are Xcode project embedding, Carthage, and Cocoapods; this past year all of them have had struggles.
+1 point 2. Most of my Swift code is within Objective-C projects and most of my time wasted is dealing with incompatibilities between Objc types and Swift types.
All in all, I think it's a bit premature to do a "One year where do we go" article the week before WWDC.
It is an interesting language, but I've found a couple of things while starting to use it that have driven me crazy, and not really made me want to continue delving; the two that come to mind are
a) Error messages are awful, and often nothing to do with the actual error
b) Was driven crazy trying to append a tuple to a list. E.g.
A tuple of type (Int,String) is expressed (2, "a")
var aTuple : (Int,String) = (2,"Some")
A list of these is
var l : [(Int,String)] = []
This does not work:
l.append((2,"a")) // ERROR: missing argument for parameter #2 in call
This ALSO does not work:
l.append(aTuple)
but this does:
l.append(2,"a")
Yes, that is inconsistent. I like those languages that have a quality about them where you can guess correctly at how to do something. Orthogonality comes into play here as well as copying from other languages.
I'd like to C++ support added to Swift, similar to Objective-C with Objective-C++. There are some C++ frameworks which are nice to use in Obj-C, like Box2D. Currently to get them to work with Swift, you have to write an Obj-C or C wrapper around a C++ framework, and then import that into Swift.
Swift is useless to me if I have to re-write code on other platforms. In such cases I will always use as little as possible and then switch to some other portable language for the meat of my code.
It's probably more likely that Microsoft will ship a Swift runtime/compiler system for Swift than Apple admitting anyone cares about anything but iOS. I'd be slightly surprised if MS hasn't already started on it.
The day Apple goes cross plat will be interesting. (Sorta like MS backing down on longstanding issues as reality invades.)
I think it's coming. There was a HN post about MS working on bringing Obj-C to MS without any kind of emulation layer simply by leveraging llvm and the existing MS C++ compiler. It's called Project Islandwood (https://dev.windows.com/en-us/uwp-bridges/project-islandwood) and in a video presentation about it there was also mention of work on Swift (although Swift support wasn't official). MS is really moving in some interesting directions these days and I'm all for it.
Why web frameworks in Swift? Do people think they will crop up instantly after Swift is open sourced? What makes it more attractive than Go, or Rust?
It takes a considerable amount of work to make a good web framework - look at the attention Rust gets and the state of its web frameworks. They've come a long way no doubt, but none are production ready. Swift can leverage some Objective-C sure, but nobody's writing web apps in Objective-C either.
Having written a non-trivial amount of Swift and Go, and a trivial amount of Rust, I'd say that Go doesn't offer as much opportunity for abstraction as Swift (which has generics, for starters). Rust feels lower-level and there's a lot of syntax baggage re: memory management, which Swift doesn't have.
Personally, I quite like Swift. I came into it from a primarily dynamic lang background, and found it very expressive - not at all the static lang shackles I was dreading.
This article is mostly another Swift circlejerk. I wish the discussion was more substantiative instead of just taking swipes at Obj-C.
"I’ll be deleting all my Objective-C, because it’s technical debt."
Completely disagree. Obj-C will still be around in 10 years with some level of tool support since there are what – hundreds of millions to billions of lines of Obj-C already written? It's not just going away, like how C didn't just go away, and tons of other languages still in use today. That timeframe is likely to outlast the lifetime of most projects started with Obj-C, today.
It's not technical debt if it's the right solution to the problem. Obj-C is the best-supported way to get things done on Apple's platforms today and tomorrow. Swift is still full of rough edges, bugs, and toolchain issues that aren't just suddenly going to be magically resolved - it's a process.
So maybe they're excited about the distant future of Swift and hooray for them. I just wish it actually were Objective-C without the C and not the C++ reading clusterfuck that it is.
18 comments
[ 2.9 ms ] story [ 53.1 ms ] thread1. Get experts to improve the tutorials and classes.
-- This year I especially want to thank Ray Wenderlich (http://www.raywenderlich.com) for his clear tutorials and Rob Rix (https://github.com/robrix) for his focused classes.
2. Do spring cleaning on incompatibilities in Swift vs. Obj-C vs. Foundation, such as incompatible types that require casting, or bridging, or different semantics.
-- For most iOS code that I personally write, I value readable Swift syntax even more than fast toll-free bridging to Obj-C and CF. For examples, look at ints and strings.
3. Create some kind of dependency manager, to make it easier to have a Swift code that uses other Swift codebase.
-- The current approaches are Xcode project embedding, Carthage, and Cocoapods; this past year all of them have had struggles.
http://www.h4labs.com/dev/ios/swift.html
I expect to add a couple thousand in the second year. I'm sure the quality varies but a lot of great stuff has already been written.
Also, consider that there were 36,000 questions on StackOverflow for Swift. That's almost as many as Scala, for example.
I also hope Swift keeps improving but for the first year, I'd say it was much better than I expected.
Link?
It is an interesting language, but I've found a couple of things while starting to use it that have driven me crazy, and not really made me want to continue delving; the two that come to mind are
a) Error messages are awful, and often nothing to do with the actual error
b) Was driven crazy trying to append a tuple to a list. E.g.
Swift is useless to me if I have to re-write code on other platforms. In such cases I will always use as little as possible and then switch to some other portable language for the meat of my code.
The day Apple goes cross plat will be interesting. (Sorta like MS backing down on longstanding issues as reality invades.)
It takes a considerable amount of work to make a good web framework - look at the attention Rust gets and the state of its web frameworks. They've come a long way no doubt, but none are production ready. Swift can leverage some Objective-C sure, but nobody's writing web apps in Objective-C either.
Personally, I quite like Swift. I came into it from a primarily dynamic lang background, and found it very expressive - not at all the static lang shackles I was dreading.
It's not technical debt if it's the right solution to the problem. Obj-C is the best-supported way to get things done on Apple's platforms today and tomorrow. Swift is still full of rough edges, bugs, and toolchain issues that aren't just suddenly going to be magically resolved - it's a process.
So maybe they're excited about the distant future of Swift and hooray for them. I just wish it actually were Objective-C without the C and not the C++ reading clusterfuck that it is.