Apple yesterday announced that its spirited senior vice president of Mac software engineering Bertrand Serlet, who some are calling the father of OS X, will be leaving the company to focus less on products and more on science.
Below are some enlightening and, at times, opposing viewpoints on Bertrand Serlet from two former Apple engineers as posted on a Hacker News thread:
Bertrand is extremely valuable says user jballanc:
Well…I can’t say I didn’t see it coming (recent ex-Apple engineer here), and I’m happy for Bertrand, but Apple is loosing an extremely valuable asset.
Bertrand is a truly amazing and, I feel, wholly under-appreciated engineer and manager. He knew the technology better than pretty much anyone at Apple, and he stayed involved in all of the nitty-gritty details including participating in some of the internal engineer mailing list discussions.
One story I can relate that I think illustrates the point: Inside Apple there is a system to search the source code for every product they ship. The idea is that when you need to track down the definition of that primitive method that keeps crashing on you, you just go to this site, type in the function name, and get the source laid out in front of you (nicely syntax highlighted, of course). Well, one day I got the idea to use this tool to search for people, instead of functions. For a while now the policy at Apple has been that engineer’s names don’t go in the public headers that ship…but there’s no rule about internal code that the outside world will never see. So I typed in “Bertrand Serlet” into the search, and the first thing that popped up?
Seriously! The rest of the list was equally impressive including the original implementation of NSObject, a bunch of CoreFoundation, and on, and on. Avi Tevanian often gets credit for the work that he did on Mach, but Bertrand was most of the brains behind Cocoa.
Anyway, I could go on, but I’ll just say that if I could have one wish as a programmer it would be to get to work with Bertrand Serlet again
And a counter point from nupark:
Speaking as a former Apple engineer in Core OS, this is a bit too glowing. Serlet wrote quite a bit of code in the NeXT days, much of which does not meet what you would call modern best practices, and even when written was fairly unusual.
However, Serlet, despite no longer writing code, was incredibly stubborn about any changes to his pet implementations, even 10-20 years later. This included large changes, such as updating malloc to a more modern implementation (see Jason Evan’s later work on jemalloc), and small changes, such as updating top(1) to better match its Linux and BSD counterparts and implement a standardized library (libtop) for accessing process/host statistics (he wrote top, too).
Serlet was like many technical individuals that graduated into fulltime management; stuck with the last technology they’d worked on, as it was when they last worked on it. Avie was the same with his fixation on Mach, and Mac OS X was honestly poorer for it.
And jballanc responds:
Heh, ok…I’ll take that. I find your perspective a bit entertaining coming from Core OS (I was on Server, as it so happens). At least, when I was there Core OS had a reputation as being the more “academic” and “by the book” group. That’s compared to Frameworks, which was much more pragmatic than dogmatic. One of the things I admired was how Bertrand managed those conflicting viewpoints with some grace. Of course, things being what they were, I’d expect someone from Core OS to blame Bertrand for being too “old fashioned”. At the same time I know plenty of people from Frameworks who were upset that he “adopted new technology too soon”…there was especially a lot of that with respect to libdispatch.
As for malloc, I find it hard to believe that he was stubborn about changes. The one chance I had to sit and have coffee with Bertrand, we discussed what API’s we’d most like to rewrite given infinite time/resources. His answer was “malloc”. I think rather than being stuck with the last technology, he had a difficult time balancing the pressures of change with the need for consistence, and did so admirably.