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.
I will say this about Bertrand -- the guy works all the time. It's become a running joke with my wife... Every single time we go out to dinner & coffee in downtown Palo Alto, we wonder which coffee shop we'll see him in, working away on his laptop.
#2 may have been shot down by Apple this week. I'd assume if he were going to leave Apple, they'd keep mum. Or maybe he was going to bail but they offered him more money. Or offered to let him work from the UK.
Also: TUAW rivals the National Inquirer on reliability of their news. You shouldn't cite them if you want your points taken seriously.
Regarding #2 — when I first saw that rumor my thought was: where would he go? My take is that Ive is in some kind of lock-in — nowhere else would he get the culture, resources, help, anything he needs to be what he is.
The Ive thing is / was apparently about wanting to move back the UK and have his children educated here rather than work.
I'm guessing that he's set for life financially and that he'd basically have his pick of jobs or freelance work so while it might not be Apple, he's going to do fine.
But a recent newspaper article (it was the Daily Mail so I use the term newspaper loosely) said he wasn't looking to move back here and there was no truth to the rumour. No idea what their source but probably about as reliable / unreliable as the source of the original rumour which was pretty speculative to say the least.
Yeah. My [utterly speculative, outsider] feeling is that Ive wants to leave Apple to pursue other things about as much as Jobs does. The only thing I'd imagine could outweigh that would be family considerations.
Nice one! Ever since the port of Mac OS X to the iPhone - the iOS - I am in awe of Apple engineering. They are Gods.
I mean - imagine Vista, or Win 7 going on the phone, just with a new touch UI framework added. It simply wouldn't work, couldn't work, would be impossible, beyond the reach of the richest software company in the world.
Sometimes, good engineering does pay off, and ultimately one could say that iOS is a direct result of good engineering. Every time the iOS wins it's a win for good design, and for object oriented programming.
That said, the dark side of being so far ahead of everyone for so long is a severe case of NIH syndrome at Apple. Those times when others surprisingly better Apple, Apple takes a very long time to catch up.
Dev tools are the best example with XCode 10 years behind Eclipse.
MobileMe Mail is perhaps another one: MobileMe Mail is similar to Mail.app on OS X - but Gmail is way better than that, and has been pretty much from the beginning.
I'm not sure why you're getting upvoted. The NT base OS already runs on embedded platforms with equal or lesser power than that of any of the iOS platforms.
Are you trying to imply that the base OS is bloated? Or, are you trying to imply that the UI frameworks are bloated?
Apple didn't just port Mac OS X to the iOS platform, they more accurately ported the underlying Darwin OS to it, and added UIKit and other specialized frameworks.
I don't know much about Windows Embedded Standard (what Microsoft officially calls its modular embeddable cut-down version of W7, also known as "MinWin") vs. Windows CE, but Microsoft for whatever reason still chose to base Windows Phone 7 on CE instead of Standard, indicating that they still don't think Standard is appropriate for mobile devices. Probably they will port it to Standard eventually, but they haven't yet.
MinWin is not a "cut-down version of W7" - it was never productized, only a concept demo. Regardless though, Vista had started and W7 continued better separation of layers in NT. Maybe Vista was a percieved disaster, it was a necessary step nontheless.
An interesting excerpt (iirc, Eric demoed this in a Channel 9 video):
In October 2007, Eric Traut, a developer at Microsoft, demonstrated a self-contained MinWin system, made up of about 100 files, on which a basic HTTP server was running.[10][11] Traut noted that MinWin takes up about 25 MB on disk and has a working set (memory usage) of 40 MB. It lacked a graphical user interface and is interfaced using a full-screen command line interface. Traut explained during the demo that MinWin would not be offered as a stand-alone product, but would instead be used as the basis for future operating system releases such as Windows 7.
Wasn't it productized as Windows Embedded Standard? (in its minimal configuration)?
I must admit I've never seen this stated anywhere official, I just assumed it based on the fact that the minimum footprint for WES is 40MB, which was the same figure quoted for MinWin.
The thing is those "other specialized frameworks" are mostly the exact same ones you get on the Mac. So the accurate description would be: "Apple ported the major parts of Mac OS X to ARM and exchanged UIKit for AppKit".
Wil Shipley (longtime NeXT and Mac OS X programmer) posted a few thoughts on Serlet and his replacement Federighi. Well worth a read, he clearly has enormous respect for both of them.
Well it’s a sad day for all of us here in Cupertino. Bertrand Serlet, the friendly cyborg from the future who has lived among us and helped guide our software development efforts with such skill, has been recalled back to his home planet. We’ll have a little announcement at town hall this Friday with a cake and ice cream. Bertrand has been instrumental in guiding our OS X development and now that Leopard is out the door Bertrand (real name: Belar) felt this was a good time to heed the call of his people on Gallifrey One, who need him to help fight off some invaders in the future or something.
[...]
Much love, Bertrand. O traveler of time, you have brought a vision of peace to our galaxy, not to mention a great deal of truly sweet software. For your countless contributions to our company and to our planet, we thank you.
That's a great part of the business; ideas and people travels! Look at Matias Duarte -the designer of WebOS- he moved to the Android team and made (made is technically speaking) the Honeycomb we now know. Designers and coders moves and makes the industry moving in a great way because it creates diversity and changes!
"The Xcode 4 interface should not imitate iTunes."
The new design has its problems, but this kind of feedback isn't specific enough.
The team did try to clean up the mess, and were successful in some areas. A modern, single-window design is laudable. But the document handling is just abysmal, as it has always been in Xcode.
The tabs don't make sense (they're even upside-down); the "counterpart" button is gone; you can't split the editor without invoking this misguided "assistant"; error messages appear in this narrow column on the left, so of course they're truncated to the point of uselessness and if you go to the results and put them in the main editing pane, it doesn't pull up the relevant source code at the same time.
Aside from the document-handling fiasco, there are lots of plain old bugs in Xcode 4. Worst of all is that it simply won't build a lot of projects that worked fine in Xcode 3, stopping people's work in its tracks.
I just checked Eclipse: Green circle with a white, right-pointing triangle. Then I checked Netbeans: Green right-pointing triangle. Both of these are unmistakable icons for 'play'. Edit: I even googled for screenshots of Visual Studio...green right-facing triangle.
really, cause that's exactly what button I look for when I'm in an IDE trying to figure out how to run a project. I'm sitting here looking at intellij which has a 'play' button for running code.
Guys, try reading his post:
"When I want to build my project I do not want to press a play button."
He said BUILD, not RUN. A Play button is to build and RUN the project. I agree with his objection: There's no Build button in the UI.
And even worse is the width of the combined drop-down list for configurations. There's a vast expanse of empty space in the (now non-customizable) toolbar, and they made this control SMALLER. The information it should be providing is cut off in all cases, even with short project names. I try to be sympathetic to the Xcode team's tasks, but this is idiotic.
Not to take anything away from Bertrand and go back to the normal tea leaf reading we so enjoy to do with Apple, but … here goes :]
Did anyone else notice how the press release was so heavily focused on Steve Jobs? It could almost be read as: Jobs is at the helm, and don't worry, he'll be okay.
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.