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

41–50 of 105 posts

Re: Swift's Evolution

#41

Post by andybak »

masklinn wrote: post #27
pscarey wrote: post #20

Earlier quoted context omitted.

Thanks for sharing that link. I found it quite an interesting read. (I much prefer Swift to ObjC after a conversion of about 10k lines in an iOS app). C style for loops come pretty early in most programming tutorials, but I wonder how much non-C programming does actually use them nowadays (from the Community Responses, it seems not much Swift courtesy of other options). Usually, a C style for would be to loop over an…

> 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)
The number of times I also need a integer counter is fairly small.

Re: Swift's Evolution

#42

Post by aaronbrethorst »

> The biggest travesty was the "Great Renaming" which touched every line of Swift code I had and burned a week of my life on tedium

The sheer amount of churn in Swift between v1 and v3 was what has kept me on the sidelines. It was only that Apple plainly stated last summer that they were done radically changing the language that I was willing to get into Swift at all.

Re: Swift's Evolution

#43

Post by [deleted] »

[deleted] wrote: post #37
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…

[deleted]

[deleted]

Re: Swift's Evolution

#44

Post by mikeash »

karmelapple wrote: post #32
nicky0 wrote: post #30

Earlier quoted context omitted.

Anyone shipping swift code one day one had to be pretty masochistic. I just couldn't understand why people were doing it. It was obviously not ready for production use, and still isn't. But I'm happy that people are playing with it and the language is being refined so that I can start using it in a few years.

Why isn't it currently ready for production use? ABI stability is the only real issue I can see now.

I'd say it's ready, but it's a bit iffy because of the tooling. The compiler is way too easy to crash, the debugger is often worse than useless, and larger projects can be extremely slow to build.

You can put up with these, and I think it's worth the tradeoff, but you should definitely consider them carefully before putting a lot of effort into build a real-world Swift code base.

Re: Swift's Evolution

#45

Post by mikeash »

jcizzle wrote: post #24

If you follow the Apple dev community, there is a group of folks that make their living on books and speaking. That's fine, but they are using the platform differently than someone shipping software. They are also often the authors of some of the more ideological, less pragmatic proposals. This has a large impact on the disconnect the author describes - which incurs a cost on folks who ship software. I do wish the Sw…

Maybe I'm in the wrong part of the Apple dev community, but I don't know of anyone who makes a living on books and speaking. I know many who write books and do a lot of speaking, but there isn't enough money in it for it to be anything more than a side gig.

Re: Swift's Evolution

#46

Post by dep_b »

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 versions of Xcode 8 at least. But that was too late for me.

Apart from that it's a big step forward, less wordy than Objective-C yet it's still "readable language" instead of a bunch of almost random generic English words.

I'm not sure about async / await. Whenever I deal with it in .Net languages I never find it that intuitive compared to blocks. But you know every programmer suffers from Stockholm Syndrome at least a bit so it could just be my mind warped to not only accepting but even glorifying the flaws in a language.

There are people out there that genuinely like JavaScript for instance!

Re: Swift's Evolution

#47

Post by mikeash »

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.

When you do need an integer counter, the best way to have it is to create a new collection consisting of (index, element) pairs. Swift (and many other languages) make this easy:

  for (index, element) in collection.enumerated()
There are some cases where the C style for loop is the most natural way to express something. For example, looping over NULL-terminated array of pointers is nicely expressed with one (Swift 2-ish pseudocode):

  for var cursor = ptr; cursor.pointee != nil; cursor += 1
But these situations are really rare, and when you do encounter them, it's not a big deal to transform them into a while loop:

  var cursor = ptr
  while cursor.pointee != nil {
      defer { cursor += 1 }
      ...do stuff...
  }

Re: Swift's Evolution

#48

Post by ngrilly »

bsaul wrote: post #16

I'm actually pretty happy swift moves the server side story forward, because i'm convinced the "next big language" will have to run on mobile and server. Actually, i think they don't go fast enough, especially regarding concurrency ( which on the server goes beyond just providing async await, as lattner said they were aiming at something closer to the actor model). I don't think the "maybe objc is still relevant for…

> which on the server goes beyond just providing async await, as lattner said they were aiming at something closer to the actor model

I'd be interested in further information about this, if you can share some link here.

Re: Swift's Evolution

#49

Post by [deleted] »

karmelapple wrote: post #32
nicky0 wrote: post #30

Earlier quoted context omitted.

Anyone shipping swift code one day one had to be pretty masochistic. I just couldn't understand why people were doing it. It was obviously not ready for production use, and still isn't. But I'm happy that people are playing with it and the language is being refined so that I can start using it in a few years.

Why isn't it currently ready for production use? ABI stability is the only real issue I can see now.

[deleted]

Re: Swift's Evolution

#50

Post by nicky0 »

melling wrote: post #33
nicky0 wrote: post #30

Earlier quoted context omitted.

Anyone shipping swift code one day one had to be pretty masochistic. I just couldn't understand why people were doing it. It was obviously not ready for production use, and still isn't. But I'm happy that people are playing with it and the language is being refined so that I can start using it in a few years.

Developers are shipping both small and large projects with Swift. You may have a different opinion, for reasons that you haven't stated, but shipping production Swift apps is not an anomaly.

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 soon, I'm sure.

Admittedly I'm basing my opinion on Swift as it was about 12 months ago so hopefully someone can tell me how wrong I am and that the frequent IDE crashes and compiler bugs are fixed, refactoring is now available, autocomplete works really well, compile times have improved, and the language has no more breaking changes, etc.

It's just that I have work to do and Objective C is still solid and dependable. Playing with Swift was fun but I kept running into too many yak-shaving diversions to get even basic things done.

So is it time for me to switch?

Post reply on HN