He was bold enough to create a DSL starting from C. Too many black bar-worthy losses lately.
Given the impact of his contributions, I don't understand why there isn't a black bar.
Brad Cox has died
151–160 of 197 posts
Re: Brad Cox has died
#152Earlier quoted context omitted.
as i recall, `libobjc` is ~25% of app launch time. `objc_msgSend` is quite expensive when you're making hundreds of thousands to millions of calls per second.
Although Swift has the spotlight, Objective-C keeps being improved. "Advancements in the Objective-C runtime" https://developer.apple.com/videos/play/wwdc2020/10163/
Swift uses the Objective-C runtime.
Re: Brad Cox has died
#153Was it covid?
Re: Brad Cox has died
#154Earlier quoted context omitted.
Although Swift has the spotlight, Objective-C keeps being improved. "Advancements in the Objective-C runtime" https://developer.apple.com/videos/play/wwdc2020/10163/
Swift uses the Objective-C runtime.
Swift is tiptoeing between static and dynamic typing, preferring the former when feasible, but often needing some of the latter when dealing with the UI.
Re: Brad Cox has died
#155Earlier quoted context omitted.
I'm curious--what happened to Objective-C in that fight with C++? Why didn't people go for its simplicity?
As usual, platform languages win. C++ was born at Bell Labs and quickly integrated into their workflows as C with Classes started to get adopters. This raised the interest of the C compiler vendors, so by the early 90's, all major C compiler vendors were bundling a C++ compiler with them. Additionally, Bjarne got convinced that C++ should follow the same path as C and be managed by ISO, so the C++ARM book was written…
> Apple was one of the major OS vendors that never cared much about C for OS development
It's true that MacOS Classic kept providing Pascal headers for most of its APIs for a long time (I don't recall whether they ever stopped), but internally, they started switching to C by the late 1980s (as an external developer, I could tell by one bug which would never have made it through a Pascal compiler, but was typical for the kind of bugs that wouldn't get caught by a K&R C compiler), and by the late 1990, it was all C and C++, just with Pascal calling conventions for all public facing APIs. In my time at Apple, I never encountered a single line of Pascal code.
Re: Brad Cox has died
#156There is no doubting the legacy of Objective-C (especially given the high likelihood you are reading this post on a mobile device, using app written in Objective-C), but to truly appreciate Brad's legacy, am curious about the appeal of using Objective-C. Having developed only one small iOS app with Objective-C code, I was mostly turned off by its overall verbosity in the context of NS prefixes. Hence, I ask the quest…
Objective-C is a very simple, clean language–very much unlike its other "object-oriented-C competitor" C++. Unlike C++ it's a 100% superset of C, and it takes its cues from Smalltalk where objects send messages to each other rather than statically call each other's procedures. To support this, there is a very rich runtime that allows all sorts of reflection and metaprogamming atypical in a compiled language.
Tastes may differ. To me, C++ looks like an organic extension of C syntax, while Objective C looks like an alien graft on top of C.
Same with semantics: In C++ there is a continuum from POD structs to adding non-virtual methods to adding virtual methods. In Objective C there is a gaping chasm between C types and Objective C types, and weirdness occurs when you mix the two (e.g. pass a method taking an (int) to a place expecting a method taking an (NSNumber *)).
Containers (arrays and dictionaries) in Objective C, I find particularly ugly, especially in earlier (pre-2010 or so) versions of Objective C. They can contain only Objective C objects, not C objects, but can wildly mix and match objects of different types (this has been helped by Objective C generics by now). Access to elements is very verbose (this has been helped by syntactic sugar by now).
Just recently, I had to review Objective C code using a multidimensional numeric array. Even in modern syntax, it was no joy to read, and I wept for the senselessly murdered memory and CPU time. But if it had been written in pre-2010 Objective C, I might have lost my will to live for weeks.
Re: Brad Cox has died
#157I mentioned Brad Cox's "software ICs" today on the phone in a conversation about big ideas in programming, not knowing that he'd passed away a couple weeks ago. Here's the Objective-C paper at last year's HOPL: "The origins of Objective-C at PPI/Stepstone and its evolution at NeXT" https://dl.acm.org/doi/10.1145/3386332 https://news.ycombinator.com/item?id=23516334
That's a truly excellent paper (and exceptionally honest, considering some of the touchy subjects involved) and disentangles many of the origins of the various concepts in Objective C between the Stepstone and NeXT environments.
Re: Brad Cox has died
#158This is Apple Objective-C right? I thought it was developed in house, didn't realize it had already existed.
It was originally developed by Cox's company in the mid 1980s, and then adopted by Steve Jobs' company NeXT in the late 1980s as the official language of NextStep. The Apple connection is only that Apple bought NeXT and that its OS X is really just a Mac-skinned version of NextStep.
> OS X is really just a Mac-skinned version of NextStep.
You could probably describe Rhapsody that way, but by the time Mac OS X came out, I don't think that's an accurate characterization at all anymore.
In addition to the sizable Carbon subsystem, the NeXTStep pieces were also changed substantially, e.g. the refactor of Foundation that extracted CoreFoundation and the change of the graphics subsystem from Display Postscript to Quartz.
Re: Brad Cox has died
#159Earlier quoted context omitted.
Objective C loses to C++ for performance if you really start exploiting OOP a lot. The fact the you can swizzle methods in ObjC says a lot about the "weight" of the underlying implementation ("it's all messages") compared to C++.
The fact that you can swizzle methods also says a lot about its power and flexibility. When Steve Jobs was at NeXT, he was quoted numerous times bashing C++ as having 'dead objects' while pointing out that ObjC objects were 'alive'. One seldom needs to make use of swizzling, but when you do need it, it's an awesome capability. As prabhatjha pointed out in another comment in this thread, swizzling was used to automati…
Absolutely. I've used swizzling myself to fix issues with audio plugin's GUIs (to limit how fast they are allowed to redraw themselves). It's very clever and sometimes very useful.
But the ability to do that comes with certain costs, and performance is one of them. The fact that these "methods" are dynamically dispatched sometimes matters, and you can't change that any more than you can swizzle in C++.
Re: Brad Cox has died
#160Earlier quoted context omitted.
Although Swift has the spotlight, Objective-C keeps being improved. "Advancements in the Objective-C runtime" https://developer.apple.com/videos/play/wwdc2020/10163/
Swift uses the Objective-C runtime.
Swift can uses the Objective-C runtime for interoperability with Objective-C code, just like .NET uses COM on Windows.
They need to interoperate with the rest of the platform.