

John Siracusa's in-depth review of Snow Leopard on Ars Technica - glhaynes
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars

======
e1ven
I always love John's OSX reviews; I've been hitting refresh compulsively for
the last few days, reloading the URL where it would be.

What I find interesting is what he chooses to cover and not cover- The review
is 23 pages, which is quite a codex, but choices had to be made.. There is a
page dedicated to the specifics of GCD's C interface, but only a paragraph
about the revised Services design.

In all, I think that Ars does a wonderful job with these reviews, and like
10.6 itself, a lot of the depth is built on top of previous (excellent)
releases. For example, we know that John thinks the hybrid finder, which is
neither Spacial or truly a file browser, is a strange beast, and he's linked
to his epic discussions about the finder in the past. In this review, all that
is needed is discussing the changes that bring us into SL, and the review does
that well.

I've joked to my friends before that sometimes I'm more excited about the Ars
review of a new release than I am about actually installing it, and the new
version delivers as promised.

Snow Leopard looks to be doing a great job in laying the foundation for the
next few years of OSX- It's interesting to watch how the relationship between
the iPhone and Mac code continues to evolve.

~~~
masklinn
> I've been hitting refresh compulsively for the last few days, reloading the
> URL where it would be.

Wow, I'm glad to learn I wasn't the only guy doing that.

------
jsz0
I was relieved when Apple announced there would be no major UI changes in Snow
Leopard. I like the OSX GUI a lot. Some minor tweaks are fine but there's
always so much pressure to 'make it look different' that we often give up
perfectly functional UIs for the promise of something indescribably better. It
rarely works out in the end. Radical GUI overhauls almost have to be tied into
radical UI toolkit overhauls to force developers to adopt your fancy new ways
of doing things.

I am surprised he didn't cover the changes to the Services menu. I feel like
it's one of the biggest obvious changes to Snow Leopard. I doubt many people
used, or even understood, what the Services menu was in previous versions.
It's now an incredibly useful context sensitve feature that appears to be
extensible through Automator. This could be the biggest stealth UI paradigm
shift in SL. My only gripe is discoverability. Apple did a great job fixing
this feature but people who are used to ignoring it will continue to do so.
Something simple like an icon next to the menu entry might have caused people
to give it another glance.

Overall this is a fantastic review. I am a little disappointed that 10.7 came
out around page 13. I'll never catch up now.

------
railsjedi
John got me incredibly excited about Grand Central Dispatch. I'm almost
tempted to start tinkering with Macruby to see if I can't get that
functionality without having to relearn C.

~~~
cubicle67
agreed. best explanation I've seen by a _very_ long shot

[http://arstechnica.com/apple/reviews/2009/08/mac-
os-x-10-6.a...](http://arstechnica.com/apple/reviews/2009/08/mac-
os-x-10-6.ars/12) and [http://arstechnica.com/apple/reviews/2009/08/mac-
os-x-10-6.a...](http://arstechnica.com/apple/reviews/2009/08/mac-
os-x-10-6.ars/13)

Edit: you've gotta get excited when you see examples like this

before:

    
    
      for (i = 0; i < count; i++) { 
         results[i] = do_work(data, i); 
      } 
    
      total = summarize(results, count);
    

after:

    
    
      dispatch_apply(count, dispatch_get_global_queue(0, 0), ^(size_t i) {
         results[i] = do_work(data, i); 
      });
    
      total = summarize(results, count);
    

_And there you have it: a for loop replaced with a concurrency-enabled
equivalent with one line of code. No preparation, no additional variables, no
impossible decisions about the optimal number of threads, no extra work
required to wait for all the independent tests to complete. (The
dispatch_apply() call will not return until all the tasks it has dispatched
have completed.) Stunning._

~~~
masklinn
<puts on nazi hat> then again, it's always been utterly trivial to do that in
Erlang, just replace

    
    
        Results = lists:map(DoWork, data)
    

by

    
    
        Results = pmap(DoWork, data)
    

with `pmap` being implemented with 15 lines of Erlang.

~~~
tjogin
The whole point of GCD is that it is a central entity that knows how much work
the entire system is doing on each individual processor core, and can adjust
the number of threads accordingly.

