Hacker News Reader

Comment by brutus1213 | Hacker News Reader

This post hits it right on ... the renaming thing and the removal of traditional for loops ... I'm just bewildered by it. When I saw it, my reaction was ... WHY??? The incompatibilities between swift 2 and swift 3 made me thankful I did not invest the language prior to 3. While I stepped into it at this point, and think the language has a lot of potential (not changing the damn language .. I mean having a large eco system of useful libraries around it). Apple still has an opportunity if they don't screw it up further.

View on HN

There is never a better time to make a breaking change than right now.

Why does make treat tabs and spaces differently? Because Feldman's original version had that bugs and he didn't want to disrupt the <10 users and their <100 makefiles. That was the wrong decision, though he didn't know it at the time.

However many users Swift has today, tomorrow there will be more. However many lines of code are written in it, tomorrow there will be more. The pain of making a change will only increase.

Apple was up front with everyone about Swift 1: there will be source-breaking changes in the future. Swift 3 was targeting source stability so it was the last chance to make such large changes.

In contrast, Swift 3.2 and Swift 4.0 are compiled by the same compiler and can be linked together. That means you can upgrade each module separately and don't have to wait for dependencies to upgrade. That's a huge win.

Swift 4 also brings Codable which will shave a massive amount of boilerplate from many codebases. The String overhaul is great too, along with generics improvements. These all affect the standard library and thus ABI stability.

The Law of Exclusivity is in, which is the core of the upcoming memory ownership model, which itself will enable async and other concurrency paradigms. This also affects ABI.

Once ABI stability lands the pace of standard library changes will necessarily slow dramatically. It is important to take the time to get things right, rather than rushing and locking bad or insufficient designs into stone.

> the removal of traditional for loops […] When I saw it, my reaction was ... WHY???

For all of these reasons, at least: https://github.com/apple/swift-evolution/blob/master/proposa...

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 array, and a safer way to do that probably could have stopped countless vulnerabilities & bugs occurring over the years.

> 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)

    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...
  }

And you can trivially package the process into an iterator anyway if it's a case you encounter often.

   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.

As you indicate, the renaming may be a net loss for those who have to do he renaming, but, from Apple's viewpoint, is more than offset by the expected gains when writing new code by both current developers (where the gain may be small, zero, or even negative because they already are familiar with the API) and developers yet to start using Swift.

So, the question should be whether Apple should have prioritized new users of the language over their existing language users. I think they made the right call, more so because they pre-announced it. Not only didn't they claim the language was frozen, the specifically said it would see changes.

I like the renaming, even though I don't like the way they went about it (the migration was, and continues to be a huge headache). I also like that they removed traditional for loops — what would be your reason for keeping them?

Reply on news.ycombinator.com