tag:blogger.com,1999:blog-8397311766319215218.post6265441547953907258..comments2023-11-29T18:05:17.337+01:00Comments on metablog: The sp(id)y subset, or Avoiding Copeland 2010 with Objective-C 1984Marcel Weiherhttp://www.blogger.com/profile/11651004661887001433noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-8397311766319215218.post-84909056067648773812014-05-03T18:33:26.349+02:002014-05-03T18:33:26.349+02:00I think you're right that Apple's current ...I think you're right that Apple's current direction is an uncomfortable truce between order and chaos.<br /><br />I wouldn't characterize it as "Objective-C without the C", though. In fact, it seems more the direction of Java or C++, keeping the intermingling of objects and structs/pointers that is the source of the problems and then trying to get out of the mess through static analysis and static restrictiveness, but with the default still being raw pointer access that can and will crash.<br /><br />As examples, see CoreAnimation and more recently SceneKit, which both uses structs fairly randomly in unexpected places where they could easily have used objects instead. And performance really isn't the issue here, these abstractions move sufficient other information that the object overheads shouldn't be significant (as also demonstrated by Quartz use of equally heavy CF-style objects).<br /><br />Or the "NSInteger" madness, which causes great confusion because programmers that don't have the history don't understand that these are primitives that behave different from objects such as NSNumber (and how could they?)<br />Marcel Weiherhttps://www.blogger.com/profile/11651004661887001433noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-11719365741618096432014-05-03T17:24:02.617+02:002014-05-03T17:24:02.617+02:00Yes, the "Objective-C without the C" ide...Yes, the "Objective-C without the C" idea. As I think I mentioned on the podcast, that sure appears to be where Apple is going, but it still seems like a bit of an uncomfortable truce between order and chaos to me.John Siracusahttps://www.blogger.com/profile/11921986837458094573noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-35813430330302564452014-05-03T16:37:37.664+02:002014-05-03T16:37:37.664+02:00Thanks, I both read the "revisited" arti...Thanks, I both read the "revisited" article (it's actually one of the links above) and listened to the podcast all good stuff! Heck Guy and I had a little twitter-exchange about him mangling my last name :-)<br /><br />The, er, point stands that the pointer-safe language you are looking for is already present inside Objective-C, we just need to give it a chance to come out. And I have reason to believe that it isn't even that hard...not necessarily to make such errors impossible, but to make you have to really go out of your way to get them, which seems sufficient to me.<br />Marcel Weiherhttps://www.blogger.com/profile/11651004661887001433noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-4493468530545251512014-05-03T16:02:42.065+02:002014-05-03T16:02:42.065+02:00I don't think I said that a VM is required for...I don't think I said that a VM is required for memory safety. (Just look at Perl, for example: no VM, not interpreted, memory-safe.) Also, you should read my <a href="http://arstechnica.com/apple/2010/06/copland-2010-revisited/" rel="nofollow">Copland 2010 Revisited</a> article from (appropriately) 2010. I also did a <a href="http://www.imore.com/debug-32-john-siracusa-copland-2014" rel="nofollow">long, rambling podcast</a> on this topic with Guy English last month.John Siracusahttps://www.blogger.com/profile/11921986837458094573noreply@blogger.com