How exactly are protocols a Swift "upgrade" to OO programming? They were in Objective-C since the mid 90s, adopted by Java as interfaces, copied by C# etc.
Also, protocols in Swift have a huge performance downside, because they decided to have them work across structs and classes: if you use a protocol in a function argument, the compiler doesn't even know the size of the argument at compile time, so copying the arguments has to be dynamically dispatched unless the compiler can figure it out in an extra optimisation pass...that's not possible when doing separate compilation.
> Runs reasonably fast, on par with Go or Java.
A downgrade...particularly considering the epic compile times.
Strange comment. I never said that Swift invented these language features; not sure what the relevance is that many of its features have existed for a long time and some other languages also offer them. Swift ties together a lot of features that in combination make it quite enjoyable to use. It's fine if you prefer other languages, there is certainly plenty of choice. Speaking of protocols, they offer some significant differences to protocols in ObjC which are very effective for writing saner and less bug-prone code, but I don't want to expound here on all aspects of the language. (there are many other simple features that make a big difference to the coding flow; computed properties, language-level optionals and the syntax surrounding their myriad uses, the list is quite long of good features to speed up safe, productive workflows)
Never had a problem with long compile times -- once you have your initial build, 90% of the time or more the incremental build process is very fast.
The languages I used for about 15 years were ObjC, C, C++, Clojure (and other langs before that). I find Swift to be a thoughtful blend of the key features of these four languages -- each of the things I like most about those langauges are in Swift, but it's the syntax in particular that I like most.
> I never said that Swift invented these language features;
Hmm...not sure how else to interpret "upgrade to OO programming with use of protocols" other than that there was an upgrade to OO, and that upgrade was with the use of protocols. Now it looks like you meant an upgrade of the way protocols are used in OO, but you won't say how they Swift's protocols actually constitute an upgrade.
Protocols replace many uses of OO from objc, making code much easier to understand. In addition, swift protocols are much more powerful in almost every way.
> How exactly are protocols a Swift "upgrade" to OO programming? They were in Objective-C since the mid 90s, adopted by Java as interfaces, copied by C# etc.
Typically you would write more protocol-oriented code - rather than using inheritance (which is mostly there for Objective-C compatibility) you define protocols and implement them for types.
This is a lot closer to traits in Rust than interfaces in Java. Among other things, a developer can define how a third party type implements a protocol they control, without subclassing or wrapping, as long as it does not require additional data.
I won’t teach Swift here, but Google is your friend. You can start by studying all the languages differences with regards to extending existing protocols, and how optional protocol conformance and methods are handled. Swift in many ways (not just with protocols) is like a fix for many headaches that objc provided in these areas. It’s partly why Apple encourages “protocol oriented” programming in swift over “object oriented” because of how rich the feature set is compared to objc.
Quite a lot has changed in objc since the nextstep days! And a lot more changed as Apple learned from that and built swift. My guess is you don’t know these languages as well as you think if you’re not clear about these differences.
How exactly are protocols a Swift "upgrade" to OO programming? They were in Objective-C since the mid 90s, adopted by Java as interfaces, copied by C# etc.
Also, protocols in Swift have a huge performance downside, because they decided to have them work across structs and classes: if you use a protocol in a function argument, the compiler doesn't even know the size of the argument at compile time, so copying the arguments has to be dynamically dispatched unless the compiler can figure it out in an extra optimisation pass...that's not possible when doing separate compilation.
> Runs reasonably fast, on par with Go or Java.
A downgrade...particularly considering the epic compile times.
> named parameters
Also there since the 80s, in a less weird way.
https://blog.metaobject.com/2020/06/the-curious-case-of-swif...
> ...professionally used about half a dozen languages ...
What languages were those, if I may ask?