Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming

Brad Cox, Creator of Objective-C Programming Language, Dies At 76 (legacy.com) 48

Posted by BeauHD from the rest-in-peace dept.
We have learned that Brad Cox, computer scientist known mostly for creating the Objective-C programming language with his business partner Tom Love, died on January 2, 2021 at his residence. He was 76. From a Legacy.com post: Brad was born on May 2, 1944 in Fort Benning, Georgia, to the late Nancy Hinson Cox and Dewey McBride Cox of Lake City, South Carolina. Brad grew up on the family's dairy farm in South Carolina but found himself most interested in science. After graduating from Lake City High School, he received his Bachelor of Science Degree in Organic Chemistry and Mathematics from Furman University, and his Ph.D. from the Department of Mathematical Biology at the University of Chicago, and worked on an early form of neural networks. He soon found himself more interested in computers and got a job at International Telephone and Telegraph (ITT) and later joined Schlumbeger -- Doll Research Labs, and ultimately formed his own Connecticut startup, Productivity Products International (PPI) later named Stepstone.

Among his first known software projects, he wrote a PDP-8 program for simulating clusters of neurons. He worked at the National Institutes of Health and Woods Hole Oceanographic Institute before moving into the software profession. Dr. Cox was an entrepreneur, having founded the Stepstone Company together with Tom Love for releasing the first Objective-C implementation. Stepstone hoped to sell "ICPaks" and Dr. Cox focused on building his ICPak libraries and hired a team to continue work on Objective-C, including Steve Naroff. The late Steve Jobs', NeXT, licensed the Objective-C language for it's new operating system, NEXTSTEP. NeXT eventually acquired Objective- C from Stepstone. Objective-C continued to be the primary programming language for writing software for Apple's OS X and iOS.
This discussion has been archived. No new comments can be posted.

Brad Cox, Creator of Objective-C Programming Language, Dies At 76 More

Brad Cox, Creator of Objective-C Programming Language, Dies At 76

