221–230 of 263 posts
Earlier quoted context omitted.
So just like lots of Objective-C code, including the old NeXTSTEP Kits?
Swift's protocols are an evolution of protocols in ObjC. They offer additional features to make them safer and easier to write.
Earlier quoted context omitted.
> without a big performance hit. You might be surprised (I was). Most of the benchmarks I’ve seen place it more in the neighborhood of golang and v8, rather than the C, C++, rust neighborhood you might expect. Another commenter in this thread highlighted that the ref-counting GC is what keeps it out of the C / Rust performance neighborhood.
Swift doesn't have a GC. The automatic reference counting is a feature that just inserts retain/release statements at compile time, so there is no additional process that handles that. I would suspect that the performance hits originate from other things.
Earlier quoted context omitted.
Swift's protocols are an evolution of protocols in ObjC. They offer additional features to make them safer and easier to write.
I know both languages, did my learnings of Objective-C while porting code from NeXTSTEP into Windows 95, what additional features?
I might be in the minority here (though, reading the comments, it seems others have the same opinion), but I find Swift to be a step back compared to Objective-C. I really like the verbosity of Objective-C - this makes the code more readable and easier to understand, even (or especially) when reading a program the first time. Being a superset of C (and C++ with Objective-C++) means that, when necessary, one can easil…
Swift has been a hugely successfully language. Mostly at slowing down iOS runtime performance per clock cycle, and increasing compilation times. Its also been hugely successful at punishing companies for using it, since it didnt really work for a few versions. While there have been fewer crashes (sort of) due to the switch, as someone who worked for years in Objective C and years in Swift, I honestly never felt that…
Given karismatic a prize. I wonder if the current state of affairs is what Chris L had in mind?
Earlier quoted context omitted.
One of the interesting side effects of this is that those new libraries are going to have significantly worse introspection and hotpatching opportunities, so they better code them correctly, or things are going to really suck.
Would you mind to elaborate why this is the case? I am not in Swift/Obj-c ecosystem so I'm just clueless.
Apple, like most companies, does not provide official mechanisms to patch bugs out of their software. They also keep most of their system frameworks closed-source. However, it just so happened that they write most of their software in programming languages are are highly dynamic and easy to reverse engineer, allowing third parties to dig into implementation details when they need to, understand how things work, and most importantly, change things as needed. It's risky and dangerous work, but every major app you've ever used on an Apple device ships with several fixes like these at any given time.
The Apple of today has very different goals from their frameworks. Shipping symbols that help people understand how the system frameworks function is "needless bloat" that "exposes implementation details". Indirection and patching functionality is seen as overhead that can be removed for improved performance. App review does not like it when people ship self-modifying code, and as a result patching system frameworks is also not permitted due to codesigning. Swift in particular removes a lot of dynamic dispatch functionality, gets stripped far more aggressively, and compiles to code that is far less readable that what we had before.
What this really means is that we are moving closer to a system where what Apple ships is what you get. Being able to make tradeoffs in this area is necessary, but the ones Apple have chosen mean that they have to be very confident that they don't ship bugs. If they aren't capable of doing this, well, it's not a good tradeoff.
Earlier quoted context omitted.
What makes you say that? I don't think you can find many developers that would be willing to go back to Objective C.
Not sure why the only alternative to Swift is "going back", particularly when Swift is already going back in many ways. How about going forward to an alternative that actually isn't a step back.
The only people i ever hear complain are objc diehards and general apple haters.
Earlier quoted context omitted.
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 significan…
> 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. OK. ¯\_(ツ)_/¯
Earlier quoted context omitted.
I know both languages, did my learnings of Objective-C while porting code from NeXTSTEP into Windows 95, what additional features?
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 or…
No need for Google, as mentioned, I know both languages.
As for protocols not being encouraged in Objective-C, I migth own the wrong NeXTSTEP manuals.