Dennis Ritchie, a co-creator of Unix and C, passed away a few weeks ago, and was honored with many online tributes this weekend for a Dennis Ritchie Day advocated by Tim O’Reilly.
It should hardly be necessary to state the importance of Ritchie’s work. C is the #2 language in use today according to the TIOBE rankings (which, while criticized in some quarters, are at least the best system we currently have for gauging such things). In fact, TIOBE’s preface to the October 2011 rankings predicted that a slow but consistent decline in Java will likely make C the #1 language when this month’s rankings come out.
Keep in mind that C was developed between 1969 and 1973, making it nearly 40 years old. I make this point often, but I can’t help saying it again, when Paul Graham considered the possible traits of The Hundred-Year Language, the one we might be using 100 years from now, he overlooked the fact that C had already made an exceptionally good start on a century-long reign.
And yet, despite being so widely used and so important, C is widely disparaged. It is easy, and popular, and eminently tolerated, to bitch and complain about C’s primitiveness.
I’ve already had my say about this, in the PragPub article Punk Rock Languages, in which I praised C’s lack of artifice and abstraction, its directness, and its ruthlessness. I shouldn’t repeat the major points of that article — buried as they are under a somewhat affected style — so instead, let me get personal.
As an 80′s kid, my first languages were various flavors of BASIC for whatever computers the school had: first Commodore PETs, later Apple IIs. Then came Pascal for the AP CS class, as well as a variety of languages that were part of the ACSL contests (including LISP, which reminds me I should offer due respect to the recent passing of its renowned creator, John McCarthy). I had a TI-99 computer at home (hey, it’s what was on sale at K-Mart) and its BASIC was godawful slow, so I ended up learning assembly for that platform, just so I could write programs that I could stand to run.
C was the language of second-year Computer Science at Stanford, and I would come back to it throughout college for various classes (along with LISP and a ruinous misadventure in Prolog), and some Summer jobs. The funny thing is that at the time, C was considered a high-level language. At that time, abstracting away the CPU was sufficient to count as “high-level”; granted, at the time we also drew a distinction between “assembly language” and “machine language”, presumably because there was still someone somewhere without an assembler and was thus forced to provide the actual opcodes. Today, C is considered a low-level language. In my CodeMash 2010 talk on C, I postulated that a high-level language is now expected to abstract away not only the CPU, but memory as well. In Beyond Java, Bruce Tate predicted we’d never see another mainstream language that doesn’t run in a VM and offer the usual benefits of that environment, like memory protection and garbage collection, and I suspect he’s right.
But does malloc() make C “primitive”? I sure didn’t think so in 1986. In fact, it did a lot more than the languages at the time. Dynamic memory allocation was not actually common at that time — all the flavors of BASIC of that time have stack variables only, no heap. To have, say, a variable number of enemies in your BASIC game, you probably needed to do something like creating arrays to some maximum size, and use some or all of those arrays. And of course relative to assembly language, where you’re directly exposed to the CPU and RAM, C’s abstractions are profound. If you haven’t had that experience, you don’t appreciate that a = b + c involves loading b and c into CPU registers, invoking an “add” opcode, and then copying the result from a register out to memory. One line of C, many lines of assembly.
There is a great blog from a few years ago assessing the Speed, Size, and Dependability of Programming Languages. It represents the relationship between code size and performance as a 2-D plot, where an ideal language has high performance with little code, and an obsolete language demands lots of work and is still slow. These two factors are a classic trade-off, and the other two quadrants are named after the traditional categorization: slow but expressive languages are “script”, fast but wordy are “system”. Go look up gcc – it’s clearly the fastest, but its wordiness is really not that bad.
Perhaps the reason C has stuck around so long is that its bang for the buck really is historically remarkable, and unlikely to be duplicated. For all the advantages over assembly, it maintains furious performance, and the abstractions then built atop C (with the arguable exception of Java, whose primary sin is being a memory pig) sacrifice performance for expressiveness. We’ve always known this of course, but it takes a certain level of intellecutual honesty to really acknowledge how many extra CPU cycles we burn by writing code in something like Ruby or Scala. If I’m going to run that slow, I think I’d at least want to get out of curly-brace / function-call hell and adopt a different style of thinking, like LISP.
I was away from C for many years… after college, I went on a different path and wrote for a living, not coming back to programming until the late 90′s. At that point, I learned Java, building on my knowledge of C and other programming languages. But it wasn’t until the mid-2000′s that I revisted C, when I tired of the dead-end that was Java media and tried writing some JNI calls to QuickTime and QTKit (the lloyd and keaton projects). I never got very far with these, as my C was dreadfully rusty, and furthermore I didn’t understand the conventions of Apple’s C-based frameworks, such as QuickTime and Core Foundation.
It’s only in immersing myself in iOS and Mac since 2008 that I’ve really gotten good with calling C in anger again, because on these platforms, C is a first-class language. At the lower levels — including any framework with “Core” in its name — C is the only language.
And at the Core level, I’m sometimes glad to only have C. For doing something like signal processing in a Core Audio callback, handing me a void* is just fine. In the higher level media frameworks, we have to pass around samples and frame buffers and such as full-blown objects, and sometimes it feels heavier than it needs to. If you’re a Java/Swing programmer, have you ever had to deal with a big heavy BufferedImage and had to go look through the Raster object or whatever and do some conversions or lookups, when what you really want is to just get at the damn pixels already? Seems to happen a lot with media APIs written in high-level languages. I’m still not convinced that Apple’s AV Foundation is going to work out, and I gag at having to look through the docs for three different classes with 50-character names when I know I could do everything I want with QuickTime’s old GetMediaNextInterestingTime() if only it were still available to me.
C is underappreciated as an application programming language. Granted, there’s definitely a knack to writing C effectively, but it’s not just the language. Actually, it’s more the idioms of the various C libraries out there. OpenGL code is quite unlike Core Graphics / Quartz, just like OpenAL is unlike Core Audio. And that’s to say nothing of the classic BSD and other open-source libraries, some of which I still can’t crack. Much as I loathe NSXMLParser, my attempt to switch to libxml for the sake of a no-fuss DOM tree ended after about an hour. So maybe it’s always going to be a learning process.
But honestly, I don’t mind learning. In fact, it’s why I like this field. And the fact that a 40-year old language can still be so clever, so austere and elegant, and so damn fast, is something to be celebrated and appreciated.
So, thanks Dennis Ritchie. All these years later, I’m still enjoying the hell out of C.
Real life intervenes again (parsing PDF, whee!) and I have to cut short a planned epic iDevBlogADay entry. But I do want to bang out a few quick notes on various topics of interest.
The first is Core Audio in iOS 5, which we can now talk about publicly. If we go through the iOS 4.3 to iOS 5.0 API Differences document, we see that Audio Units accounts for a large number of diffs. This comes from the addition of a suite of units that finally make programming at the unit level a lot more interesting. Whereas we used to get a single effects unit (AUiPodEQ), we now get high and low pass filters, the varispeed unit, a distortion box, and a parametric EQ that lets us play with sliders instead of the “canned” EQ settings like “Bass Booster” and “Spoken Word”. Even more useful, we get the AUFilePlayer, meaning you can now put audio from a file at the front of an AUGraph, instead of the sheer pain of having to decode your own samples and pass them to the AUGraph through a CARingBuffer.
iOS also gets the AUSampler unit introduced in Lion, which provides a MIDI-controlled virtual instrument whose output is pitch-shifted from a source sample. This was shown off at WWDC, although providing the source to the unit by means of an .aupreset is still a dark (undocumented) art. This is the first actual MIDI audio unit in iOS, which makes the presence of Core MIDI more useful on the platform.
Core Audio giveth, but Core Audio also taketh away: iOS 5 removes (not deprecates) VoiceIOFarEndVersionInfo. This struct, and its related constants (specifically kVoiceIOFarEndAUVersion_ThirdParty), were documented as interoperating with a hypothetical “3rd-party device following open FaceTime standards”, something I took note of last May as possibly meaning that FaceTime was still ostensibly being opened up. With the removal of these APIs, I think that closes the book on Apple having any intention to live up to its vow to publish FaceTime as an open standard.
There’s lots more to talk about, but I’m already over my allotted blogging time, and work beckons. Perhaps you’d like to hear me speaking about this stuff and demo’ing it? I’m doing an all-new-for-iOS-5 Core Audio talk at two upcoming conferences:
- Voices That Matter: iOS Developers Conference, Nov. 12-13 in Boston, and $150 off with discount code
BSSPKR5. - CocoaConf, Dec. 2-3 in Raleigh, NC, which has early-bird pricing available through Oct. 31.
I’ll also be doing a talk about AV Foundation capture at these conferences. And back on audio, I just heard from my editor that the last three chapters of Core Audio should be in the Rough Cut on Safari Online Books in the next week or so, although I still have some work to do to clean up bits that are broken on Lion (read the sidebar on Audio Components if you’re having a problem creating audio units with the old Component Manager calls) and to clear out forward references to stuff that didn’t end up making the final cut for the book.
It’s been a busy year for Apple user outrage, with radical changes to Xcode 4 and Final Cut Pro X provoking serious anger and lots of bitter denunciations on forums, blogs, Twitter and the like.
I can’t speak for Final Cut Pro X (I have yet to get my video hardware up to snuff), but frankly, I think Mac OS X 10.7 (Lion) deserves a lot more hate than Xcode 4.
And I’m happy to provide it.
Both have bugs, and with massive development, that’s not that surprising. I crash Xcode every few days. I get the spinning pinwheel of death from Lion every couple hours, in situations where it never occurred in Snow Leopard or earlier OS X releases. These will get smoothed out in time.
But once they are, what remains? Let me state my premise clearly: I like Xcode 4 because it’s built atop some fundamentally good ideas, and I dislike Lion because it’s not.
Let’s start with Xcode 4. Being on Lion, I can’t run Xcode 3 to reacquaint myself with the old days, but a few screenshots reminded me of some of its traits.
Xcode 3′s main window had a “Groups and Files” list on the left side. Except it didn’t have just files and groups of them. It also had an icon to represent your source code repository. And your recent searches. And smart searches. And bookmarks. And… you get the idea.
And that was before iPhone. Now Xcode had to handle provisioning, device management, remote debugging, archiving, and so on. iPhone development made demands that Xcode wasn’t really meant to handle, and it’s clear that iOS is going to be more and more important in the future, meaning that Xcode needs to be at least as aligned to iOS development as Mac, if not more so.
And this, to me, is what Xcode 4 gets right: it is a fundamental rethink of Xcode, informed by the first few years of iOS development. Its changes are radical, but in general, they’re based on cohesive and sensible ideas.
The biggest change in Xcode is how responsibilities are divvied up: the project workspace window is the container for anything related to a given project, and the organizer is for cross-project concerns like documentation, device management, source code repositories, and so on. Within the project workspace, there’s a fundamental left-to-right flow of specificity: a selection in the navigator sets the content area, and a selection in the content area can have further consequences in the utility area. That means we can pick files in the file navigator to bring them up in the source editor (the typical case), or use the log navigator to show build or runtime logs in the content area. The generic approach to the content area also opens up new opportunities: we already see this with Interface Builder incorporated as the editor for NIB files, and in Xcode 4.2, the content area offers up a new UI for editing storyboards.
Meanwhile, the now-prominent organizer makes the system of archiving builds more visible, which is critical not only because you now have to use this interface to submit to the App Store, but also because archiving is the only way to symbolicate and thereby make sense of crash logs you get back from Apple.
Quibble with specifics, or the roughness of a new codebase, but I do think Xcode 4 has its head in the right place. It’s built on fundamentally good, forward-looking decisions that put an end to the era in which Xcode frantically shoehorned in new iOS-related concepts, and is better positioned to adapt to whatever Apple throws at it over the next few years.
For a contrast, let’s look at Lion.
As with Xcode, I’ll set aside the annoying bugs — though I don’t know that I’ll ever forgive Lion’s Finder for losing the positioning of icons in most of my windows — and look at the ideas behind it.
What is the underlying concept of Lion? We’ve heard a lot about the importation of iPad features, notably the aggressive use of multi-touch gestures. The big one of these, of course, is the reversing of the scroll direction, dubiously spun as “natural” scrolling by Apple.
The problem with the iPad metaphors, for a start, is that there’s a fundamental difference between desktop and tablet gestures: desktop users are touching a proxy object like a magic mouse or trackpad. On the tablet, you can see the thing you’re touching; on the desktop, there’s a detach between the two.
In many ways, Lion seems optimized for laptops, which always have touchpads, and which enjoy a more intimate relationship with the user than a potentially sprawling desktop. As much as I hear the Mac Pro disk thrashing and see the aforementioned spinner, I also wonder if Lion isn’t really meant for use on machines with SSD storage instead of conventional hard disks.
And if Lion truly is optimized for portables, and if this is the reason for its seeming “iPad-ization”, I think it begs the question: why turn my Mac into an iPad, when I could just buy an iPad instead.
Honestly, I like my iPad. As I’ve said before, I like the iPad more than a laptop, and have gone iPad-only for my last few conferences. Thinking further ahead, the iPad is only going to get more powerful and more capable, while the traditional computer is fairly static in its abilities. Of all the things I need to do, the only productivity that’s really unavailable to me on the iPad is coding: there’s no Xcode for iPad, and it’s not clear whether a slimmed-down version would be possible with current hardware. But it’s not out of the question: Apple introduced Xcode in 2003, and the iPad 2 already outclasses a top of the line PowerBook of that era. In time, and probably not long from now, I’ll be able to do everything I care about on the iPad, and will be happy to.
So why compromise the desktop now, and turn it into something it’s not, which is to say a desktop OS with iPad features bolted on? Lion’s iPad-isms don’t really pay off for me, and what we’re left with is a mish-mash of incongruous concepts. Unlike Xcode 4, there’s no unifying concept behind Lion’s changes; instead, it feels like they’re trying to capture the iOS buzz and excitement, cramming in iPad-isms wherever they can be made to fit.
Steve Jobs famously made the analogy that desktop computers are like trucks, and that fewer and fewer people need trucks. It’s a clever and insightful analogy. The problem for me is that the people who need trucks don’t want those trucks turned into oversized sedans. What consistent ideas are present in Lion serve to work against what makes a desktop OS useful and productive in the first place.
The desktop OS doesn’t need a fundamental rethink; it may well be on a slow path to obsolesence, and it’s fine for Apple to let it go, as iOS is the heir apparent. But in lieu of a grand reinvention that is not likely, necessary, or needed, change for the sake of change is not welcome.
And don’t even get me started about the little things (monochrome icons in Finder sidebars, the hiding of ~/Library, Launchpad… must resist urge to hurt someone…)
I’m a half-day late with my iDevBlogADay post… sorry.
So I was thinking about conference panels recently, something I don’t often attend or participate in. Panels to me seem like something that should work better than they usually do. You have smart, interesting people, but unless they know to “play ball”, to go out of their way to find ways to dig deeper or draw out conflicts and differences between each other, you tend to end up with a lot of head-nodding and personal pet theories that the rest of the panel doesn’t really have a stake in.
It’s not clear that the audience gets a lot out of it either. At Cocoaconf, I was on an iOS developer panel and the first question we got was the hopelessly played out “how do I get my app noticed” one. Ugh. You don’t need a panel for that, we’ve all been griping about that for three damn years now, and if we don’t have good answers yet, we’re never going to. Moreover, I’m not sure that attendees have a good sense of the potential of panels and how they can draw that out.
So here’s a solution. It comes to us by way of the fine folks at Harmonix, makers of Rock Band, Dance Central, the new iOS novelty VidRhythm, the rare iPod nano/Classic game Phase, etc. At their last two panels at PAX, they did a “Reverse Q&A”, which works like this: the panelists either ask big poll-type questions of the room, ask followup questions and get shouted-out responses from the crowd, or they ask “man on the street” style questions to whoever is at the front of the line for the mic. Either way, the topic is then followed up by the panelists and whoever from the crowd happens to be at the front of the line for the mics.
It still seems like a work-in-progress on the Harmonix podcasts, but there is a gem of a great idea here. Anyone who’s working in iOS and attending conferences has something interesting to say, and probably some unique real-world perspectives that wouldn’t necessarily be obvious to the kind of people that get picked for panels. We’re all self-employed hipster indies and authors, so we likely have little if any idea how iOS is playing out in big enterprises, how well or poorly it rubs shoulders with other technologies, etc. So in a Reverse Q&A Panel, I could ask these kinds of questions of whoever is first at the mic: “what do you use iOS for… how’s that working out… what’s missing that you think should be there…”
The responses we would get from the attendees would drive panel discussion, and in a sense, the person at the front of the line for the mic becomes a temporary member of the panel. In this, it’s a lot like the “open chair panel” that I’ve seen pulled off only once (at the Java Mobility conference in Jamuary 2008, where I saw the last gasp of the old world prior to the iPhone SDK announcement a few weeks later).
And I still like the format of both the Reverse Q&A and the Open Chair Panel more than I like straight-up open spaces, which at the end of the day are just chats, and chatting is best done over food and drink, like at the end of Cocoaconf where Bill Dudney, Scott Ruth and I grabbed two guys from Ohio U. that Bill had met and headed down to Ted’s for some bison burgers. That’s chattting. If you’re going to schedule a time and a room, it’s already more formal, and a structure helps set expectations.
I’m inclined to talk up Reverse Q&A as a format to the Cocoaconf and CodeMash organizers… would like to give this a try in the next few months.
And speaking of which, let’s practice. Here are some questions I’d like to ask of Reverse Q&A attendees. Feel free to answer any of them in the comments. I’d like to know what you guys and girls are thinking:
- Do you learn new platforms, languages, and frameworks from books, blogs, official docs, or what? (I want to know so I can figure out whether I should bother writing books anymore… signs point to no)
- What do other platforms do better than iOS?
- What’s the one App Store policy that pisses you off the most?
- Do you sell your own apps, write apps for someone else (employer, contract clients, etc.) or something else? Which of these do you think makes the most sense for you?
- Do you want more or less webapps in your life?
OK, you guys and girls talk for a while…
Random collection of thoughs from my trip to WWDC 2011:
Pre-Trip: Japantown
I always make sure to find time on San Francisco trips to visit Japantown (as I’ve noted before, I often stay in a B&B adjoining J-town). Since last time, a Daiso store has gone in and it’s probably my new favorite thing there. As I described it on Twitter, it’s “like a Japanese Dollar Tree that got drunk and doubled down on the tacky.” Everything’s $1.50, and the amount of odd novelty borders on the infinite. I grabbed my kids some arbitrary little items from here (a tiny LED lantern, mini bike reflectors, etc.) and they were duly amused.
My usual stops are Moritaya toys, Japan Video, and of course Kinokuniya books, which expanded down a floor a few years back and now has a manga department the size of a Waldenbooks. The curation is knoweldgable and thorough, highlighted by an entire shelf of Osamu Tezuka manga, probably the one place in the US where you could buy the entire 8-volume set of Buddha in its entirety. Unfortunately, the set of Phoenix on display was incomplete, likely owing to Viz’s failed release of the series and its subsequent demotion to out-of-print status. As handsome as Veritcal’s Tezuka releases are, I’m sure I’m not the only one who’d happily re-buy all of Phoenix if Vertical could get the rights to re-do it.
Hey, don’t drift off yet… I’m getting back to tech stuff. Also on display at Kinokuniya was an entire table of Hastune Miku and general Vocaloid artbooks and CDs. Miku is the name given to a synthetic singing program, based on the Yamaha “Vocaloid 2″ engine. In an act of shrewd marketing, the different voices are sold as distinct characters, with names, appearances, and personalities that have been further fleshed out by a community of digital media artists who create songs and videos with the characters (a feat made possible by generous licensing terms and/or the traditional tolerance of Japanese business for fan-created works… something that would never be allowed in the litigous U.S. of A.). It’s kind of a shame there isn’t more of substance written in English about this entire Miku phenomenon and its collaborative fan-culture… the best stuff I’ve found so far are the captions to a 10-minute TV Asahi report, and the cover story to the latest Tokyo Kawaii Mag e-magazine.
And the idea of singing software that creates a vocal track by entering pitch and lyrics… am I the only person who thinks this fills an obvious hole in Garage Band, with the novelty that the Western mainstream media has no idea that Miku and her fellow Vocaloids exist? If the English could be improved (and it clearly has a long way to go), it could be a mind-blowing demo at the annual Fall Apple Event. Granted, I wouldn’t necessarily expect Steve Jobs — a guy who dated Joan Baez after all — to be OK with the idea of synthetic singing. But considering that Miku already has 2,000 songs on iTunes and 10,000 on Amazon MP3, there are clearly plenty of people who are already enamored with this non-existent pop-star. And with Vocaloid3 coming in September, the timing would be ideal.
I’m a fan, too. I grabbed “The World Is Mine” when it charted on iTunes a few weeks back, and will be picking up the full Supercell/Miku album when it drops this week. So yeah, I did indulge a $30 Hastune Miku artbook.
[release release];
The talk of the conference itself can only be hinted at without violating NDA. If you watch the video and inspect the slide for the many iOS 5 features that weren’t specifically called out in the keynote, you’ll see the term “automatic reference counting”.
You might already be aware that iOS programming involves a system of tracking memory use by counting references to Foundation objects. You might also be aware that getting this system right drives many otherwise sane developers to the brink of slitting their wrists, because it is so hard to get right. And you might also be aware that OS X has garbage collection, but that this slide didn’t say “garbage collection”, it said “automatic reference counting”.
Yeah, ponder on that for a while. Or get the docs if you’re in the developer program. If it does what the name says, it’s another fantastic illusion: the ease of a GC language, without the compromises and slop of GC.
The Core Audio book, and the other one
I had a chance to meet with Chuck and Kevin, editor and co-author respectively, of the Core Audio book. As noted in my last blog post, Pearson just did a massive drop of three new chapters to the Rough Cut on Safari Books Online. The sample code is all there too. This gives us a clean slate to get to the end (finally!). The plan from here is for me to do an iOS chapter (which will need some iOS 5 tweaks when the NDA drops… not sure how the timing will work out), while Kevin finishes up MIDI. We’ve left space for a final chapter on advanced topics, but we may not end up needing it. Kevin felt that the Audio Unit chapters went about as far on the topic as he planned or expected, and aside from custom units, the only thing I wanted to get in here is static buffering for OpenAL. So this chapter might go away, meaning that we could be in tech review by the end of the Summer. And only, what, a year late?
Oh, and there’s another book that I’ve signed, but I can’t identify the co-author and there’s not enough there to really talk about. But if you know me and made the obvious guesses, you’d have about a 50-50 chance of being right. And if I confirmed that I’m not writing a book on AV Foundation yet, the odds should go into the high 90s. Let’s just say that this is something I was more or less embarrassed into writing.
The iPad-only Experience
As mentioned before, I used WWDC as an experiment in going laptop-free, taking only my iPad and iPhone. Overall, it went about as I expected: I wasn’t able to download the iOS 5 or Lion SDKs or update my devices, but between sessions, labs, and social events, I would barely have had time to use them during my week in San Francisco anyways. I did look up some essential documentation on developer.apple.com and threw the PDF versions over to iBooks for offline reading, which is likely as much as I would have done with a laptop anyways.
The labs still had a handful of iMacs available, though most of the space was clearly set aside for people with their own laptops. I pulled down code for my never-fully-working VTM iPhone 2011 editing/effects demo as a zip and managed to not solve its problems, even with the help of two AV Foundation engineers, though they did give me some advice for some iOS 5 APIs that could perhaps diagnose the problem. I’m also thinking of rewriting my AV Foundation talks anyways, from the bland “introduction” and “advanced” to something more audacious, like “Let’s Write QuickTime Player. On iOS. In An Hour” and “Let’s Write Final Cut Pro. On iOS. In An Hour”. At any rate, between fetching code from the web and from backup zips on my iPad’s AirSharing, even lab time didn’t really require me to bring a laptop.
Where I do think working on the iPad is challenging is where it’s always a problem: when you need to manage several things at once. Writing a blog, for example, is a total hassle, because you have to switch entire apps (not just move between windows), to pick up a URL to copy-and-paste. Moving documents between applications is still touch-and-go, but by design: rather than exposing a file system, apps have to opt-in to accepting files, and many don’t.
But then again, you’d have these same problems if you were using a full-screen mode text editor on the desktop, too. Like these apps, the iPad focuses you on doing one thing at a time, and for that, it’s great. But there are times when I need more than that. Or, to use the vehicle analogy, every now and then I need a real truck, not just a car.
Also, the iPad’s battery life is insane. If we all brought iPads, Apple could have left the power strips in Cupertino. Charge overnight, pound on it all day, repeat.
The Myth of Moscone’s Miraculous Bandwidth
Something else about downloading the SDKs and betas of iOS 5. Everyone’s duly knocked out by the speed of these. What took me five hours to download over 6 MBps DSL back in Grand Rapids took most people about five minutes to download over the ethernet cables at Moscone West. Many took this as evidence of phenomenal bandwidth going through the building.
Then it hit me this afternoon: No, dumbass, they had an edge server in the second floor NOC. They weren’t sending 5,000 attendees times 10 gigabytes of data dozens of miles from Cupertino, or thousands of miles from North Carolina; they were sending it hundreds of feet, over gigabit ethernet gear that you could easily buy at Fry’s. It doesn’t prove the power of the internet, it proves the power of the LAN.
I don’t doubt that Moscone West has extraordinary internet access (people posted screenshots from SpeedTest.net to prove it)… but I also don’t doubt that they charge dearly for it. With everyone hitting the same files, Apple would be nuts to not just bring their data with them.
What would have been interesting, had I thought of it, would have been to try getting a similarly-large (multi-GB) file that’s unlikely to be on an Apple server inside the LAN, like a Linux .iso or something. If the Apple bits remained phenomenally faster, I’d take that as evidence they were already in the building.
A Supposedly Fun Thing I’ll Never Do Again
OK, grumpy bit: I’d never done “Stump the Experts” before, and by all appearances and accounts it has a long and hilarious history at WWDC. And a shambling mess that refuses to take itself seriously is often a grand time.
But really, this event came off as a waste of time. Organizers collected onstage a glorious assemblage of luminaries who shaped Apple’s history… and then promptly did nothing with them. Only a handful of audience questions (6, maybe?) were posed to the experts, the best of which was a rhetorical question. The experts themselves were never even identified, or given a chance to be applauded for their contributions over the years. Some of the questions asked of the audience were deviously clever, but if that’s the best part, maybe that should be the form the event takes in the future.
I’m sure it’s great. So are World Cup soccer, scripting languages, and Kate Bush. But that doesn’t mean they do anything for me.
Latin for “fail”
My goodness the nearly-vacant Metreon looks pathetic. And turning it into a Target, in the middle of the city’s convention district, is going to be just plain weird.
And that’s coming from someone who started this article talking about his affection for a virtual pop singer, so I think I know weird when I see it.
Boom?
As I’ve been writing, I got word that iOS 5 breaks my iPod sample-reading example, which apparently a lot of people have been trying out (thank you!). I’ve joined the forum thread and promised to look at it tomorrow. My first guess is just a bug and not nefarious skullduggery!… but working with Apple, you never know when you’ll be knifed in the back, so… sure, maybe.
I’m going to get some sleep and pick up on that, and client work, in the morning. Like all WWDCs, we return with much to do. A good problem to have.
Just in time for WWDC, we have two bits of news about the Core Audio book.
-
First, the next three chapters are finally available on the Safari Online Books “Rough Cut”, so those subscribers can now read chapters 7-9, covering Audio Units, advanced Audio Units, and OpenAL. This is some of the hardest material in the book, and as we thought that units were important and underserved by existing documentations, we just let things run long and get deep, ultimately walking through four example programs.
-
Our editor has been working on a big WWDC-week promotion, an enormous iOS/Mac development EPUB sampler from various Pearson imprints (Addison-Wesley Professional, Prentice-Hall, Sam’s, etc.). The thing is over 400 pages when opened in iBooks, and contains complete chapters from eight books, including chapter 7 from Core Audio. Yeah, the first half of the just-released Audio Units material. 60 pages of the stuff. Freebies. You’re welcome.
Plan from here is to do three more chapters: Core Audio on iOS, MIDI, and Advanced Grab Bag of Fun and/or Evil. I can’t publicly avoid the fact that this has been a troubled project – our last update was in, what, September? But a splash of visibility and viability may be what we need to finally make the final push to get this title wrapped up, rewritten and polished, and off to the printer.
And no, I don’t know where the download code is. I sent it to Chuck two months ago. If it continues to be a problem for readers, I’ll probably put a second copy on my Dropbox next week and just point people there.
