What makes code “Swifty”? | Hacker News Reader

What makes code “Swifty”?

swiftbysundell.com

68 pointsAustin_Conlon19 comments

The title here is misleading. Most of this applies to Objective-C. There's nothing wrong with the article as far as programming advice goes, but it has nothing to do with Swift idioms.

> So, to make our code more “Swifty” from a performance point of view, sometimes all that we have to do [is literally the same thing we would do in Objective-C]

Is anyone writing consistently good, up-to-date Swift documentation for experienced programmers? Some of the early books haven't been updated since the earliest Swift versions.

SwiftUI is very poorly documented by Apple and much of the third-party SwiftUI docs are for the obsolete WWDC version.

> Most of this applies to Objective-C.

Objective-C’s type system is much poorer than Swift’s, and it lacks a number of expressive operations. The “before” examples are generally how a lot of people would actually write code in Objective-C.

Which ones?

I wrote ObjC for 7 years, Swift for 3. I only looked at the first two examples, they both were generic programming advice, nothing to do with the language

The first three. Objective-C doesn't have enums with associated values and it's common to store things in heterogeneous collections or stringly-keyed collections. Creating protocols for generic constraints is also rare–informal protocols (respondsToSelector, anyone?) are instead quite prevalent. And Objective-C's "collection" APIs are much less powerful than Swift's: I might use a regex replacement instead of four calls to replacingOccurrences(of:with:), but it's the same principle.

To answer your question: objc.io

I’ll tack on a couple sources to this:

http://pointfree.co - high quality content, emphasizing functional programming.

https://oleb.net/blog/ - blog of Ole Begemann, co author of Advanced Swift (good resource itself)

https://appventure.me - Benedikt Terhechte’s topical guides to Swift features

https://andybargh.com/blog/ Andy Bargh’s topical articles

The first example utilizes a feature of Swift's type system which obj-c does not have (enums with associated values) to write code which is better than could be done in obj-c. This seems like a perfectly good example of improving code by making it more "Swifty", as one of the distinguishing features of Swift is that it has a more powerful type system than most mainstream languages.

The second example is strange. It's improving the code by making it call the correct method from the standard library rather than the wrong one. I guess that's not bad advice, but I have no idea what it has to do with Swift in particular.

The third one is a missed opportunity. Swift has some unusual ideas around how things should be named (partially inherited from Smalltalk via obj-c, but also partially new), but instead of talking about that it's just generic "give things useful names" advice that has little to do with Swift.

Oh how wonderful will it be to program front end and backend web apps with Swift, I just can’t wait

I'm hoping apple starts to take the cross platform story more seriously. It sounds like it's a big topic for the release of 6. I find it to be a really pleasant and productive language to work in.

Performance is not really a USP of Swift. It's certainly possible to write high-performance Swift code (with the help of a lot of profiling) but if your main concern is performance, you would be much better served reaching for Rust or C/C++.

IMO the most important things about Swift code is that it has nice safety features, and it is easy to write clear, self-documenting code.

I’d love to see Sundell go and optimize the code on the Computer Language Shootout so we could see its potential in a swifty way.

there's always been something i wondered about swift : how does it compare to other PL in terms of performance ?

The initial promise was to have it be comparable to other compiled languages ( java , c++, whatever), but i've yet to find a real benchmark.

Or rather, the ones i've seen made it look more on the range of interpreted/dynamic languages ( ruby / python or node), at least for server side projects. Which came as a surprise to me.

Has any real work been work on that issue somewhere ?

Rather slow currently, thanks ARC.

https://github.com/ixy-languages/ixy-languages

This is not a good representative benchmark for Swift. It uses lots of reference counted objects within tight loops, which is a worst-case for Swift. It's also not idiomatic Swift - classes are used in many places where they should not be.

Also, it's a benchmark which needs special hardware to be run, so it's not easy to try to reproduce or improve on this result.

The same conditions apply to all languages.

No they don't. GC language, for example, are more sensitive to memory pressure to reference counting overhead.

First, Swift is also a GC language.

Secondly, with exception of Java, the remaining ones on that benchmark support value types and native heap allocations.

We can get into semantics all day, but the point still stands that different languages are going to perform differently on any given benchmarks due to the performance constraints of that language.

Also I would love to see an implementation of the swift benchmark which doesn't lean on reference types, which is not idiomatic swift and is likely the reason the ARC penalty is so high here.

Reply on news.ycombinator.com