Does your Erlang example take into account the _overall_ work the _entire_ OS
is doing on each individual processor core, adjusting the number of threads as
the amount of _overall_ work changes — or does it just take the Erlang-
program's own work into account?

~~~
masklinn
> The whole point of GCD is that it is a central entity that knows how much
> work the entire system is doing on each individual processor core, and can
> adjust the number of threads accordingly.

No. That's a side effect and benefit. The whole point of GCD is that it's
trivial to use, therefore making it easy to benefit from multicore machines.

> Does your Erlang example take into account the overall work the entire OS is
> doing on each individual processor core, adjusting the number of threads as
> the amount of overall work changes — or does it just take the Erlang-
> program's own work into account?

In the erlang view of the world, the erlang runtime is the OS. And within that
context, Erlang takes in account the overall work of itself (in fact, it more
precisely doesn't give a damn: it spawns a scheduler thread per logical core
-- or more or less if you ask it to -- and then dynamically maps Erlang
processes on these OS threads the way GCD dispatches queued tasks to its
threadpool).

~~~
tjogin
The first two letters stand for Grand Central. That's not a side-effect, it's
a core purpose, without which it would not do half of what it does, nor do it
half as well.

While Erlangers may view the Erlang environment as the universe, it decidedly
isn't, as it runs on an OS that does other things as well. Your Erlang
example, while I'm sure it's really great for you and other Erlangers, simply
doesn't do what GCD does.

~~~
masklinn
> Your Erlang example, while I'm sure it's really great for you and other
> Erlangers, simply doesn't do what GCD does.

That's very debatable, but thank goodness it wasn't my point in the first
place. My point was simply to do what cubicle67's example demonstrates, namely
(in his words)

> And there you have it: a for loop replaced with a concurrency-enabled
> equivalent with one line of code. No preparation, no additional variables,
> no impossible decisions about the optimal number of threads, no extra work
> required to wait for all the independent tests to complete. (The
> dispatch_apply() call will not return until all the tasks it has dispatched
> have completed.) Stunning.

That's very precisely what the Erlang example does.

~~~
pohl
As a fan of Erlang, it might have been better to stick to your initial point
rather than trying to disagree with tjogin about what is/isn't a central
purpose of GCD. That tangent was orthogonal to the syntactic elegance you
wanted to highlight.

Of course, if that sort of thing was a core design goal from the outset it
damned well should be more elegant! It's much harder to bolt closures on to C,
and a bit of syntactic elegance had to be traded off to make it happen, no
doubt. I'd say they did a fine job given the constraints. My favorite touch:
they chose a glyph for the block pointer that was actually pointy: ^

I don't want to detract from Erlang, because you were right to highlight what
it does so well...but it's nice to see these ideas make it into the C
foundation of a mass-market operating system in a manner that is both central
and grand, even if the syntax isn't quite as tight.

~~~
masklinn
> but it's nice to see these ideas make it into the C foundation of a mass-
> market operating system in a manner that is both central and grand, even if
> the syntax isn't quite as tight.

Absolutely. And I find the syntax pretty tight anyway.

------
ajtaylor
I had the pleasure of working with John a few years ago in Boston. Very smart
guy. A bit quirky, but aren't we all in some way? :-) His reviews have always
been of special interest to me because he peers into the cracks that most
reviewers don't even notice, must less explore.

------
mhansen
Wow. I saw the 23 pages and closed it, but after seeing comments here I'm
reading it and I've learnt a hell of a lot. This isn't your everyday review!

~~~
randallsquared
As e1ven mentioned, it really is pretty normal for this guy. :)

------
huyegn
That was one of the best technical reviews I've ever read. His composition
style flowed incredibly well.

~~~
masklinn
Check out his previous OSX reviews as well, they're glorious:

