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?
malloc.c
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.
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.
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.
Oh, and as for top…when they did change it in early SnowLeopard builds, it broke a whole host of tooling, etc., and they had to revert some changes...
Given where Core OS sits in the software stack (kernel, libc, file systems, etc), being "academic" and "by the book" shouldn't be surprising. :)
As to the rest; my point was that Bertrand was very opposed to change in 'his' code, not that he wasn't open to any change. Regarding malloc, I think Bertrand still thought he'd be best suited to do it, and he has always objected strenuously to others approaching his problems.
Oh, and as for top…when they did change it in early SnowLeopard builds, it broke a whole host of tooling, etc., and they had to revert some changes...
That's pretty normal when tools depend on text output of commands (something Core OS has told everyone not to do, and then they do anyway). The initial conversion to modern top/libtop actually occurred back in the 10.{1,2,3} release cycles, and was subject to a very heavy amount of push-back and compromise with Bertrand about "his" top(1) :)
Oh, I never had a problem with Core OS's academic bent...enjoyed it actually. I was more commenting about the unique sort of tension that existed there, and that managing that tension while also developing kick-ass software is a relatively impressive feat. Also, you're right about the "I can do it better than anyone" attitude regarding fixing things that he wrote...but then my experience was that this was a pervasive attitude at Apple. The only way you could get someone to listen to you was to not only do it better but prove that you had done it better. So, maybe that's not the best attitude for a manager to take, but hardly out of the ordinary (for Apple).
I also feel that as time moved on, Bertrand was making more bad decisions, but that this might have been a consequence of pressure from the top. It may not look like it to the outside observer, but there is a major metamorphosis going on at Apple internally. I think this move will be for the best for Bertrand. As for Apple... * shrug *
...oh, and thanks for bringing back memories of the Core OS "you're doing it wrong, stupid" lessons I got so familiar with. If only we could all be so perfect as Core OS! ;-)
Interesting - in that case I cheer his departure. One of the most important abilities of a great engineer is to be able to throw away his own code (so it can be replaced by something better).
I'm sure there are many brains behind Cocoa, but Ali Ozer has to be the most unsung hero at Apple. Seems like it's been his core vision for all these years that has kept things coherent.
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?
malloc.c
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.