4 ms·
From the abstract when they try to describe how Obj-S is better than Swift they kind of utterly fail: "While Swift fixes some of Objective-C's most obvious fla
by slver 5y ago
From the abstract when they try to describe how Obj-S is better than Swift they kind of utterly fail:
"While Swift fixes some of Objective-C's most obvious flaws that were due to it being constructed by crashing two existing languages into each other, it discards the good with the bad. With a vengeance. Objective-S also discards the bad, while enhancing the good and taking it to an entirely new level."
So Swift is Obj-C without the bad parts, but also without some good parts, but Obj-S is Obj-C without the bad parts and the good parts are gooder.
I'm sorry but that's a poor elevator pitch about... anything. Gotta get more specific.
- mpweiher 5y agoYeah, didn't have much energy left at that point. Still very short: Swift improves on and really doubles down on the algorithmic parts. But that's not where the actual problems are [Stroustroup]: “C with Classes was explicitly de- signed to allow better program organisation; computation was considered a problem solved by C” Objective-C is also largely algorithmic, but flexible enough that you could create some decent architectural adapters. Building and using these architectural adapters is where the magic was. As an algorithmic languages it was at best mediocre. Swift not only doubles down on the algorithmics, and yes, it is better at those if you don't consider performance, but also tightens things up so creating those sorts of architectural adapters becomes harder if not impossible. What Objective-S does is take a look at all those architectural adapters we're building using somewhat rickety metaprogramming and instead of forbidding that goes "hey, we seem to want and need to program with a combination of different architectural styles, let's make that possible using plain old programming, rather than fancy metaprogramming". And in order to make that possible with plain programming, the language has to naturally support different architectural styles. And of course they really, really went in the wrong direction with the tooling.
- slver 5y agoWhat are architectural adapters
- mpweiher 5y agoSoftware that adapts between architectural styles. The Unix stdio library, for example, is an architectural adapter between the pipes and filters architectural style of the shell and the call/return architectural style of C.
- slver 5y agoSo it’s just an adapter. Why would Swift not be suitable for it?
- mpweiher 5y agoAn architectural adapter. I can't tell you why Swift would "not be suitable" for it as I never claimed that it wasn't. What I did claim is that it is less suitable for writing these kinds of adapters between its native architectural style and non-native architectural styles, because it is more restrictive. And being more restrictive is entirely intentional. And being more restrictive is probably a Good Thing™, overall, in order to prevent silly mistakes, f it weren't for the fact that large parts of the programs we write require, well "strongly request", different architectural styles. Now if you were actually able to express different architectural styles naturally within the language, you wouldn't need to do so many unsafe metaprogramm-y hackish things. ¯\_(ツ)_/¯
- slver 5y agoWhat you call unsafe hackish things is basically the default level in C. It makes no sense to both call this unwanted in Swift and wanted as a whole language. It comes off as you just don’t like the “unsafe” word.
- mpweiher 5y agoNot sure where you are coming from. If you actually support different architectural styles in the language, like in Objective-S, then you don’t have to resort to the kinds of hackish implementations that were necessary, but at least possible and reasonably easy in Objective-C. And that are still necessary, but much more difficult in Swift, because it (rightly) tries to restrict hackish things, but (wrongly) still doesn’t support other needed architectural styles.