4 ms·

Swift is an improvement over C for the problem domain. Something akin to Swift as a modern C replacement with keeping of the 'Objective' bits of Objective-C lay

Swift is an improvement over C for the problem domain. Something akin to Swift as a modern C replacement with keeping of the 'Objective' bits of Objective-C layered on top of it would have made for the ultimate language, though.

MBCook 3y ago
I don’t know how doable that would be. Objective-C does just about everything it can to make sure you can mess with it at runtime and confuse the ever living hell out of any type checker that wants to be strict. And the additional strictness is one of my favorite parts of Swift.
- randomdata 3y ago
  In theory, you are only reaching for the 'Objective' parts of Objective-C when your code actually benefits from being object oriented (in the Kay sense). Otherwise you can stick to pure C. Of course, C has a lot of ugly traps which makes it less than ideal for this domain. This hypothetical subset language addresses those issues. While, again, you would only reach for the 'Objective' parts when your code benefits from being object oriented. It is true that the inherit dynamism of message passing makes static analysis impossible to cover all cases, but as with all things in life there are tradeoffs. You lose the nice aspects of object oriented systems if you do not allow for that, and OO is particularly well suited to UI code. Of course, Swift abandoned the object oriented model completely. Which is fine. But Objective-C showed that you can have your cake an eat it too, offering OO where appropriate, and a non-OO language for everything else. Objective-C's downfall was really just in that C didn't age well – which, among other things, I am sure contributed to seeing the use of the 'Objective' bits where they weren't really appropriate.
  - pjmlp 3y ago
    Swift also does OOP, it did not abandoned anything.
    - randomdata 3y ago
      Technically true if you enable it with the @objc flag. However, the documentation suggests that you are only use that when needing to interface with Objective-C code, so it is not how one would use Swift in a pure Swift environment. Swift's primary object model design is much more like C++.
      - pjmlp 3y ago
        Playing with words doesn't change the fact that Swift fully supports OOP, even without any presence of @objc annotations. Classes, interfaces,interface and class inheritance, polyphormism, variance, type extensions, compile time and dynamic dispatch, overloading, associated types.
        randomdata 3y ago
        The original comment clearly states that, for the purposes of the comment, Kay's definition for OOP is in force. Your personal definition is cool and all, but has no relevance to the context established in this thread. Is there some value in this logically flawed correspondence that I have overlooked? What is it trying to add?

MBCook 3y ago

I don’t know how doable that would be. Objective-C does just about everything it can to make sure you can mess with it at runtime and confuse the ever living hell out of any type checker that wants to be strict. And the additional strictness is one of my favorite parts of Swift.

randomdata 3y ago
In theory, you are only reaching for the 'Objective' parts of Objective-C when your code actually benefits from being object oriented (in the Kay sense). Otherwise you can stick to pure C. Of course, C has a lot of ugly traps which makes it less than ideal for this domain. This hypothetical subset language addresses those issues. While, again, you would only reach for the 'Objective' parts when your code benefits from being object oriented. It is true that the inherit dynamism of message passing makes static analysis impossible to cover all cases, but as with all things in life there are tradeoffs. You lose the nice aspects of object oriented systems if you do not allow for that, and OO is particularly well suited to UI code. Of course, Swift abandoned the object oriented model completely. Which is fine. But Objective-C showed that you can have your cake an eat it too, offering OO where appropriate, and a non-OO language for everything else. Objective-C's downfall was really just in that C didn't age well – which, among other things, I am sure contributed to seeing the use of the 'Objective' bits where they weren't really appropriate.
- pjmlp 3y ago
  Swift also does OOP, it did not abandoned anything.
  - randomdata 3y ago
    Technically true if you enable it with the @objc flag. However, the documentation suggests that you are only use that when needing to interface with Objective-C code, so it is not how one would use Swift in a pure Swift environment. Swift's primary object model design is much more like C++.
    - pjmlp 3y ago
      Playing with words doesn't change the fact that Swift fully supports OOP, even without any presence of @objc annotations. Classes, interfaces,interface and class inheritance, polyphormism, variance, type extensions, compile time and dynamic dispatch, overloading, associated types.
      - randomdata 3y ago
        The original comment clearly states that, for the purposes of the comment, Kay's definition for OOP is in force. Your personal definition is cool and all, but has no relevance to the context established in this thread. Is there some value in this logically flawed correspondence that I have overlooked? What is it trying to add?