Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift's Evolution

carpeaqua.com

Post reply on HN
Print view View original

81–90 of 105 posts

Re: Swift's Evolution

#81

Post by valuearb »

nicky0 wrote: post #77
valuearb wrote: post #68

Earlier quoted context omitted.

I shipped my first Swift App with version 1.2, and have written or helped write a half dozen since. Anyone who is still using Objective C and dealing with dangling pointer bugs and difficult to maintain code is missing the point that most software development is bug fixing and maintenance. I never have the IDE crash and haven't for the last year+, never have problems with compiler bugs. Autocomplete is fine, compile…

In what ways is objC difficult to maintain, and in what ways is Swift easier to maintain than objC? I look forward to the magical bug free future when I switch to Swift.

If you actually believe I offered you a magical bug free future, can you at least pay me for it?

Swift is far more readable and a bit more concise than objective c, that makes it more maintainable. The bigger win is of course optionals, which, (if you embrace them properly), can mean your app will never have a dangling pointer or runtime crash from a nil pointer.

I spent nearly 20 years writing object oriented C and Objective C apps for personal computers and phones, and dangling pointer crashes were the biggest possible sinkhole of time, and worse degradation of product quality.

I can't imagine ever going back to objective c.

Re: Swift's Evolution

#82

Post by Apocryphon »

coldtea wrote: post #58
nicky0 wrote: post #50

Earlier quoted context omitted.

It's fine if you don't mind using rudimentary, buggy tools, and converting your whole code base to the latest language changes every 6 months, and you don't mind bloating your app with a mandatory 8Mb runtime. Great for small projects, people coding for fun, learners, and early adopters/neophiles who enjoy keeping up with all the changes. But substantial projects need solid, stable tools. Swift will get there very so…

Great for small projects, people coding for fun, learners, and early adopters/neophiles who enjoy keeping up with all the changes. But substantial projects need solid, stable tools. Lots of projects more important and substantial than anything you and I have worked on have been shipped with Swift. So that argument doesn't really fly. Apps redone/adopting Swift include Twitter, Pandora, Groupon, Fitbit, etc. (Heck, ma…

LinkedIn gave a tech talk some time ago at the SF NSMeetup. The LI app was written since Swift 1.2 and has had a good deal of growing pains since then.

https://www.youtube.com/watch?v=X9waDi787uo (14:15-15:30, 39:26-40:37)

Re: Swift's Evolution

#83

Post by kibwen »

AsyncAwait wrote: post #28

I think the author misses the fact that Swift wasn't truly 'done' when it was introduced, (and still isn't). Objective-C had some 30+ years to evolve, but Swift can't have 3? I get that if you're shipping Swift in production you want to refactor as little as possible, but it is pretty hard to come up with the ideal design straight out of the gate. Swift can stop evolving, but it will be THEN when it loses the reason…

The comparison with Rust's period of instability is very mistaken. Before 1.0 we were emphatic in telling you that you should not use Rust in a production capacity. The rust-lang.org homepage loudly proclaimed that the implementation was a prototype that would "eat your laundry". Coming into the IRC channels, anyone asking whether Rust was production-ready would be told that it wasn't, and we suggested alternative languages for those needing stability. In contrast, you don't see anyone calling Swift an experimental prototype despite it being as trigger-happy with breaking changes as ancient Rust. I take issue with the messaging that Apple has used to describe Swift's level of stability; just saying "we warned you there were going to be breaking changes :shrug:" drips with contempt. Just because one has given oneself license to break something does not mean that one should exercise that right wantonly.

I do think the Swift developers are getting better about that, fortunately, but a lot of developer goodwill has been burned in the meantime.

Re: Swift's Evolution

#84

Post by mpweiher »

andybak wrote: post #40
masklinn wrote: post #27

Earlier quoted context omitted.

> C style for loops come pretty early in most programming tutorials Meh. Many languages don't have c-style for loops in the first place. Neither Python nor Ruby do for instance. I don't think Rust ever had them either[0]. [0] https://www.reddit.com/r/rust/comments/2957fg/can_i_request_...

I agree. Looping over a numeric sequence is simply a specific case of looping over any collection. A language should reflect this. It feels so natural to write: for thing in collection: process(thing) and very easy to move from that to a functional style: map(collection, process) or collection.map(process) The number of times I also need a integer counter is fairly small.

   result := collection collect:[ :a | a process ].
   result := collection collect process.

   collection do process.

   1 to: 10 do: [ :i | stdout println:i ].
   stdout do println: (1 to: 10).
All just plain messages and plain message syntax, no special control structures needed.

Re: Swift's Evolution

#85

Post by Larrikin »

coldcode wrote: post #2

I use Swift daily in a mixed application of both languages. I worked with ObjC since back in the NeXT days and I used to like the language but today nothing could ever drive me back. Xcode on the other hand is nightmare I despise daily but that's a different issue. The sooner ObjC goes away the better.

After developing Android apps for a while and finally taking an iOS class, XCode felt like such a step back compared to Android Studio. I ended up downloading AppCode and only using XCode for UI related task.

Re: Swift's Evolution

#86

Post by eschaton »

