Live data from Hacker News

Why Objective-C

inessential.com

131–140 of 160 posts

Re: Why Objective-C

#131

Earlier quoted context omitted.

how would you write something like #include #include #include int main(int argc, char** argv) { using namespace std::literals; std::string foo = "foo:"; foo += argv[0]; std::map m{ {foo, 123} , {"count: "s + std::to_string(argc), 456} }; std::println("{}", m); } in C

Sure, there are nice parts of C++. And there are also brain-dead parts that add needless complexity such as: * rvalue references * the difference between auto, decltype, typeof * unreadable template monstrosities * various different flavors of "smart" pointer * the continued existence of footguns relating to UB, dangling pointers, unexpected temporary lifetimes, etc * total absence of a build system or package manage…

No worries, you get some of those in C23, and C2y.

Where is C's build system and package management?

Yeah, because using _Generic alongside typeof and preprocessor macros isn't half-assed attempt at generics.

Re: Why Objective-C

#132

Earlier quoted context omitted.

So you silently ignore something being null when you don't expect it to be? That sounds even worse.

It's just that pointer?.doSomething() is the default. Le horreur!

Not really, because doSomething is not called if reference/pointer is null, whereas in Objective-C there is still a message that is sent to the NULL recipient.

Re: Why Objective-C

#133
post #93
post #71

Earlier quoted context omitted.

What C features can you not realistically use from C++?

C11 atomics, C11 threads, variable length arrays, safely reading from an inactive union member, designated array initializers, compound struct literals, implicitly converting a void pointer to a typed one, and the list goes on.

Indeed, and some of those, thankfully as C++ is TypeScript for C.

Re: Why Objective-C

#134
post #30

I still find Objective-C++ useful for writing MacOS apps that make heavy use of C++ libraries (e.g.; Eigen, OpenCV). The caveat is I have done a lot of Objective-C programming and Swift is still not as seamless as I would like bridging with modern C++ and the the STL.

I've been playing around with low-level Metal a bunch lately, any many of their docs and samples seem still be mostly in Objective-C/C++ and not Swift, so have been forcing myself to get into it. At first I had the usual revulsion to the syntax, but after a few days getting used to it, I actually don't mind it at all now. (I still wouldn't say it's "elegant", but I can live with it). Being Metal shader code is basica…

Metal is the last Mac OS framework that was fully done in Objective-C, however contrary to Microsoft, at least Apple does provide first class bindings to Swift.

To this day, .NET is not welcomed on the Windows division, and they rather go out of their way producing stuff like WinRT/UWP with the outcome we all know.

Re: Why Objective-C

#135

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…

Welcome to Smalltalk, Lisp, Java and .NET, which alongside NeXTSTEP/OS X, share a common linage of tooling ideas, and programming language features.

Hence why given the option I rather stay in such environments.

Now Android Studio is the product of Google's mess, and I am glad to have moved away from Android development, it also doesn't have anything to do with enjoying pure Java development on desktop (Swing, SWT, JavaFX) and server.

Re: Why Objective-C

#136
post #62

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.

I think C++ have caught up with C99 already. So it's late 90s, not mid-90s :)

No not really, for instance the designated init feature in C++20 is a distinctive C++ feature which is not compatible with C99's designated init. AFAIK the C subset hasn't changed since C++98.

Re: Why Objective-C

#137
post #71

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++?

Any language feature added in C99 and later.

In GCC and Clang it's quite relaxed since their C++ frontends pull in a couple of modern C features as non-standard C++ extensions, but MSVC has a strict separation between the C++ and C frontend and doesn't allow this sort of 'cross-pollution'.

As a quick example, this C99 code block has at least 4 features that don't work in C++:

https://github.com/floooh/sokol-samples/blob/91bd8c6f9f52149...

- taking the address of an adhoc-created struct in a function call

- random array access in struct initialization

- designator chaining in struct initialization

- designators can be out-of-order in C but not C++

...also using unions as different views on the same memory is actually useful sometimes.

Re: Why Objective-C

#138

Earlier quoted context omitted.

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!

Best I can tell, it turned into Google Web Designer! 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.

Possibly! The tool was definitely named Atlas when it was going to be an open source tool made by 280 North [1]. But it could have been renamed Ninja after Moto acquired it.

[1] https://arstechnica.com/gadgets/2009/03/atlas-a-visual-ide-f...

Re: Why Objective-C

#139

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…

> Reading all the really, super old documentation that explains entire subsystems in amazingly technical depth

Any links?

> Maybe this is also why Smalltalk fiends are such fans.

I started getting interested in Smalltalk after I tried writing a MacOS program by calling the Objective-C runtime from Rust and had a surprisingly good time. A Smalltalk-style OO language feels like a better base layer for apps than C.

Re: Why Objective-C

#140
post #132

Earlier quoted context omitted.

It's just that pointer?.doSomething() is the default. Le horreur!

Not really, because doSomething is not called if reference/pointer is null, whereas in Objective-C there is still a message that is sent to the NULL recipient.

No, the messenger identifies the NULL recipient and does not send the message.
Post reply on HN