91–100 of 160 posts
IMHO 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.
What C features can you not realistically use from C++?
Earlier 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.
IMHO 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.
What C features can you not realistically use from C++?
Earlier 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.
I recently started writing for macOS in Swift and, holy hell, the debuggability of the windowing toolkits is actually unparalleled. I've never seen something that is this introspectable at runtime, easy to decompile and analyze, intercept and modify, etc. Everything is so modular, with subclassing and delegation patterns everywhere. It seems all because of the Objective-C runtime, as without it you'd end up needing s…
> Writing GUIs for the Linux desktop is also a terrible experience. I've found the DX for GTK to be at least tolerable. Not fantastic, but I can at least look at a particular API, guess how the C-based GObject code gets translated by my language bindings of choice, and be correct more often than not. The documentation ranges from serviceable to incomplete, but I can at least find enough discussion online about it to…
As for sandboxing, 9front/plan9 uses namespaces, but shared directories exist, of course. That's the point on computing, the user will want to bridge data in one way or another. Be with pipes, with filesystems/clipboard (or a directory acting as a clipboard with objects, which would be the same in the end).
At 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.
Earlier quoted context omitted.
> 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.
Then what does it mean if "composition over inheritance" is also taught as a good practice in OO?
Earlier quoted context omitted.
Then what does it mean if "composition over inheritance" is also taught as a good practice in OO?
That's a rule-of-thumb to help beginners in making judgement calls. It doesn't mean inheritance should never be used.
I recently started writing for macOS in Swift and, holy hell, the debuggability of the windowing toolkits is actually unparalleled. I've never seen something that is this introspectable at runtime, easy to decompile and analyze, intercept and modify, etc. Everything is so modular, with subclassing and delegation patterns everywhere. It seems all because of the Objective-C runtime, as without it you'd end up needing s…
It's probably one of the better UI frameworks I think I've used (though admittedly a lot of that also is in part due to "InterfaceBuilder" magic and auto-wiring. Still I often wish for that sort of elegant "billions of hooks, but you only have to care about the ones you want to touch" experience when I've had to use other UI libraries.
Earlier quoted context omitted.
Weren't they acquired by Motorola?
Yes, after which they announced they were canning their "Atlas" project, which was meant to be an Interface Builder for the web. Motorola decided they wanted to keep the technology in house. No idea if they ever did anything with it!
I'm on the outside, but best I can tell:
- You're thinking of a UI design tool called "Ninja"
- Google purchased Motorola Mobility and the Ninja project got cancelled
- Google launched Google Web Designer, that basically had an almost identical UI. As far as I can tell the internals are different, but probably shared some code or at least design work.