Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Objective-C

inessential.com

Post reply on HN
Print view View original

61–70 of 160 posts

Re: Why Objective-C

#61

Post by rweichler »

steeleduncan wrote: post #50
vintagedave wrote: post #6

Earlier quoted context omitted.

I hadn't come across this. Insane (if true, I've never tried) that GnuStep is not 100% compatible, surely that would be the point. How easy is it to port, say, a Leopard-era Objective C app to ObjFW?

I tried this with an old iOS only game a few years ago. It is clearly not a heavily used library, but it seemed to work ok - There was a bug or two I had to patch, but the code is readable, so it wasn't a big deal - OFString, etc aren't intended to be 1:1 replacements for NSString, etc. This wasn't a real problem. They mostly match, and all I needed to do was write a few categories - The runtime functions are not com…

This is why I went with GNUstep. All of the APIs are 1:1 with Apple's, including the runtime (which is very important imo). It has AppKit support as well; its AppKit implementation is kind of half-baked, but at least it exists. Also, a lot of the APIs are kind of old. But looking at how Swift evolved over the years, maybe that's not a bad thing.

My main complaint with GNUstep is the licensing. The runtime itself is MIT which is great, but its implementation of Foundation/AppKit is LGPL. ObjFW, including its runtime, is LGPL. At least with GNUstep one day I can create my own version of Foundation based on Cocotron or swift-corelibs-foundation or something, and not need to muck with rpaths + ship a bunch of .dll/.dylib/.so files with my app in order to comply with the license.

Re: Why Objective-C

#62

Post by j16sdiz »

flohofwoe wrote: post #29

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 :)

Re: Why Objective-C

#63

Post by GaryBluto »

Towaway69 wrote: post #51
sgt wrote: post #22

That's it, I'm pivoting my startup technically and rewriting everything in ObjC! /s

I wonder how well AI generates Obj-C - it might well produce better quality code for your token/buck! In a previous life, one would select the programming language according how expensive developers were. Nowadays it's the quality that an AI can generate. What a wonderful future we've put together. /s

I've been using Opus 4.6 to make myself a harness for old Macs that uses models offered by the Github Copilot subscription.

From my experience, when it creates working Objective-C, it's great. When it slips up, it slips up majorly.

Re: Why Objective-C

#64

Post by mikehall314 »

samesimilar wrote: post #54
mikehall314 wrote: post #34

Every so often I get weirdly obsessed with Objective-J, which "has the same relationship to JavaScript as Objective-C has to C". It is (was?) an absolutely bonkers project. I think it has more or less died since 280 North was acquired. https://www.cappuccino.dev/learn/objective-j.html

Anyone know if this is or ever was the basis for Apple's iCloud web apps on iCloud.com (e.g. Keynote / Pages / Notes etc.)? Those apps are heroic attempts to replicate the desktop app experience in the browser. I'm curious what web framework is underlying it. Side note - if I could install 3rd party apps w/ similar UIs in my iCloud dashboard that would be interesting.

I think originally Apple was using SproutCore, which had similar aspirations to produce "desktop quality" web apps, and was one of the early frameworks to implement things like two-way data binding. This was back when iCloud was called MobileMe.

SproutCore 2.0 became Ember.js 1.0, but I don't know if Apple are still using it.

Re: Why Objective-C

#65

Post by 0x457 »

mikehall314 wrote: post #34

Every so often I get weirdly obsessed with Objective-J, which "has the same relationship to JavaScript as Objective-C has to C". It is (was?) an absolutely bonkers project. I think it has more or less died since 280 North was acquired. https://www.cappuccino.dev/learn/objective-j.html

Didn't expect to see cappuccino mentioned ever again. It was so wild, you can use AppKit documentation for cappuccino. Apps were so pretty and yet so fast.

I remember back in 2009 I really liked their coffee machine icon. I emailed the devs, they referred me to some design studio, and then to my surprise they replied and said that it's Francis Francis X1. Now I'm looking at it in my home office.

Re: Why Objective-C

#66

Post by mikehall314 »

sgt wrote: post #40
mikehall314 wrote: post #34

Every so often I get weirdly obsessed with Objective-J, which "has the same relationship to JavaScript as Objective-C has to C". It is (was?) an absolutely bonkers project. I think it has more or less died since 280 North was acquired. https://www.cappuccino.dev/learn/objective-j.html

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!

Re: Why Objective-C

#67

Post by kccqzy »

I 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 for building GUIs, but not for pure computation.

Re: Why Objective-C

#68

Post by kccqzy »

flohofwoe wrote: post #32
9rx wrote: post #28

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…

> can respond to messages that it doesn't have a method for. Clang produces a warning in that case though (something along the lines of "object might not respond to ..."), I don't think that feature is particularly useful in practice (also because it kills any sort of type safety) :)

And the reason it’s a warning and not an error (like in C++) is that it’s actually possible that the object can respond to such a message but the compiler doesn’t know about it.

Re: Why Objective-C

#69

Post by vintagedave »

zffr wrote: post #36
mikehall314 wrote: post #34

Every so often I get weirdly obsessed with Objective-J, which "has the same relationship to JavaScript as Objective-C has to C". It is (was?) an absolutely bonkers project. I think it has more or less died since 280 North was acquired. https://www.cappuccino.dev/learn/objective-j.html

Holy shit, it’s still being actively developed and maintained https://github.com/cappuccino/cappuccino

And wow, it's basically a web version of Cocoa! Check this out: https://ansb.uniklinik-freiburg.de/ThemeKitchenSinkA3/

Re: Why Objective-C

#70

Post by LoganDark »

kmeisthax wrote: post #57
LoganDark wrote: post #20

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 OLE, you're actually thinking of COM, not OLE. They were co-developed together: COM is a cross-language object system (like GObject), while OLE is a set of COM interfaces for embedding documents in other arbitrary documents. Like, if you want to put a spreadsheet into a Word document, OLE is the way you have to do that. Microsoft even built much of IE[0] on top of OLE to serve as its extension mechanism.

Oops, you are right about COM. I got them mixed up because I was thinking of the integration in WordPad.

> Mac apps are Mac native because Apple gives enough of a shit about being visually consistent that anyone using a cross-platform widget toolkit is going to look out of place. Windows abandoned the concept of a unified visual identity when Windows 8 decided to introduce an entirely new visual design built around an entirely new[1] widget toolkit, with no consideration of how you'd apply any of that to apps using USER.dll/Common Controls. As it stands today, Windows does not have a good answer to "what widget toolkit do I use to write my app", and even Microsoft's own software teams either write their own toolkits or just use Electron.

Mac apps are Mac native because the APIs are amazing and the ROI can be really really good. It takes so much effort to do the same from scratch, especially cross-platform, that, you're right, I can smell anything written in Qt (because the hitboxes and layout are off) or GTK (because the widget rendering is off).

With that said though, wxWidgets seems to translate EXTREMELY well to macOS, though last I used it, it didn't have good support for Mojave's dark mode. Maybe support is better nowadays. For example, Audacity appears to me as just a crammed Mac-native app rather than blatant use of a cross-platform toolkit, and wxPython used well can be completely mistaken for fully native.

Post reply on HN