8 ms·
Is It Time for Swift?
- yrezgui 11y agoI'm not an iOS developer but for the native modules that I developed for Cordova or React Native, Swift is definitely a much better and cleaner language to develop it.
- R00TL3SS 11y agolol. "use an 'objective' approach to adopting swift". nothing like a well placed pun.
- BuckRogers 11y agoI knew there was some churn in the Swift language but didn't think it was going to continue. I'm not using Swift now but will likely hold off a bit longer as a result. I did think they nailed the open source launch. Swift on the server is an exciting prospect, more competition is always good. While I'm not a Swift dev yet (I don't have a Mac thus mainly interested in the libre crossplatform launch), I've been keeping my eye on it with Swift Weekly. I think 2016-2017 could well be the year(s) of Swift's ascension.
- lpsz 11y agoHave been using Swift since late 2014 (having used ObjC for many years prior to that). Even with the occasional churn (eg move to 2.0 or 2.1), the sheer gain in productivity due to brevity, type checking, cleaner closures, and various other language features, easily outweighs any costs. I find myself being able to do more with less code, and cleaner code. It's cognitively way easier to build bigger abstractions. We do have a few legacy bits that makes no business reason to port at this point, but Swift-to-legacy interop works well, too. I would say the biggest step that made things usable was introduction of incremental builds in 1.2.
- ktRolster 11y ago> the sheer gain in productivity due to brevity, type checking, cleaner closures, and various other language features, easily outweighs any costs. Serious question: do you have a metric you are using to measure that, or is it just kind of a "gut feeling?"
- cellularmitosis 11y agoI think that approach (waiting to adopt) makes sense if you aren't already an ObjC developer. Less to unlearn. However, for an ObjC dev, waiting to adopt is only going to put you further behind the curve (the hard part won't be absorbing the changes from Swift 2 to Swift 3, its dropping your ObjC habits and learning what it means to write idiomatic Swift (which isn't going to drastically change between Swift revisions)).
- melling 11y agoHow many iOS Objective C books have been written in the past 18 months? I count at least 3 dozen Swift books: http://www.h4labs.com/dev/ios/books http://www.h4labs.com/dev/ios/books At some point soon if you want to find recent examples for iOS 8 and 9, they'll all be in Swift. iOS 10 will be announced in 4 months. Books, blogs, and perhaps all of Apple's examples, will be in Swift.
- travisty 11y agoSadly though, a lot of the books either are or will be out of date as more updates come to Swift and break existing code. I've been working on and off with Swift since the beginning, it has a lot of great characteristics, but updates breaking code isn't something most developers have time to worry about.
- alblue 11y agoIt's tough. I had a book out in 2014 and it's just been re-released as a second edition in 2016 (Swift Essentials) with fixes for all the changes introduced since the initial release. And you can't run the fix-its on a book :-) One thing that has helped with the new openness of Swift's evolution is that I included several upcoming warnings, such as the demise of the ++ and -- operators and the 'standard' for loop. There will have to be a phase change in the future when Swift moves from a "move fast and break things" to a "stable evolution". It has been suggested that this will begin with Swift 3 (when a stable ABI is introduced) but I suspect it will be Swift 4 or 5 when stability is really nailed down.
- melling 11y agoYes, and the new versions will have updated Swift. The four year old Objective C books will contain valid code with outdated API calls.
- icpmacdo 11y agoIts funny yesterday I had a meeting with my 2 head course professors talking about this exact issue. A capstone project essentially requires a objectice c ios app but they have stopped producing reference books for them in IOS 8 && 9.
- st3fan 11y agoPretty happy the Firefox for iOS team made the decision to go fully Swift about 14 months ago :-) Almost 60,000 lines later, no regrets. It is awesome.
- shawn-butler 11y ago> git clone https://github.com/mozilla/firefox-ios.git https://github.com/mozilla/firefox-ios.git FireFox-ios > cloc FireFox-ios/ 1068 text files. 928 unique files. 303 files ignored. C 1 files 10606 blank 51150 comment 94618 code Swift 332 files 9660 blank 5808 comment 43474 code EDIT: I give up trying to format the output correctly
- deathanatos 11y agoThe single .c file, I'm guessing is: https://github.com/mozilla/firefox-ios/blob/master/ThirdParty/sqlcipher/sqlite3.c https://github.com/mozilla/firefox-ios/blob/master/ThirdPart... It appears to be the source for sqlite3, all concatenated together, which is why it's absurdly long. And it's third party, so its not really their code, but of course the tooling can't tell that.
- Someone 11y agoI haven't checked, but chances are it is the SQLite amalgamation or a tweaked version of it. https://www.sqlite.org/amalgamation.html https://www.sqlite.org/amalgamation.html: "The standard makefiles for SQLite have a target for building an object we call the "amalgamation". The amalgamation is a single C code file, named "sqlite3.c", that contains all C code for the core SQLite library and the FTS3, FTS5, RTREE, DBSTAT, JSON1, and RBU extensions. This file contains about 184K lines of code (113K if you omit blank lines and comments) and is over 6.4 megabytes in size".
- brendanlim 11y agoLyft for iOS is probably one of the largest Swift apps http://m.fastcompany.com/3050266/tech-forecast/lyft-goes-swift-how-and-why-it-rewrote-its-app-from-scratch-in-apples-new-lang http://m.fastcompany.com/3050266/tech-forecast/lyft-goes-swi...
- smegel 11y agoThis is starting to sound a lot like Android developers still asking if they should use Android Studio or Eclipse...
- vinceyuan 11y agoIt's totally different. Google officially stopped development and support for ADT in Eclipse. But Apple is still supporting Objective-C and most Apple's apps are written in Objective-C.
- agildehaus 11y agoApple is supporting Objective-C out of necessity (both for themselves and others). It's still very clear where the future of iOS development lies, and how few disadvantages there are. That they continue to support Objective-C has little to do with whether or not you should be using it. You should, clearly.
- peterkelly 11y agoIt will be time for Swift when they stop making backwards-incompatible changes to the syntax and I can be sure my code from today will still compile tomorrow when I download the latest version of Xcode.
- st3fan 11y agoJust deal with it.
- sssilver 11y agoThe alternative is to either stifle improvements, or to bloat the language. And we all know what that looks like looks at C++ I personally am happy they're making backwards-incompatible changes, and I hope they always continue doing that. I'm happy to maintain my software in return of working with an elegant, cutting-edge, small, logical language.
- dikaiosune 11y agoYou don't need breaking changes to get many benefits of a language like swift - for example rust has had very little breakage since hitting 1.0.
- wallacoloo 11y agoThanks for bringing rust into the discussion - they handle language standardization/evolution very effectively, in my opinion. "Experimental" features are added to the language, but they are all effectively #define-gated for at least one release before being concretized (it's done more pragmatically than a literal #define of course, given that rust doesn't have any concept of #defines). This makes sense in my opinion because it gives an opportunity to evaluate proposed language changes under real-world use-cases before making it official, and people must explicitly opt into the possibility of their code not working with future releases, thus fully knowing and accepting the risks.
- edgyswingset 11y ago>I personally am happy they're making backwards-incompatible changes, and I hope they always continue doing that. At the very early stages of the language, sure. But ten years down the line with significant assets in Swift? I think your opinion will change.
- dxhdr 11y agoSwift is a neat language but unfortunately doesn't fix the extremely verbose and archaic-feeling NextStep libraries that make Objective-C a pain to read or write: let bar = foo.stringByReplacingOccurrencesOfString(" ", withString: "", options: .LiteralSearch, range: nil) Compare to any other language, say Python: bar = foo.replace(" ", "")
- rarepostinlurkr 11y agoCocoa renamification coming up, which will remove some of that. Also most of those words are auto completed for you. https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007737.html https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...
- sehr 11y agoMore info: https://swift.org/blog/swift-api-transformation/ https://swift.org/blog/swift-api-transformation/
- schrototo 11y agoI know exactly what the first one does, without knowledge of the underlying API. I have no idea what the second one does. Does it replace occurrences of the first parameter with the second one, or vice versa? I assume it returns a copy of the string? What do I need to do to perform a case insensitive search? etc.
- forrestthewoods 11y agoThat's a true statement. Yet I still think the second way is superior. There's a steeper learning curve sure. But brevity has value. Is grep a stupid ass name that makes no sense to the layman? Of course! Can even moderately complicated regular expressions actually be read by anyone after the fact? Hell no. And yet it's a fantastic tool. If there were a dynamic toggle between verbose and brief newbies would start with verbose. I bet most users would eventually switch to brief. Not all, but most.
- 11y ago
- pmalynin 11y agoWhat bother me the most about Swift, is it essentially a C# clone, actually worse, because C# has more features. It is a travesty that Apple chose to design yet another shit language when there are so many other alternatives. And now, like with Go, everybody is jumping on the band wagon because its Apple. Sigh.
- akhilcacharya 11y agoC# clone? In what way?
- pmalynin 11y agohttp://swiftcomparsion.qiniudn.com/ http://swiftcomparsion.qiniudn.com/
- andybak 11y agoThat page reads like someone who doesn't know much about other languages cherry-picking and making dubious connections. A fair chunk of the Swift examples listed strike me as radically different to the C#
- deleted 11y ago[deleted]
- meddlepal 11y agoC# clone? It's far more like a Kotlin clone without the JVM.
- pcwalton 11y agoWhile I agree that Swift and C# share a lot of commonalities and are fairly similar languages, the better integration of Objective-C alone makes the new language worth it. I don't know anyone in PL who thinks Swift is a bad language. It's a nice, conservative, tasteful design that uplifts some proven functional features. What's not to like?
- 11y ago
- edwinnathaniel 11y ago> Syntax Doesn’t Move the Needle; It’s All About Tradeoffs That section is gold.
- tylerc230 11y agoOne of the most compelling reasons to start using Swift is to make your project more attractive to job applicants.
- tomwilson 11y agoI still prefer objective-c most of the time. RIP :-(
- billconan 11y agohere is one of my pain points of using swift. I need to convert Int to In32 and CFloat to CGFloat a lot. I wonder why there are so many basic types, and why can't they be simply converted to other types.
- wolfsir 11y agoInt is a 64-bit data type and Int32 is 32-bits. The compiler refuses to infer that you want to lose data. Converting the other way, the compiler refuses to infer that you want to bloat your data. CGFloat, depending on the runtime, may either be a Float or a Double, so explicitly converting to and from it is required. Rather than create a byzantine set of rules about whether it is "safe" to convert from one type to another, Swift wisely requires that all type conversions be explicit.
- bsaul 11y agoI'm so desperate to find a good programming environment on the server side, that i thought this talk was about using swift for the server side...
- adwelly 11y agoOT but I can report significant success with clojure on the server over the last several years.
- mike_hearn 11y agoKotlin looks somewhat like Swift (or Swift like Kotlin, depending on your perspective) and you get all the tools and libraries that have been built up over the years for server side programming on the JVM.
- paulddraper 11y agoBut not the iOS APIs.
- bsaul 11y agoDeploying on the jvm isn't what i would call a sane environment, i'm looking for something more go like (aka build copy, done). Plus kotlin doesn't seem to have a very stable web framework for now, and clojure isn't enough strongly typed for my taste. All those things i'm looking for makes me really hope in swift on the server... But thank you a lot anyway for making suggestions.
- mike_hearn 11y ago"Not sane"? You can literally unzip a JVM and then run "java -jar myapp.jar", how is that too complicated for modern day sysadmins? But if you want a single copyable deployment then look at the javapackager tool in Java 8. It will take a unified JAR (which any build tool can produce) and create a .deb/.rpm/.tar.gz with a bundled JRE inside such that you can install it and then run your app in the usual UNIX way (by name). You wouldn't even know it's Java under the hood. Kotlin doesn't need any web frameworks because it's 100% interoperable with Java, so you'd just use any of those like Play Framework, Ninja framework, Spring Boot, etc.
- frik 11y agoShould one wait for Swift 3? The API/syntax changes are a concern. Code breaking changes aren't that great. Also last time I checked Swift still requires a 64bit iOS device.
- jakobegger 11y agoNot sure where you got that 64bit thing from. I wrote an app using Swift and it runs fine on my 32bit iPhone 5.
- JimDabell 11y agoGenerally speaking, Xcode can usually automatically migrate your code, and the places where it can't are pretty easily done manually. Swift doesn't require 64-bit iOS, and never has as far as I recall.
- pivo 11y agoApple provides code migration support in Xcode, so when they break things it's mostly a mechanical and sometimes automatic update. I migrated our 50K lines of Swift code from Swift 1.2 to 2.x in a few hours.
- preordained 11y agoSomething to think about from end user Joe, here: A quick search seemed to indicate that Swift support (officially) began in iOS 7. Great, that's the version I'm on. If anything coming down the pipe for Swift depends on a later version, I'm not on board. I'm not going anywhere. A lot of users, myself included, have been burned when a version upgrade runs like a dog on old hardware...but unfortunately, I'm not going to spring for a new iPad every year, much to the chagrin of Apple. It'd be interesting to see how App Store success correlates with how many versions you can support.
- thewarrior 11y agoApple already thought of this and tbe Swift runtime + libraries are embedded inside every app that uses Swift. No worries :).
- preordained 11y agoNo worries, indeed. Good to know!
- peterashford 11y agoReference counting seems really backwards and it hurts performance. Odd feature to have in a modern language
- natch 11y agoWhy is he talking as though using objects is out, and using value types is the only valid path with Swift? Especially during a transition phase, which we are inescapably in right now, wouldn't it be pragmatic to continue using objects when needed, even if the eventual goal is to end up transitioning to protocol oriented programming? In other words we don't need to conflate Swift with POP, which I think is what he's doing when he talks about the purported problems of NSNotificationCenter.