dep_b wrote: post #46

I didn't have a really rough time with the Big Rename but some subtle differences bit me, simply the way how strings are constructed for example: var someId: Int! ... let urlString = "\(baseUrl)/\(route)/\(someId)" Result in Swift 2: "http://ac.me/products/123" result in Swift 3: "http://ac.me/products/Optional(123)" Happy hunting! Some of this ended up in production :( They've changed it to a warning in later versio…

You should be using the methods on the URL struct to compose a URL, rather than string interpolation. You wouldn't use string interpolation or concatenation to compose an SQL query, would you?

Re: Swift's Evolution

#87

Post by AlexeyBrin »

Apocryphon wrote: post #62
htormey wrote: post #35

Earlier quoted context omitted.

Its fair to say that if you adopted Swift as soon as it was announced you should have expected some pain, especially given all the warnings Apple put out about it. I think the issue is that for the last year or two all of the tutorial websites and the third party library ecosystem have moved from Objective-C to Swift in a big way. If you are new to iOS development this might lead you to have a false sense of security…

It's definitely annoying that most of the major online iOS learning resources are no longer updating their Objective-C material.

Maybe it is just a question of analytics, I mean if you have a bunch of Objective-C articles with 100 readers per month and a set of Swift articles with 10000 readers per month, as an author, you will probably chose to invest your time in updating the Swift version.

Re: Swift's Evolution

#88

Post by AsyncAwait »

kibwen wrote: post #83
AsyncAwait wrote: post #28

I think the author misses the fact that Swift wasn't truly 'done' when it was introduced, (and still isn't). Objective-C had some 30+ years to evolve, but Swift can't have 3? I get that if you're shipping Swift in production you want to refactor as little as possible, but it is pretty hard to come up with the ideal design straight out of the gate. Swift can stop evolving, but it will be THEN when it loses the reason…

The comparison with Rust's period of instability is very mistaken. Before 1.0 we were emphatic in telling you that you should not use Rust in a production capacity. The rust-lang.org homepage loudly proclaimed that the implementation was a prototype that would "eat your laundry". Coming into the IRC channels, anyone asking whether Rust was production-ready would be told that it wasn't, and we suggested alternative la…

> the rust-lang.org homepage loudly proclaimed that the implementation was a prototype

I get what you're saying, but a 'prototype' is perhaps a bit far. Rust was far from being called a prototype years before being declared stable, however I do agree that branding Swift 1.0 in 2014 was a mistake. Personal theory is that if you want to release something at Apple to the public, and Chris wanted to get feedback, you have to brand it 1.0

> just saying "we warned you there were going to be breaking changes :shrug:" drips with contempt

Ouch, that's going a bit too far, Chris Lattner definitely doesn't strike me as someone who has contempt for developers. He gave us LLVM, (which BTW Rust uses as its backend) and by all signs he worked very hard in the background to get Swift open-sourced. Now they're taking a lot of feedback from the community via their Swift Evolution process and the Swift community wants the language to continue to evolve, so it does, not sure what could've they done better in this regard.

Re: Swift's Evolution

#89

Post by dwaite »

objclxt wrote: post #70
valuearb wrote: post #67

Earlier quoted context omitted.

Because Swift 1.0 was far superior to Objective C in maintainability and code quality. Now I do admit the build times were awful and I had a couple puzzling crashers that were only cleaned up by Swift 1.2 (thankfully didn't ship till after 1.2 was final), but the transition was worth it.

> Because Swift 1.0 was far superior to Objective C in maintainability and code quality. You can take Objective-C code written three years ago, open it up in Xcode today, and compile it. The same cannot be said for Swift. So saying Swift 1.0 was "far superior" in terms of maintainability is a bit of a stretch, in my opinion.

3 years is long enough for an Objective-C API to be deprecated and obsoleted/removed.

It would also be really challenging for Swift code written 3 years ago to compile, because Swift wasn't released yet.

Re: Swift's Evolution

#90

Post by kibwen »

AsyncAwait wrote: post #88
kibwen wrote: post #83

Earlier quoted context omitted.

The comparison with Rust's period of instability is very mistaken. Before 1.0 we were emphatic in telling you that you should not use Rust in a production capacity. The rust-lang.org homepage loudly proclaimed that the implementation was a prototype that would "eat your laundry". Coming into the IRC channels, anyone asking whether Rust was production-ready would be told that it wasn't, and we suggested alternative la…

> the rust-lang.org homepage loudly proclaimed that the implementation was a prototype I get what you're saying, but a 'prototype' is perhaps a bit far. Rust was far from being called a prototype years before being declared stable, however I do agree that branding Swift 1.0 in 2014 was a mistake. Personal theory is that if you want to release something at Apple to the public, and Chris wanted to get feedback, you hav…

Yes indeed, I don't blame Chris for any of this. Given his pedigree with LLVM, I'd believe that if he had his way Swift would have been open and available for comment from day one. I squarely blame Apple's management, a misapplied corporate culture of extreme secrecy, and an executive allergy to the word "beta" for the issues that I perceive. I apologize if it seemed that I was blaming the Swift developers themselves or denigrating their abilities.
Post reply on HN