Earlier quoted context omitted.
>[1] https://github.com/swiftlang/swift-evolution/blob/main/propo ... -- apologies to the authors, but even as a previous C++ guy, my brain twisted at that. Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C. These kinds of features are not intended for use in daily application development. They're systems-language features designed for building high performance,…
The "Swift has too many keywords now" meme makes me want to go insane. The vast majority of Swift code never runs into any of that stuff; so, what advocates of it are saying is in effect "we don't want Swift to expand into these new areas (that it has potential to be really good at) even if it's in a way that doesn't affect current uses at all." That said, the Swift 6 / Strict Concurrency transitions truly have been…
Why Objective-C
81–90 of 160 posts
Re: Why Objective-C
#82I do not get this argument at all. A long time ago I ported a simple sudoku solver to Objective-C by using the foundation classes, like NSMutableArray. It was terribly slow. All those messaging sending just to do what should have been a single instruction (or less!) That’s when I realized that if you want speed in an Objective-C app, you really are going to reach for the C subset. The objective part is really good fo…
Re: Why Objective-C
#83[objC retain]
Re: Why Objective-C
#84Earlier quoted context omitted.
One of my recurring language design hot takes is that it's easier to design for speed and then make it easy to use than it is to make it easy to use and then try to speed it up.
C++ is trying to make C easier to use for 40 years, and it's still not there. So I wouldn't call that easier.
Re: Why Objective-C
#85At this point in my career, I can't go back to a language that doesn't have support for Optionals or compiler validation of nullable types. I can sacrifice async or fancy stream apis, but I will never go back to chasing null pointer exceptions on a daily basis.
Obj-C does have a "nonnull" annotation now (apparently added to assist Swift interop). One of the final jigsaw pieces turning it into a really pleasant language.
Re: Why Objective-C
#86IMHO the one great feature of Objective-C (compared to C++) is that it doesn't interfere with any C language features. In C++ the C 'subset' is stuck in the mid-1990s, while Objective-C "just works" with any recent C standard.
Re: Why Objective-C
#87Earlier quoted context omitted.
In the end though most of those 'sending a message' actions are just fancy virtual method calls (e.g. an indirect jump), everything else would be much too slow: https://www.mikeash.com/pyblog/friday-qa-2017-06-30-dissecti... IMHO the whole 'message' and 'sending' lingo should be abandondend, the job of objc_msgSend is to look up a function pointer by certain rules. There are no 'messages' involved, and nothing is 'se…
> There are no 'messages' involved, and nothing is 'sent'. The conceptual difference is significant as an object can respond to messages that it doesn't have a method for. You are, conceptually, just sending a message and leave it up to the object what it wants to do with it (e.g. forwardInvocation:). That is, after all, what sets "object-oriented" apart from having objects alone. Optimizations that can be made under…
I wouldn't say so, most object-oriented languages don't work like Objective-C/Smalltalk. Today, I think most programmers would agree that inheritance is the defining feature of object-orientation.
Re: Why Objective-C
#88That aside, I was glancing through the source code for the engine and noticed this:
https://codeberg.org/brentsimmons/SalmonBay/src/branch/main/...
I wonder why they opted to do this instead of NSJSONSerialization - maybe I'm just misunderstanding the use for the class tho.
Re: Why Objective-C
#89Earlier quoted context omitted.
> There are no 'messages' involved, and nothing is 'sent'. The conceptual difference is significant as an object can respond to messages that it doesn't have a method for. You are, conceptually, just sending a message and leave it up to the object what it wants to do with it (e.g. forwardInvocation:). That is, after all, what sets "object-oriented" apart from having objects alone. Optimizations that can be made under…
> That is, after all, what sets "object-oriented" apart from having objects alone. I wouldn't say so, most object-oriented languages don't work like Objective-C/Smalltalk. Today, I think most programmers would agree that inheritance is the defining feature of object-orientation.
Understandably, language evolves. If OO means something different today, what do most programmers call what used to be known as OO? I honestly have never heard anyone use anything else. But I am always up for refreshing my lexicon. What did most programmers settle on for this in order to free up OO for other uses?
Re: Why Objective-C
#90I do not get this argument at all. A long time ago I ported a simple sudoku solver to Objective-C by using the foundation classes, like NSMutableArray. It was terribly slow. All those messaging sending just to do what should have been a single instruction (or less!) That’s when I realized that if you want speed in an Objective-C app, you really are going to reach for the C subset. The objective part is really good fo…
That is one advantage of C++ - you can use higher level features like generic data types/algorithms, member functions, constructors, destructors, and iterators and still have performant code. You can use object-orientation without having to heap allocate each object and pay the cost of "virtual" calls. (which many other object-oriented languages couple together)