[http://arstechnica.com/apple/reviews/2000/10/macos-x-
beta.ar...](http://arstechnica.com/apple/reviews/2000/10/macos-x-beta.ars)

<http://arstechnica.com/apple/reviews/2001/04/macos-x.ars>

<http://arstechnica.com/apple/reviews/2001/10/macosx-10-1.ars>

<http://arstechnica.com/apple/reviews/2002/09/macosx-10-2.ars>

<http://arstechnica.com/apple/reviews/2003/11/macosx-10-3.ars>

<http://arstechnica.com/apple/reviews/2005/04/macosx-10-4.ars>

[http://arstechnica.com/apple/reviews/2007/10/mac-
os-x-10-5.a...](http://arstechnica.com/apple/reviews/2007/10/mac-
os-x-10-5.ars)

~~~
cubicle67
This is interesting; you've posted the exact same set of links as mikedouglas
below, but 4 hours later, and yet (at the time of writing) your comment's got
3 points, and his is on -1

Is it because he used bit.ly? (I'm not being snarky, just curious)

~~~
masklinn
> Is it because he used bit.ly? (I'm not being snarky, just curious)

Might be. I hadn't seen his comment yet when I posted mine (was just scrolling
down) and just wanted to point the previous reviews to huygen (I'd kinda
missed they were on the last page and he'd already got the links through the
article itself).

------
chris24
It's split onto 23 pages? Uh, wow.

~~~
dasil003
Yeah, this is the first time I'm actually using a "bookmark" as such.

------
mronge
I see how GCD is going to make putting long running tasks on a separate thread
easy, but I have a bone to pick. In his GCD example he has this example of
code

    
    
      - (IBAction)analyzeDocument:(NSButton *)sender 
      { 
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
          NSDictionary *stats = [myDoc analyze]; 
          dispatch_async(dispatch_get_main_queue(), ^{
            [myModel setDict:stats]; 
            [myStatsView setNeedsDisplay:YES]; 
            [stats release];
          });
        });
      }
    

It takes a potentially long running operation, analyze, and put it on a
background thread. Once it's done, the UI is updated on the main thread. GCD
made that ridiculously easy, but, this is assuming that the objects reference
from your block are thread-safe.

It may be that the analyze method isn't thread safe, and mutates some state
inside the myDoc object. So it made one part of creating async/multi-threaded
apps easier, but you still need to be careful with mutating state like that.

~~~
antonovka
_It may be that the analyze method isn't thread safe, and mutates some state
inside the myDoc object. So it made one part of creating async/multi-threaded
apps easier, but you still need to be careful with mutating state like that._

Yes. I believe many Mac developers attempting to leverage GCD are going to get
a long-overdue wakeup call regarding their extremely prevalent use of mutable
state.

------
mikedouglas
Previous reviews:

<http://bit.ly/osx10-5>

<http://bit.ly/osx10-4>

<http://bit.ly/osx10-3>

<http://bit.ly/osx10-2>

<http://bit.ly/osx10-1>

<http://bit.ly/osx10-0>

~~~
Derrek
I'm curious, why use URL shortners on HN? It's not like you're constrained to
140 characters. (I'm not trying to be a jerk, just trying to understand your
reasoning.)

~~~
mikedouglas
Siracusa tweeted the links the day before, so I had them in a textfile on the
desktop. Because the URLs were easier to read than the originals, I didn't
think it would be an issue.

------
mrshoe
What does the y-axis on the graph on the first page represent? I might be
missing something, but that curve looks completely arbitrary...

~~~
pohl
He explains in the text: "The releases are distributed uniformly on the Y
axis". In other words, there is an equal amount of space between each release.

Although someone does point out in the comments that he has left out the
initial release of Tiger/x86, which was arguably a 0-features follow-on to
Tiger/PPC. That would have changed the shape of the curve. The choice is
completely arbitrary.

------
sachinag
Summary: "Should you buy Mac OS X Snow Leopard? If you're already running
Leopard, then the answer is a resounding 'yes.' If you're still running Tiger,
well, then it's probably time for a new Mac anyway. When you buy one, it'll
come with Snow Leopard."

I love Ars; a lot of 'em are here in Chicago, but man, this shit can get out
of hand. At least they do the summary themselves on the last page.

~~~
dcurtis
I'm actually sick of reading countless shallow reviews that just reiterate the
crap that you can find by booting Snow Leopard on your own. This article has
an amazing amount of information that has not been previously publicized in
detail.

------
hyperbovine
23 pages when you're gonna buy it anyways.

~~~
neilc
I think you obviously don't read a review like this because you want to
understand whether to plunk down your $29 -- you read this because you want to
understand Snow Leopard.

~~~
unalone
I'm slowly drifting away from being a tech geek, and so articles like
Siracusa's let me see in ridiculous detail what's going on with a piece of
technology that I love. It's a damn good read for the sake of reading.

