Live data from Hacker News

Brad Cox has died

legacy.com

161–170 of 197 posts

Re: Brad Cox has died

#161
post #120

Earlier quoted context omitted.

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…

I bet it was actually C++ with extern "C", which was my point, specially given the MPW and PowerPlant frameworks.

I never knew anyone doing bare bones C on classic Mac.

Re: Brad Cox has died

#162
post #31

I am giving a talk in work soon around method swizzling in iOS and was delving into the history of Objective-C a bit and came across Alan Kay's talk about the power of simplicity and how we've all screwed up OOP. 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,…

>Brad definitely walked on the blue plane. RIP.

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."
https://www.writing.upenn.edu/~afilreis/88v/blueguitar.html

Re: Brad Cox has died

#163
post #31

I am giving a talk in work soon around method swizzling in iOS and was delving into the history of Objective-C a bit and came across Alan Kay's talk about the power of simplicity and how we've all screwed up OOP. 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,…

"I think Alan's idea of OOP was something more fluid, more organic than this." 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?"

>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.

Smalltalk 76-like...

Re: Brad Cox has died

#164

Very sad. I had the privilege of taking a class from him at George Mason University, and he was (unsurprisingly) very knowledgeable. 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…

>No one was interested in his idea of trying to monitor component use during runtime to pay developers.

Well, today we call it "function as a service" and Serverless...

https://en.wikipedia.org/wiki/Function_as_a_service

Re: Brad Cox has died

#165

I met him once in the late 1990s, when his travels took him to Zurich and he asked me whether I could book a talk for him at ETH Zurich, where I was a grad student. 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…

>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.

A lot of modern infrastructure works like that -- function as a service, serverless, k8s boxes, etc.

Re: Brad Cox has died

#166

I met him once in the late 1990s, when his travels took him to Zurich and he asked me whether I could book a talk for him at ETH Zurich, where I was a grad student. 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…

I think the vision of Software ICs was delivered most fully by VBX custom controls for Visual Basic and Delphi. Superseded by OCX. 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.

Depends on which circles you move around.

https://www.actiprosoftware.com/

https://www.grapecity.com/

https://www.telerik.com/

Just a sample, there are others.

Re: Brad Cox has died

#167

Earlier quoted context omitted.

It's not a modern language, so appreciating it has to be in its original context. I think it does an admirable job of augmenting C with object-oriented capabilities. It's certainly easier to master than C++. 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 NeX…

Mostly the latter, I would assume. Apple didn't really use anything other than Objective-C for its application frameworks (and still generally does not, for the most part).

I read in multiple sources, usually the kind of comments that is only possible to validate with inside info, that to this day not all business units are sold on Swift.

Re: Brad Cox has died

#169

Earlier quoted context omitted.

> 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. 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 t…

> It implements message-based programming, which is "real" OOP 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 implement…

Absolutely incorrect: http://wiki.c2.com/?AlanKayOnMessaging

Re: Brad Cox has died

#170

Earlier quoted context omitted.

It's not about "array" or string". [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(appDidBecomeActive:) name:NSApplicationDidBecomeActiveNotification object:[NSApplication sharedApplication]]; can you explain to me what any of those terms mean without looking a fairly extensive reference manual?

Yep. AppKit has this concept called a Notification Center, which, duh, sends notifications. You want to observe the notification called NSApplicationDidBecomeActiveNotification . The way you want to observe this notification is by being sent the message * appDidBecomeActive: . The "object:" parameter tends to be nil, so I did actually have to look that up: it means I only want to receive this particular notification…

In addition, the semantic consistency of the frameworks combined with the verbosity encouraged by the language makes it easy to jump into a new-to-you part of a 25+ year old codebase and start making useful changes very quickly.

This is much more difficult when you have to be careful about what every single operator dispatches to, or when more than just the receiver’s type determines the method that’s called. You can look at code in isolation and get a pretty good idea of its intent and the routes that its implementation will take, both of which are necessary to start making changes.

Post reply on HN