1. 12
  1. 7

    Brad Cox was the creator of Objective-C and I found this, and some of his related writings, very insightful when I first read them 15-20 years ago. He was a strong advocate of both building reusable components and of the idea of building abstractions for different kinds of developers. His original vision for Objective-C was to allow people to package C libraries into Smalltalk-like components that programmers who understood the business problems but didn’t need to know about the implementation details of the libraries could use.

    I was reminded of this by the recent article on the use of Python in scientific computing. Python has been a great example of Brad Cox’s vision: a smallish number of people write C libraries and Python wrappers around them that are easy to use, a huge body of programmers use a language that makes it easy to compose those building blocks. Python hasn’t displaced Fortran there, Fortran and C++ are still used where Fortran was used, Python has replaced MATLAB or blackboards, which would then have been given by a non-programmer to a programmer to tell them how to assemble Fortran building blocks.

    1. 5

      Objects as composable components hasn’t really worked out in general because APIs are complicated and it’s hard to design and agree on common interfaces between components. Software is also prone to leaky abstractions, where internal state in the component unintentionally becomes part of its behavior in undocumented ways.

      I’m guessing the math/science domain works well because the components tend to be functional (little or no state) and the APIs use standardized mathematical concepts like vectors and matrices.

      I spent a couple of years in the 90s working on OpenDoc, an attempt to create very high level (end-user composable) components for GUI applications. The API became very complex, to the point where it was extremely difficult to implement a component that could contain other components.

      1. 2

        I’m guessing the math/science domain works well because the components tend to be functional (little or no state) and the APIs use standardized mathematical concepts like vectors and matrices.

        Absolutely! Although, even so, a composable, high-level approach still took a long time to catch on, and I have a feeling it’s still mostly confined to areas where interaction with external and/or commercial applications is more common, like statistical learning. There’s a cultural bridge that’s really hard to cross.

        The article @david_chisnall mentioned was pretty vindicating for me to read because back in 2010 or so I tried that exact same thing. I wrote some parallel number crunching code, loosely based on an older Matlab prototype (“loosely” as in it tried to get to the same results starting from the same inputs, but in a slightly different way, which resulted in a lot less number crunching that could also be done in parallel).

        The number crunching parts were all C, and getting that working was the first step. But I was a little reluctant to do all the not number crunching parts in C – parsing job descriptions, reading inputs, writing results, drawing graphs and so on. There was also a tiny but critical piece of interpolation logic that I was not looking forward to re-implementing in any language – it was very well-maintained, well-tested, fifteen year-old Matlab code, and being able to use the exact same interpolation method as the older Matlab prototype would’ve saved me a lot of headaches. So I wrote the whole thing in Python, which called C for the heavy number crunching, and Matlab for that one interpolation function).

        The folks at the lab were mostly okay with me doing this back at the time, largely because, to everyone’s surprise, it seemed to work. The real shock came when I told them this is actually how Matlab works, too: When you do x = A\B it’s actually calling a bunch of C code behind the scenes (I don’t know what it uses now but back then the sparse solver it used was UMFPACK, I think, which my program also used, because UMFPACK worked really well for us).

        Then they let me do an improved version based on the the same stack (more or less, I think by this time we had a bunch of PhD students who were using all available Matlab licenses and I was fed up with waking up at 2 AM so I could test my code, and ported all that crap to Octave). But they were already kindda jittery about it, and I don’t think “that’s how Matlab does it” really registered on their radar. They once again let me do the Python-calling-C-code scheme because we were on a tight deadline but they did ask me if it were possible, once we were done and the paper was submitted, to rewrite this in a “proper” language like C++. I think someone actually tried it after I left, but they hated it and it really didn’t take off.

        1. 2

          I am curious. Would you consider the COM architecture a reasonable approach? (This was your competition right?) Or do you see problems in that approach to reusable components similar to that found in opendoc? I would be happy for any info as I am interested in this area.

          1. 1

            Sorry for the delay replying … this is kind of apples-vs-oranges. COM is more of an ABI, as I understand it, a convention for how to structure vtables. The counterpart on the OpenDoc side was SOM, a technology from IBM for cross-language object binding.

            ActiveX would be the layer more like OpenDoc, although they still don’t match because ActiveX components were developer-oriented while OpenDoc was user-oriented.

            1. 1

              Thank you! much appreciated. So, from what you say, should I understand that you were trying to design objects that were directly usable by the end users?

              With ActiveX one could fairly easily build a component, and make it available for developers who were using say VB or VC, and from my time developing for Windows, I remember that this was fairly easy, albeit with security problems. What other problems did ActiveX have? (In the context of “Objects as composable components hasn’t really worked out in general”)?

              1. 1

                Yes, OpenDoc components were user-embeddable and bound to document content. Sort of like when you embed a table or chart or picture in a word processor, or a rich text field in a drawing program … only the components don’t belong to the same app or even the same developer.

                It failed for a bunch of reasons, including

                • its own architectural flaws and the complexity of its APIs;
                • this was the mid-90s and suddenly everyone’s attention went from desktop productivity apps to the World-Wide Web;
                • Apple, its primary contributor, was having a near-death experience and had to kill off a bunch of non-essential R&D.
                1. 1

                  Thanks! If I understand correctly, this is sort of like the OLE in the Windows environment? where you can embed an Exel file in a Word document? Microsoft seems to be using it still. Does it mean the problem was with the circumstances at OpenDoc rather than objects as composable components? Or are there issues that make objects completely unusable for this purpose?

                  (I am really interested in how one can design components, especially GUI that are easily reusable by developers and end users from an academic perspective, how distribution as objects compare to distribution as libraries, and would really appreciate your insight).

                  1. 1

                    I think there’s still information about OpenDoc available online. It was definitely more advanced than OLE.

                    1. 1

                      Thanks! much appreciated.