Comments Filter:

  • Comment removed (Score:5, Interesting)

    by account_deleted ( 4530225 ) on Saturday January 23, 2021 @02:23AM (#60981420)
    Comment removed based on user account deletion

    • Yep. And I bet you the passing of the authors of Visual Basic or Javascript will elicit no more than a passing footnote on specialized websites - if they're lucky.

      • When the author of GW-BASIC checks out it should elicit at least a "Gee Whiz!"

      • The author of JavaScript is currently hated for having once, at some point of his life, donated a few grands to an anti gay marriage organization.

        I really think that him creating JavaScript brought much more sadness to the world in comparison with these few grands.

    • I had to work literally next to him, and with due respect to what you wrote about his contributions, the man himself was a pig, and he *reeked*. The office in general was smoke-free, but he got to smoke in his because a window fan (handwave handwave). His monitor and keyboard were *brown* from tobacco and the entire room reeked. The discussion of encapsulation is interesting, given that ObjC itself violated it :-x

  • My condolences, Objective-C is one of the languages I've enjoyed using a lot over the years. It's kind of verbose but I really like the ideas from other languages they mixed in there...

    I didn't mind moving on from on, as more modern languages are improved. But especially for the time Objective-C was created, it was a fantastic language compared to many others.

    • Yep. ObjC has a reputation as a weird language, but its not tat weird vat all.It just has a slightly unusual syntax for method calls. Its C++ with out all the ritual and complication. A purer and simpler object model that solves most of the problems C++ tries to address by just not having them be a problem. That might sound hand wavey, but its not. Its just simpler and doesnt try and biuild giant nests of complexity around edge cases. In some senses its almost closter to python or ruby, in some respects.

      . I

    • > But especially for the time Objective-C was created, it was a fantastic language compared to many others.

      Well put.

      I would add that it was rather "clean" as well. That was not the case at the end of its days, when they had added all sorts of cruft on a sliding scale of usability. So I think its history will be somewhat tainted by that fact, and the fact that the majority of people that ever saw Obj-C were during that period.

    • Re:Editors: What is an "ICPak" ? (Score:4, Informative)

      by Koen Lefever ( 2543028 ) on Saturday January 23, 2021 @04:41AM (#60981534)
      It is an interface library, similar to Motif:

      ICpak 101---Foundation Class Library
      ICpak 201---Graphical User Interface
      ICpak 301---GRAPHpak

      The name ICpak refers to software components which can be included in a program just as an IC can be put on a printed circuit board.

      IEEE Computer Graphics & Applications, Oktober 1987, page 74, Reader Service Number 32 [ieee.org]:
      Productivity Products International's ICpak 201 is a graphical user interface development package. The set of 49 pretested software components is designed to enable software developers to build multiwindow iconic user interfaces for workstation applications in both color and black and white.
      The package provides building blocks for rapid construction of graphical user interfaces. It includes "Software-ICs," which provide functionality for constructing windows, menus, scroll bars, stretch boxes, close boxes, confirmers, and prompters. Iconic user interfaces can be built by reusing existing components as they are, or by tailoring them for specific needs. The package is designed to be independent of underlying graphics primitives and windowing systems. Through a "virtual terminal" C function library called Earthbase, it is isolated from machine dependencies to maintain its portability. User interfaces are built by placing graphic layers one on top of another. Each layer adds an element or elements to the user interface. Layer objects determine the visual aspect of the interface and how it interacts with the end user. Layers display images and handle events attached to them.
      The package is available on DEC VAX, under Ultrix and BSD 4.2 and 4.3, color and monochrome, running X-Windows; Hewlett-Packard 9000 Series 200 and 300, under HP-UX, color, running Starbase or X-Windows; and Sun Microsystems, under SunOS Version 3, color and monochrome, running SunWindows.
      A development license for up to 10 users within a corporation costs $35,000.

      • > The name ICpak refers to software components which can be included in a program just as an IC can be put on a printed circuit board.

        This was the whole idea for Obj-C. It's late binding and extensibility were selected specifically to allow plug-n-play components.

      • There were later an SGI dev system at the company, and an IBM RT running AIX; whether products actually shipped on those platforms I'm not sure. The VAX in house ran VMS, anything on Ultrix or BSD must have been at a customer site.

  • > for it's new operating system

    Tsk, tsk.

  • Dynamic dispatch by default is a punch in the eye for performance. The syntax to expose this "message" based method call/binding is just horrible and hard to digest. liked the idea of "categories", that can be used to create arbitrary levels of accessibility of the interface, and also to add extension methods: C++ would have needed something like this. Also with Objective C 2.0 some good ideas (properties, enumeration, ...) were copied straightly from C#. I don't know exactly the feature set when the langu

    • Uum, C# only copied them from many many others before it.
      It's a Microsoft language after all, and that's kinda their whole game.

      • Re: (Score:2, Interesting)

        by ceztko ( 907766 )
        Of course all modern language copy features from previous languages. For example "Properties", intended as language first citizen getter/setter(s): actually it was already there in VisualBasic, which to my knowledge is the first language with a clear syntax describing them. My point in correlating Objective C 2.0 to C# is that, in my opinion, they picked several key features that represents the "vision" of how frequent productivity tasks are supposed to be handled in C#.

    • Call me when regulat C gets garbage collection... ;)

      See? The purpose of C it not one where GC fits. So there are oter choices, and it was't necessarily late, but maybe more of a change in preferences and situations it was used for.

    • Re: (Score:2)

      by Megane ( 129182 )
      The syntax is certainly odd, unless you've seen Smalltalk code. Then it merely clashes like lime green and safety orange. And if you're concerned about performance, automatic GC isn't how you get there.

      • Re: (Score:1)

        by ceztko ( 907766 )
        My comment about GC is that it arrived very late, not that it would help with performance. Still, I don't like a method binding mechanism that has heavy overhead in default usage. With this regard they seem to have improved the situation a lot in Swift.

        • Re: (Score:1)

          by Anonymous Coward

          You still don't get it. Some languages are made for performance. Objective-C is a proper OO superset of C, designed with speed in mind. Garbage collection definitely was not a consideration for what it is was designed to do.
          Each language is designed to solve a different set of problems, so not all languages need GC.
          It was temporarily added to Objective-C 2.0 by Apple. It was quickly deprecated in favor of ARC, which is also used in Swift, so I am not sure how Swift improved the situation, it is exactly the

    • You complain how late garbage collection was introduced. Guess what, itâ(TM)s long gone.

    • Re: (Score:1)

      by sounds ( 466749 )

      Apple put the myth of poor performance to rest during a WWDC 1997 session.

      Due to caching and the differences between PowerPC and Intel, it actually took fewer processor cycles to make a method call in Objective C on PowerPC compared to a C++ function call on Intel. That's because, at the time in the late nineties, calling a library function on an Intel processor required several segment override opcode prefixes, and this resulted in many cycles.

      Actual benchmarks and cycle counts show that Objective C does n

      • Re: (Score:1)

        by ceztko ( 907766 )
        I think comparing two different languages on two different architectures is an unfair comparison. My point is that "always on" dynamic dispatch/binding must have some penalty cost, compared to a language that does by default static binding. Anyway, it's not that I care too much about performance in a language like ObjectitveC: dynamic dispatch has also other disadvantages like signaling at run time programming errors that could be actually spotted at compile time. Good point that first-citizen "interfaces"

        • Re: (Score:1)

          by sounds ( 466749 )

          I can't argue with "must have some penalty cost," other than to point out that benchmarks show this particular overhead to be insignificant.

          Keep in mind that, back in the day, people argued against Display Postscript because it uses floating point calculations rather than fixed point integers. Again, here is where benchmarks show that processors without native floating point arithmetic units pay a severe performance penalty for floating point calculations. However, modern processors can perform floating poi

  • RIP. Kudos for Obj-C (Score:4, Interesting)

    by Ecuador ( 740021 ) on Saturday January 23, 2021 @07:27AM (#60981750) Homepage

    I have enjoyed using Objective-C. If you get over the annoyance of the wordy syntax, it is a pretty great objective superset of C, which includes mostly the right features.

    I found that one way to get over that annoyance of the wordy syntax is to try to work on some C++ codebases (preferably ones that try to use the various 'exciting' features of the bloated language) and see how sane Objective-C looks when you go back.

    Plus the verboseness it is notorious for, is not all due to the language itself. I mean Apple going from Objective-C to Swift dropped all the extra long prefixes from the names of all properties, enums etc in their frameworks, (causing some confusion in the transition), so everything looks much more succinct, and yet they did not technically NEED to be that long for Objective-C in the first place!

    Anyway, thanks Brad.

  • Objective-C (Score:3, Interesting)

    by Dan East ( 318230 ) on Saturday January 23, 2021 @08:32AM (#60981854) Journal

    I mean absolutely no disrespect for Mr. Cox, but Objective-C was one of the few languages I've used that I really, really disliked. And that encompasses everything from Lua to LISP, assembly (from microcontrollers to 6510 to ARM), and of course all the contemporary stuff (Java, Kotlin, Swift, PHP, C++, Javascript, etc). I just never could wrap my head around it and felt I was re-learning the syntax every time I revisited it. Almost made me feel incompetent as a developer lol.

    There have always been specific aspects of languages I've disliked (I'm not a fan of whitespace being a construct in the logic, as in Python) but I can adapt to those things and move on. Objective-C is at another level for me though.

    I think the foremost issue is the language syntax seemed designed for the sake of the compiler, not the developer. The fact that Apple invented an entirely new language to replace Objective-C indicates the language itself was a barrier to a significant number of developers.

    • Re: (Score:2)

      by Tablizer ( 95088 )

      I just never could wrap my head around it...Almost made me feel incompetent as a developer

      Every developer is different and are tripped up by different things. It's rare somebody masters everything quickly. And if they do, they usually have lousy team/people skills. Minds are a tradeoff. The best teams leverage each others' strong points in synergistic way (yes, I used that term) and aren't afraid to ask for help or feedback from each other.

  • Stepstone encapsulates his contribution (Score:3)

    by dsgrntlxmply ( 610492 ) on Saturday January 23, 2021 @11:59AM (#60982476)

    Consider that Cox's book describing Objective-C was published in 1986, whereas gcc was first released in 1987. C compiler choices were AT&T licensed or commercial (e.g. MetaWare). Cox's commercial implementation wrapped a preprocessor and runtime library around whatever C compiler. OOP alternatives Smalltalk and Flavors/Common Loops/CLOS were all encumbered or in gestation, and required committing to weird languages with weird runtimes and arcane expensive hardware.

    Consider that this provided a stepstone to NeXT for their more important work in constructing a UI framework that while proprietary, was at least fairly readily accessible, and ran with remarkably good performance on a 25 MHz 68030. This then brought integration with gcc and an available GPL'd runtime, and eventually Apple to provide something for people to snipe at decades after the actual fundamental contributions.

    • Comment removed based on user account deletion

      • I graduated in 1991 and in my degree, the language stuff focused on the different types - functional, imperative, OO, state oriented, logic, declarative, lambda calculus with proof checking, dataflow (eg sisal) etc. The sentiment among the profs was that any of the above could become the dominant future model, but we saw OO win out over the next two decades while on the sidelines, there were many who never stopped pointing out what was lost with OO-only and could be regained if we used languages better mapp

Slashdot Top Deals

If it wasn't for Newton, we wouldn't have to eat bruised apples.

Close