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 question on behalf myself and others who did not appreciate the language and did not give it a proper chance... what did I miss and what are its top appeals?
Nevertheless, Rest In Peace to a pioneer.
Objective-C is a thin-layer on top of C, adding Smalltalk-inspired object support. That's pretty much all there is to it. C, with some new syntax for objects. In the context of a world where C is the norm, that's pretty appealing. This is before Java existed, too.
The "NSWhatever" stuff, as far as I'm aware, isn't part of the language. That's all in the frameworks Apple/NEXT developed for Objective-C. (Note that the base object is called Object, not NSObject, and the integer class is Integer.) NSString is probably named that way because Objective-C doesn't include a string class (nor does C, as a string is just an array of bytes until you write a wrapper to get fancy) and NEXT made one. They were just namespacing the NEXTStep classes.
Objective-C actually doesn't require a base object (although these days it essentially does), but Object and NSObject are both examples of root objects. IIRC, reference counting is not in Object and was a NeXT invention.
This is actually a blessing because NS-/name prefixes are a simple approach to naming that keeps you humble. If you let programmers have namespacing they will invent enterprise software frameworks where every class is six layers deep in a namespace of random tech buzzwords they thought up.
> Hence, I ask the question on behalf myself and others who did not appreciate the language and did not give it a proper chance... what did I miss and what are its top appeals?
It implements message-based programming, which is "real" OOP and more powerful than something like C++, where OOP just means function calls where the first parameter goes to the left of the function name instead of the right.
In particular it implements this pattern: https://wiki.c2.com/?AlternateHardAndSoftLayers which is great for UI programming and lets you define the UI in data rather than code. Although iOS programmers seem to like doing it in code anyway.
No, it's message-based programming, which is a very powerful and useful tool. It's not the one true inheritor of the fundamental OOP concept.
OOP wasn't defined by "you send messages to objects", it was defined by the idea that objects had their own semantics which in turn constrained/defined the things you could do with them. Some OOP languages implemented "doing something to an object" as "send it a message"; some didn't.
ObjC is in the former group; C++ is in the latter.
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.
Object-related syntax in ObjC is completely alien to C. Object-related syntax in C++ (mostly) extends C structure syntax.
Yes, ObjC takes its cues from Smalltalk. C++ does not. And so... ?
[EDIT: ok, so people want to interpret "superset" as meaning "every valid C program is a valid Objective C program too. This is, with very few exceptions, true of C++ as well ]
I'm not an expert on this, but I suspect that the main reasons it was chosen for iOS were:
- The technical limitations of the original iPhone meant that you needed to use a low-level language.
- The legacy of NeXT at Apple.
Two things that I used to like about it:
- Combination of static typing and at the same time pretty high level dynamic typing: it was practically possible to call any method on any object, right or wrong, just like in dynamic languages. For performance critical parts you could always resort to C. Later, as a little bonus it was also possible to resort to... C++. There was such a beast as Objective-C++.
- The method calling syntax. Quite unusual but neat. I liked it a lot.
However, Swift ruined it for me. Now that I'm a total Swift convert and I feel a 2x or even 3x boost in productivity I can't even look at Objective-C code anymore.
It's still considered a merit by some.
It's easy to write and easy to read (especially years later). It's just such a joy to work with.
Wonderful story. I wish his family all the best.
I love Objective-C and consider it a beautiful language. Back in the day I re-discovered my love for programming when I started to learn this language. This was when I was still in the Java world.
As a side project I tried to build a drone (unmanned navel vehicle) powered by objective-c. I have abandoned the effort but posted the code on GitHub - it was a joy to work with the language and the funnest side project I’ve worked with.
These days I work with python and golang for job/hobby but I always am grateful to have spent time with objective-c. Reflecting back if I haven’t spent time with this language, today I would of not been a programmer.
Thank you Brad Cox for your work and positive influence.
The second thing that I found astonishing was that these strings were actually being used by the runtime to determine what to call, i.e. something that in basically every other native language I've seen would be a direct or indirect call to an address or vtable offset. All this in an application that has no exported functions. I can definitely see how it would make RE extremely straightforward! Efficiency, on the other hand...
https://cs.gmu.edu/~sean/stuff/java-objc.html
And what many J2EE/JEE haters aren't aware of, it started as an Objective-C framework during the OpenSTEP days, and the OS was called Spring.
https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere
In the talk, Alan talks about the ant who lives his life on a single plane of existence, the "Gulley World" or "Reality".
The ant goes to work, he finds stuff to eat, he lives his life in this Gulley World, which is depicted as a pink 2D plane. However some times on this pink plane there are little spots of blue. They represent thoughts that don't belong in the pink plane.
Sometimes those blue spots turn into blue planes, and the ant we are following starts to move along that plane instead of the pink one. Everyone in the pink plane thinks he is wrong. Everyone can see the pink plane, in all its reality. It is not until you walk on the blue plane until you can see "another way".
The metaphor being that we developers built a world where we started to take the general idea of OOP and construct a lot of "reality" around it. A lot of process, a lot of formalization so we could build mechanical systems of gears that slotted together. I think Alan's idea of OOP was something more fluid, more organic than this. The world is messy and we often try to abstract the mess away in these overbearingly weighty and hierarchical programs that everyone agrees is the right way.
I think Objective-C was the most widely used and successful walk on this blue plane. Millions of developers were exposed to the idea of message passing as a form of OOP, which is an astounding accomplishment. It really is a neat language, and I had a lot of fun learning it.
Brad definitely walked on the blue plane. RIP.
I've heard a good deal about Alan Kay's dissent of the state of OOP, but I've never seen a concise summary of his vision or the principles that Kay's 'ideal' realization of OOP would adhere to.
Does such a resource exist, written by Kay himself or otherwise? Or do I just need to go play around with Obj C or Smalltalk to really "get it?"
Per the original anecdote, being told "it's all blue!" isn't that impressive when you've seen the spots of blue and shrugged them off as just normal little detours amongst the pink, and can't imagine everything being blue. You have to see it for yourself.
Smalltalk 76-like...
Your/Alan's "blue plane" analogy remindeded me of this:
They said, "You have a blue guitar,
You do not play things as they are."
The man replied, "Things as they are
Are changed upon the blue guitar."
He worked hard to enable software reuse. No one was interested in his idea of trying to monitor component use during runtime to pay developers. That was an unworkable approach, and I told him that then. But the general world of making it easy to reuse components is a reality today, via open source software and package managers.
So, a hat-tip to him and all the other pioneers who helped make the world a better place.
This reminds me of Project Xanadu's ideas about transclusions and associated royalties.
What a coincidence that this was posted recently: https://news.ycombinator.com/item?id=25875386
In addition, the telecomms were generally not interested in the very early Internet (TCP/IP) because they couldn't figure out how to do per-packet metering, and they assumed that was necessary.
All 3 examples show that trying to do fine-grained metering, in ways that cause tremendous overhead, often don't work. It is sometimes better to make something so that it is "too cheap to meter".
People are experimenting doing this in blockchain smart contracts. It’s transparent and supports micropayments as well.
I really loved the idea of being able to create libraries of code that could just be called for a small fee or copied for free if one didn't have the funds. I hope this idea continues to catch on, it seemed to me to be a perfect incentive fit for the open source world.
This is a nice idea although I never thought it could've worked; it seems like it took forever for people to stop trying though. The app-and-library organization of software is more natural than document-and-component organization because of Conway's law, which is surprisingly hard to escape.
The way to make people pay for software components is not to ask them for money at runtime, but to do so much much earlier in the development cycle: at design time.
In the instances that I have seen this business model work, the components are usually bought as part of a collection [1]—think source-available components similar to the model made famous by Apache Commons (Commons Codec, Commons Util, Commons Lang etc). The Apache Commons OSS project emerged on June 20, 2007 [0] as a way of standardizing the need for reusable Java components and libraries, slowly killing the market of paid components.
Or, components are bought as part of an ongoing subscription to a large catalog containing thousands of components [1][2]—think of it as a company-wide Safari Books subscription but for software components.
As part of the business model, component designers and developers were paid royalties in additional to the one-time monetary payment for developing each component, with the top 25 royalty earners collectively making as much $458,792.31 over a multi-year period [3].
0: https://commons.apache.org/charter.html
1: https://software.topcoder.com/catalog/c_showroom.jsp
2: https://www.topcoder.com/tc?module=Static&d1=pressroom&d2=pr...
3: https://www.topcoder.com/tc?module=ComponentRecordbook&c=roy...
Well, today we call it "function as a service" and Serverless...
Apart from enterprises selling K8s components who call it 'metering'.
I did not quite share his confidence in my abilities in that area, but to my relief, Jürg Gutknecht agreed to sponsor the talk, and I got to spend lunch with Brad Cox, Niklaus Wirth, and Jürg Gutknecht. Given their highly divergent aesthetics in language syntax, I expected some fireworks, but the conversation was quite pleasant, even when they were discussing Perl.
I was at the time the maintainer of the Mac port of Perl, and had taken some classes with Wirth, but the idea of discussing Perl with him struck me as akin to discussing masturbation with the Pope. However, Wirth conceded that in the area of text processing, general purpose languages tended to be somewhat clumsy, and there had always been a successful niche for languages like Snobol and now Perl.
Brad Cox was a splendid conversationalist in many other areas as well. His talk focused on Superdistribution as the next evolution of the Software IC concept, and he very skillfully pitched this to a Swiss audience that a banking nation should be a natural superpower to take the lead in a micropayment world. He was very good at painting visions like this, but I'm not sure how much of it ultimately came to pass:
a) I don't think we're any closer to plug and play "Software ICs" than we were in the mid-1980s when he introduced the term. In the Objective C ecosystem, the closest there was to that was maybe Interface Builder with its Outlets and Actions, but I think that part did NOT originate with Cox (I may be mistaken, though).
b) Likewise, I don't see any move to distributed micropayments. If anything, more and more of the software revenue seems to come from centrally billed cloud services, e.g. comparing the Microsoft Office revenue model 20 years ago and now.
There were hundreds of them you could download for free or paid, doing all kinds of GUI and non-GUI tasks.
Doesn’t seem so popular now.
https://www.actiprosoftware.com/
Just a sample, there are others.
Objective-C is still my favorite language and I loved his writing when first learning it in 94.
A lot of modern infrastructure works like that -- function as a service, serverless, k8s boxes, etc.
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.
The modern version of Objective-C, the one that's still in use today, was developed by NeXT and Sun and was called OpenStep. The first OpenStep specification was published in 1994.
OpenStep API implementations were created for NeXTSTEP OS, Solaris, and Windows NT, running on Motorola 68040, Intel, PA-RISC, and SPARC (and later PPC) platforms.
Sun would switch gears to Java, Apple would buy NeXT, and OpenStep would become Cocoa.
He was a Mensch.
To quote Joe Armstrong:
> I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions — all the data comes in its input arguments and everything goes out and leave no state behind — it’s incredibly reusable.
The analogy with OOP is that (ideally) you don't need to know how it works internally: you just use the external interface.
Consider a function f that itself relies on being able to call function g. In FP, you have to either bind by name, which introduces coupling on par with OO ("the jungle"), or you make it parametric, so f doesn't know anything about g per se, but somebody does―perhaps f's caller, or its caller, etc. OO is parametric, too, but in that case they live as slots on the objects, rather than being passed as arguments.
People can try to squidge this end of the problem and find that it shquoshes up on the other side, or vice versa. There's no real escape from the problem of dealing with state.
Probably the real silver bullet boost to productivity will come when we adapt program execution environments to our dumb brains by way of VR. Think of something like a cellular automaton such as von Neumann's universal constructor:
https://en.wikipedia.org/wiki/Von_Neumann_universal_construc...
... only in 3 dimensions. When we want to debug a program, we project it into a 3-dimensional space, and we trace its execution the way you can look at something progressing through the assembly line on a shop floor, with pieces that you can reach out and touch, and even pick them up and mark some with blue dots and some without, etc. That looks a lot more like OO than FP.
When using Swift, the compiler was painstakingly slow. Because of that, I tried Objective-C and it is so clear to me that I love it. It is the best language in my humble opinion. The dynamism clicked and the modern features make it a real breeze to use.
Messages are so flexible. I also love how it has “gradual typing.”
My only gripe with it is that Categories can’t formally conform to protocols—which I understand is an easy to build feature that Blaine Garst did finish but Apple never released.
I know I’m talking about the language more than I am talking about Brad Cox, but that’s because it’s the first time I really fell in love with a language. Using Objective-C to build it brings me joy. Lots and lots of joy.
Thank you Brad. My prayers to your family. May you find peace in heaven.
I wasn't aware of that limitation, so I tried it out just now only to be certain. Works fine for me. ¯\_(ツ)_/¯
@interface UIViewBuilderSmalltalkViewController(storage) <MPWStorage>
@end
@implementation UIViewBuilderSmalltalkViewController(storage)
@end
/Users/marcel/programming/Projects/ViewBuilder/UIViewBuilderMockup/UIViewBuilderSmalltalkViewController.m:121:17: Category 'copying' does not conform to protocol 'MPWStorage'
/Users/marcel/programming/Projects/ViewBuilder/UIViewBuilderMockup/UIViewBuilderSmalltalkViewController.m:121:17: Add stubs for missing protocol requirementsRIP.
I owe so much to Objective-C. My early love for the language is what launched my own career, and inspired a love for programming in general. Thank you, Brad Cox.
One day, with the help of another student, I managed to install Snow Leopard on my Acer notebook and the first thing I wanted to do was figure out how iPhone programming worked. However I was instantly confused at the syntax of the language and that threw me off.
I did try again two more times though, and in the last one it just clicked. That was mid-2012. I dropped out of university for a job opportunity in 2015 and have been an iPhone developer ever since.
Thank you, Brad Cox.
What a beautiful way to remember him.
Alan Kay once said that those who began to talk about objects in anthropomorphic terms got object oriented programming. Your “code” now reveals to me the cycle of life in all that I type. How delightful.
Thank you :)
>"The late Steve Jobs', NeXT, licensed the Objective-C language for it's new operating system, NEXTSTEP. NeXT eventually acquired Objective-C from Stepstone."
Does anyone what NeXT paid to acquire the Objective-C license?
Part of the acquisition was that NeXT would license Objective-C back to Stepstone for their own products, so it was more than an outright purchase anyway.
Do city cops there still obsess over teen boy genitals? https://www.techdirt.com/articles/20140709/07330027823/prose...
Did I get it to work? yep. Did it make senior programmers a bit nervous? yep. I wrote a blog post about it.
Later, I got to use Java for some Android apps, and after that we got Swift. XCode seemed to get slower with swift and Java(android) was more a limited language. No complaints, but it was just not as fun and easy as using Objective C. (in my naive beginner opinion)
Things were a lot simpler back then. I'll never forget my joy learning Objective C at my first ever programming job. RIP Brad Cox
And of course only now languages like Rust and Swift are feasible given the fact they do so much compile time checking. But that makes your IDE a lot slower compared to Objective-C.
I completely agree with your point about languages being just tools in your toolbox. With that point, I always feel that many of the folks who describe themselves as being 'passionate about language xxx' might be selling themselves short when it comes to having a toolbox that's not a one-trick pony.
Objective-C was the “object oriented C” that was simple and a delight to use…words that I certainly would not use to describe competing efforts. The syntax might be a little disagreeable–a concession to strict C compatibility–but the language itself is remarkably clean and, dare I say, pretty. Brad Cox struck the balance between flexibility and practicality better than almost anyone else before or since.
Here's the Objective-C paper at last year's HOPL:
"The origins of Objective-C at PPI/Stepstone and its evolution at NeXT"
I loved his little book on Objective-C.
Do you mean: "Object-Oriented Programming : An Evolutionary Approach"? Its 320 pages!
Given current events, my assumption is COVID-19. But I know that I'm assuming that too often. Old people do die of other things.
Objective-C is poetic. Its patterns and clarity are the closest I’ve come to an ecological software language: I feel like I’m gardening when writing Objective-C code.
was discussed in 2014 here: https://news.ycombinator.com/item?id=8422695
I never met Brad Cox, but the work he did to create it has had a huge impact on my life. Watching his long interview with the computer history museum was a delight and made me feel like I knew him just a little.
Sincere condolences to his family and friends.
So thank you Brad, you've influenced my entire career. RIP.
- (void) dealloc
{
// :(
}