The Year in Mac Development
It's risky to write a "year in review" story since there are just so many of them, but I'm going to carve out my niche and look back at the stories that mattered to Mac developers in 2006.Intel
This was, unquestionably, the year of Intel for Mac developers. An Apple partnership with Intel seemed pretty strange at first, but it truly paid off. The Core 2 chips are very fast, and the Core 1 was no slouch either. The Mac received huge performance gains, reduced its power consumption, and moved almost entirely to dual-core 64-bit chips in about a year. On top of all of that, we have Parallels.
Human Interface Guidelines, Or Lack Thereof
From reading developer blogs, you'd think Apple made an announcement this year about discontinuing the Human Interface Guidelines document. It didn't happen. If anything, it was John Gruber's talk at C4 that sparked a realization that the HIG no longer reflects the current state of Mac software.
The state of HIG really stems from Apple's first priority: to make the best OS and apps they can. Frequently, this means making up the rules as they go. After the dust settles, they take the most effective bits from the apps developed internally and generalize them for third-party developers. It would be nice to have all of the Apple code immediately, but the app and framework teams run on different schedules. And of course, Apple has the right to keep some widgets to themselves, just as third party developers can have their own widgets.
It's not even clear if a reasonable HIG document could exist in this environment. All of this is constantly changing. And really, they're just guidelines anyway — not rules. "Violating" them is arguably an oxymoron. Daniel Jalkut (who I think had the best write-up on C4) summed up John Gruber's talk succinctly: The new HIG guideline is simply: does this look good?
Apple's focus must be producing software that make people want to buy a Mac, even if it means temporary inconveniences for developers. The company's single most biggest responsibility to the platform is to provide a constant influx of new users. We can invent code if necessary, we can't invent people.
If you need one rule to follow, make it this: don't introduce new behaviors for existing controls. Don't make a checkbox act like a push button or a slider act like a scroll bar. That will confuse users. If you need new behavior, make a new control. And when in doubt about UI standards, just do as Apple does. They have millions of customers, so consider that your buffer zone. Or just do whatever you think would work best.
Delicious Generation
It's tempting to lump the "delicious generation" idea in with the HIG story, but I think it's separate.
The Delicious Generation meme, started by Rogue Amoeba founder Paul Kafasis, describes an app which puts enough emphasis on fun and "cinematic" production values to make any computer science professor cringe. The term was based on Delicious Library, but one app soaked up most of the controversy: Disco.
Critics of Disco accused the developers of making something that was more about appearances than solving practical problems. Supporters say Disco takes something that's tedious and makes it fun. Disco actually billows smoke from the main window during burning, which some thought as ridiculous but I saw as the ultimate example of Mac developer ingenuity — like something from MacHack that actually shipped.
Some went so far as to say Disco just bound up Apple's frameworks into a pretty package. Although that's supposed to be an insult, I think that's really the goal of the frameworks: maximum reuse. If a developer sees value in putting a new face on an existing tool and users "get it," then so be it. I'd be more comfortable dropping my mom in front of Disco than Disk Utility.
The most interesting piece of this puzzle is that when developers violated the UI guidelines in the past, it was out of apathy or misunderstanding of how the Mac works. Such apps were obviously out of place on the platform. These new apps are different by design. It's intentional and thoughtful, and it's done within the Apple design universe.
But no matter how polished apps like Disco are, they're inherently polarizing because they're such a radical break from the Mac's minimalist roots. Still, it's challenging to build a case against them while Apple is busily doing the same with Aperture and Time Machine. On top of that, a non-trivial amount of the Mac user base likes these apps.
Some believe that the Mac would better off with a more subdued, unified look and that the current trend is leading us towards imminent doom. Personally, I'll take controversial interfaces over stagnation. Remember, there was a time when it was assumed that Mac OS X, Aqua, Quartz (and for some, even Cocoa) were signs of imminent doom.
Core Animation
If you thought custom interfaces were radical before, Core Animation looks to open the floodgates on wild interaction possibilities. Front Row-style interfaces will no longer be the realm of OpenGL experts only.
The fancy 3D effects are what get most of the eyeballs, but it's actually useful for much more than just building virtual cities of album art. It's an API for creating layered user interfaces with implicit behaviors. The new warning balloons in Xcode editor use Core Animation, for example.
Since the Core Animation workload runs on its own thread, applications can take advantage of a second core for UI rendering without doing anything at all. Combined with the existing performance benefits of Core Image, the results can actually be faster than what we have today in Tiger.
Objective-C 2.0
Although there is some skepticism, Apple is bringing Objective-C up to date with newer industry conventions. The two most important changes are garbage collection and property support. The idea here is pretty simple: make it easier to write Objective-C code.
Memory management is probably the most tedious thing you can possibly do in a programming language. Some think manual memory management is necessary for performance reasons, others feel that most applications can get away with letting the garbage collector do the work. Either way, Apple's system is opt-in.
David Young has some doubts about the properties system in Objective-C 2.0, as does Patrick Thomson.
Personally, I think the best thing Apple can do is maintain the essential parts of Objective-C and meet in the middle on syntax. The dot syntax has become nearly universal, and frankly I'll take this:
value = object.this.that.something.somethingElseover this:
value = [[[[object this] that] something] somethingElse]any day of the week. Keep in mind that square brackets aren't going away, it's just that there's going to be a new syntax available for getting and setting property values. All of the normal conventions still apply.
There may be some limited confusion with structs versus objects, but I think it's a small price to pay for making the syntax more readable and more accessible to a wider audience. Having people writing Mac software is a good thing, and the higher-level abstractions always seem to win in the long run.
Revamped Developer Tools
Apple doesn't talk much about Xcode 3 on the Leopard Preview site, but the highlights are refactoring support, improved display of warnings and errors, and project snapshots. The other big news is that Interface Builder is getting a major revamp. You can get a glimpse of it on the public site, but rest assured, big things are in store.
The Leopard dev tools will also include a new app called Xray, which is a catch-all for tuning performance. It's worth mentioning that Xray uses Sun's Dtrace framework to do some of its magic.
More info on the new tools is available here.
MacHeist and MyDreamApp
One of the biggest stories in Mac development for 2006 came at the end of the year, in the form of something called MacHeist. If you want to watch it all play out, you can see the MacHeist feature page at Cocoa Blogs.
Again, this was a polarizing issue. In short, the organizers of MacHeist offered a lump sum to certain developers for the rights to sell their product for a week. MacHeist bundled up ten applications with a combined value of $356.74 and sold them together for $49, with a portion of the sales going to seven charities. I wrote about this before (the comments are interesting too), so I don't want to rehash too much, but here's the gist.
Some said the developers were not getting a big enough cut. John Gruber shared this opinion and ran some numbers in an analysis of the event. As far as I can tell, most of the developers that participated did not regret it. Two of them actually sent me emails to confirm this, and Wil Shipley was quite public about the fact that Delicious received an increase in direct, full-price sales during MacHeist.
MacHeist sold 16,821 bundles and handed over $200,000 to charity. But this wasn't just a software auction. Even if you disagreed with the financials, it's hard to deny that MacHeist was a cleverly-conceived community game which brought thousands of Mac users to one place on a daily basis. The production values rivaled even those of Apple.
The critics of MacHeist maintained that the organizers took too large of a cut, but I'm curious how many people thought about where the proceeds are going. Maybe the MacHeist folks want gold-plated Ferraris, but it could also be the profits will be re-invested into other events or Mac-related ventures. I guess we'll see.
The less-controversial precursor to MacHeist was MyDreamApp, which was a contest losely based on the American Idol concept. Contestants submitted their concepts for a Mac apps and thousands of visitors to the site voted on their favorites. The contest featured celebrity judges and, again, did a fantastic job of building community. The winning application concepts are currently under development.
MacSanta, Cocoa Duel and Child's Play Day
Apparently launched in response to MacHeist, MacSanta was a holiday-themed site which offered 20% discounts on over 200 Mac applications through Christmas day. The site didn't feature any of the puzzles, charity donations, or community forums that were central to MacHeist, but it did bring a number of lesser-known developers into the spotlight and offered good deals to both users and developers.
Cocoa Duel was another apparent echo of MacHeist, though this one was conceived of as a peace offering between developers. Jason Harris quickly put together the IronCoder-style contest, where participanmts submitted holiday-themed applications and site visitors voted by donating to the charity suggested by their favored developer.
For example, my favorite (which was also the crowd favorite) was Snowplane by Jonathan Grynspan. I voted for his app by donating $30 to Child's Play, his favorite charity. Cocoa Duel raised nearly $2400 in six days, which is impressive given how little time there was to work with.
Last but certainly not least, Mike Zornek organized the Child's Play Day charity drive where a number of developers donated all of their sales on a single day to Child's Play. The final tally was $10,000.
Charity and Awareness
If you do the math for MacHeist, Child's Play Day, and Cocoa Duel, $212,400 was raised for charity in a very short period of time and with no mainstream advertising. That would be impressive by any standard, but it's particularly amazing given none of these efforts had high-end corporate sponsorship. All of it was a product of the Mac community's home grown efforts.
No matter how you slice it, all five events raised awareness about independent Mac developers within the Mac user base and even into the general online population via social sites like Digg. I'd wouldn't be surprised if even those who develop primarily for Windows or Linux were impressed at the visibility of both events.
Perhaps most importantly, these events took the idea of buying independent Mac software out of the shadows and brought it into the community's consciouness. A lot of the stigma of supporting smaller developers has been lifted, hopefully improving things for everyone involved.
Other Worthwhile Stories
There are a few others things that we couldn't close out the year without mentioning. First, in an effort to find creative sources of funding, the developers of both Cha-Ching and Disco introduced the unothodox idea of selling beta software at a reduced price.
I wrote about this just a few days ago, so it doesn't make sense to go into detail here, but I think it's an interesting strategy in self-funding. I hope it helps these developers succeed where they otherwise wouldn't have. Maybe even those that don't use the apps can appreciate the pursuit of making your idea work.
Another 2006 side story is that all Macs that have built-in displays now come with embedded iSight cameras. Is it just for video conferencing over iChat and Photo Booth? Well, that and scanning in items with Delicious Library. Is there more to this story? We'll have to wait and see.
Although the wheels were set in motion back in 2003, I think Apple has successfully installed WWDC as the second big Mac show of the year. The fact that the mainstream media follows the event is telling, as is the growing attendence each year. Seriously, I'm not sure where they're going to put all these people in 2007.
The Real Story of 2006
I think the biggest story from this year is that Apple finally got out of the shadow of its early success with the original Mac in the 80s, and has redefined what it means to be Apple Computer. Not only is the iPod a true cultural phenomenon, but 2006 can lay claim to the most Macs ever sold in a single quarter.
During the nineties, many were waiting to see who would fill the void left by Apple. It turns out it was Apple, just a newer version, ten years in the making.
I also hope that no one gets too wrapped up in the topics that are seen as important and controversial. To echo what I said in my post about MacHeist, no one is going to look back on this and concern themselves with which widgets drew in which colors or how much money was made in a particular software promotion. If you do it right, your memories will center around how much fun you had.
I know how it sounds — preachy and know-it-all-ish, but consider giving the thought at least a few minutes of your time. Even though we disagree on things, we're all Mac developers, participating in changing the Mac landscape in some way, and I think that's pretty damn cool. What you do could have an impact on millions of people, and the current "problems" are nice ones to have compared to the challenges faced by Mac programmers ten years ago.
There's never been a better time to make Mac software, and who knows when an opportunity like this will come along again. So just do the best work you can and don't worry about what everyone else says. Everything from this year — both the successes and conflicts — are in the past. Focus all of your attention on what you believe will make you happy now, in the present.
Eyes on the road. And as it says on the home page, follow your bliss.
The Year in Mac Development
Posted Jan 1, 2007 — 27 comments below
Posted Jan 1, 2007 — 27 comments below
macFanDave — Jan 01, 07 2961
I have worked extensively in C, and have done work in C++, Java and VisualBasic and RealBasic (and I'm just getting started in C#). While the square brackets are jarring at first sight, I caught on pretty quick and grew to really like the look of ObjC.
I love the labels on the methods. It makes code self-documenting and has given me fresh disdain for the argument lists all of the other languages use. For example, when I do a qsort() in C, I have to think really hard (or dig up the documentation) to remember is the first size_t the number of items to sort or the size of each individual item?
I've only used categories a few times, but it is a great way to add the exact functionality you need to a big honkin' class easily. Other languages either cannot do this at all, or it is not nearly as easy.
I like the idea of Automatic Garbage Collection only if the ability to do manual memory management remains as an option. With current computing power, I believe the "hit" you take for using AGC is imperceptible to the user in most applications. Nevertheless, if I ever have to write something that is so demanding that AGC becomes a noticeable liability, I'd like to have the ability to specify the exact lifetimes of each object.
One thing I'd like to see in ObjC is a real decision about designated initializers. The "book" states they exist, but in practice, it is not always clear which of the -init... methods is the DI, and if you don't have access to the source code, you cannot know whether all other inits use it. Sometimes you are lucky and the developer has kindly put a comment in about which method is the DI, but I wish there were some syntax that denoted it uneqivocally. Or, abandon the DI altogether and suggest it as a design practice only.
Happy New Year, everyone!
Nick — Jan 01, 07 2962
I think the poster child for Apple's inadequacy in this department is the source list. In this post from last year, Sven Porst outlines the inconsistencies in the source lists in a variety of apps. Now, I'm not a Cocoa developer, but I believe there is still no standard source list widget that developers can use to implement this functionality.
As far as I can tell, this blindness is limited to the user interface widgets. There are many, many examples of private frameworks that Apple has opened up to developers over the course of Mac OS X's development: Disc Burning, Cocoa Bindings, Core Data, Core Image, Core Video, Core Animation, Sync Services, and probably a number of others I'm forgetting.
For all of these, you can find examples of Apple apps that had the functionality before they became a public framework. For example, the functionality in Core Video was presumably developed for Final Cut Pro and Shake. Sync Services similarly had a prior life as a private API. I just don't see many examples of this at the UI level, besides brushed metal windows, but perhaps other commenters can enlighten me.
Matt Tavares — Jan 01, 07 2963
Properties are the most useless and confusing addition to objective-c that you could think of. What do they add to the language? Are they iVars? uhh, kinda. Do they flow when other objects don't use properties? NO. Do they confuse your average C person becuase everyone knows "." means a non-allocated property and -> means an allocated property. YES!
Lets go into a bit of detail:
Right now, you can create properties in objective-c 1.0 code, just by adding the handy @public keyword in your iVar prototype:
@interface MyGreatObjectThatDoesntUseProperties : NSObject { @public NSMutableDictionary *dict; } @endAnd hey, guess what, this will actually work:
obj->dict;No confusing "." syntax, no having to check whether it is a struct or an objective-c object.
And look at it this way, lets say you have a class that stems properties which stem public ivars, well then you have a mess on your hand.
value = object.this->that.something->somethingElseConfusing isn't it, now you dont know which object is a struct or an actual object. Thanks Apple!
The whole reason objective-c is great is becuase it keeps everything so simple, its just a small but incredibly usefull layer above c. Now its trying to be its own thing, which isn't what objective-c is. If anything, Apple should at least take a page from ruby and implement lexical-scopes or blocks or something that is atleast usefull.
Scott Stevenson — Jan 01, 07 2964
To be honest, this may become a moot point shortly. We don't know what Leopard has in store yet.
@Matt: Treating an Objective-C object as a struct isn't the same thing as the properties system. Direct struct field access isn't evaluated at runtime (therefore can't be manipulated by Objective-C/KVC magic) and it's not future proof. If the Objective-C runtime changes to make field access a hard error, all of that breaks. If the pointer is null, the app crashes.
The whole point of properties is that they provide the syntactic conveniences of direct access while still properly abstracting things from the raw data structures and activating dynamic dispatch. From the caller's perspective, it's very similar to KVC, just without all the -valueForKeyPath:@"..." stuff wrapped around it.
In other words, this:
value = [object valueForKeyPath:@"item.thing.value"]; [object setValue:value forKeyPath:@"item.thing.value"];Is roughly equivalent to this in most cases:
value = object.item.thing.value; object.item.thing.value = value;I agree low-tech implementations are better when complexity doesn't buy you anything, but Apple can't pretend that the whole world revolves around C anymore. For better or worse, Ruby, Python, JavaScript and so on have changed how people see programming.
With this approach, they can meet in the middle on syntax and still take advantage of the fact that Objective-C is both compiled and dynamic. And just like garbage collection, you don't have to use the dot syntax it if you don't want to.
I don't know how serious the issue of mixing structs with objects actually is. There are a lot of things programmers could do to make Objective-C code look ridiculous (and some do), but typically sensible conventions win when good programmers are writing code. I don't know if the this/that/something example you gave would actually compile. It might, but I haven't tested it.
Matt Tavares — Jan 01, 07 2965
But in theory my example should work, if "object" is an objective-c object, "this" is a property of "object", "that" is an ivar of "this", "something" is a property of "that", and "somethingElse" is an ivar of "something". Confusing I know, but this just demonstrates how properties can become ambiguous when in the mix with objective-c objects, structs, other properties, and even c++ classes.
Objective-c already has a great way of accessing object data where nesssary, accessors make code more readable, and in the event that you need to access a path you can just use: [object valueForKeyPath:@"..."].
Properties are a nice addition to objective-c, i'll admit, but there are so many better things that should come before properties. Blocks, operators, and stl compatibility would add miles more of a difference than properties. Which just goes to show that Apple still thinks the world revolves around C.
Objective-C is a wonderfull programming language, but apple has to set its priorities straight (I mean c'mon, they are just adding garbage collection now when it was "supposed" be available in 10.4).
Regardless, thank you for your insight on objc properties.
Nick — Jan 01, 07 2966
I would think that no two of these apps' source lists behave in exactly the same way. It's certainly not the end of the world, but I think everyone involved would be served better if there was a standard widget that handled sources lists, Apple, Third-party developers, and users. My pet annoyance is that not all of these implementations support in-place editing of source names: I can't edit the name of an iPhoto album or NetNewsWire feed by double-clicking on it, yet I can edit an Address Book group this way.
Again, this is just an example. Apple has certainly not done nothing with the UI layer in the last few years, but it seems to me that the major new frameworks added since 10.2 have no parallel in the UI layer, even though Apple has clearly been putting many custom widgets in their own apps.
Nick — Jan 01, 07 2967
These are the unsexy areas where Apple, as the platform vendor, should be putting in the work (both in design and user testing) so that the application developer doesn't have to.
Chris Ryland — Jan 01, 07 2968
It does make more work for developers, but in some sense it's put a lot of power back into UI design, instead of having everything look the same. And I think people even appreciate the added "color" (in terms of the overall texture and colors) of the resulting desktop.
@Nick: drawers seem almost officially dead as UI elements.
David — Jan 01, 07 2970
Well, sorta, but that's far from the full story.
Certainly some Mac developers violated the UI guidelines out of ignorance or indifference, but many developers had to "violate" the rules in order to do things that Apple weren't doing.
Keep in mind that up until relatively recently, Apple frowned on such UI elements as "sound" and "color". (Check out Toolbox Essentials on this topic.) Even animations are the new kid on the block, UI-wise. Many of the rules that Apple laid down were designed for another interface era: a time of static, mostly-modal interfaces, for an OS which was fundamentally ill-equipped at truly doing multiple UI tasks in real time.
Games developers, in particular, had to constantly break the rules: there was no Toolbox API functionality for "render my pretty custom control and composite it nicely alongside a Control". Most anyone doing real-time work (video, compositing, games, etc.) found that at some point, the guidelines were irrelevant, didn't work or didn't exist.
Scott Stevenson — Jan 01, 07 2971
A lot of those apps just use table views and outlines views, which have been a standard part of Cocoa since the dawn of time. Certainly developers subclass NSTableView to customize the look and behavior, but that's by design. I think it's unrealistic and unnecessary for every app's sidebar to behave and look the same since different apps do different things.
The articles promotes a level of consistency that I think is unlikely to ever happen. The author has an exquisite sense of attention to detail, but people just won't agree on the one "right" way on such fine-grained issues.
For what it's worth, I think of "source lists" as the light-blue thingies with the resizing control at the bottom, seen in both Mail and iTunes. Maybe that's not the conventional definition, I don't know.
Drawers, too, have been completely neglected since 10.0, and they definitely need some serious work or simply a replacement
I agree with Chris. I think drawers are essentially done.
Scott Stevenson — Jan 01, 07 2972
It might work, but I wouldn't assume it does. From an implementation perspective, I think it would be more manageable to disallow statements which mix properties, structs, pointers to structs and so on. That could be a real mess for both the compiler and anyone who has to read that code.
Objective-c already has a great way of accessing object data where nesssary, accessors make code more readable, and in the event that you need to access a path you can just use: [object valueForKeyPath:@"..."].
I actually think that's too verbose for today's purposes, and it can be somewhat expensive to parse the keypath string. Properties are implemented at the compiler level with a low-propfile syntax. I think it's an improvement overall.
Chris Ryland — Jan 01, 07 2973
Sure wish they'd also tackle blocks, though. There's a parallel case with low-level C stuff like pointers/structs vs higher-level properties. Having both the low-level C control structures (which are inevitable) and higher-level blocks would be killer, and would essentially give us Smalltalk (30 years later ;-) in a viable commercial package.
Scott Stevenson — Jan 01, 07 2974
Preston — Jan 01, 07 2976
Kenneth Ballenegger — Jan 02, 07 2977
Oh, and; unothodox, did you mean, unorthodox?
Michael Stroeck — Jan 02, 07 2979
Personally, I don't think properties are all that hot, but if it makes some people happy, I'm all for them. I prefer the brackets, but that may be due to the crazy highlighting scheme I use, which makes reading code more a matter of color matching than character recognition :-) When I started programming in ObjC, I came to like the Smalltalk-ish brackets because they rather unambigously told this newby programmer that a message was getting sent, but I have to admit that things were getting a bit blurry with the additional de-facto abstration that KVC offers. And I love the garbage collector. Having to manage memory by hand is utterly ridiculous for the vast majority of applications that get written today.
One thing I didn't get this year was the MacHeist controversy. All the developers are adults and fully knew what they were doing. In any case, it raised a ton of money for charity and it means that 16,000 people now potentially use TextMate (and develop bundles for it). If those two things can't make the world a saner place, what can :-) ?
Overall, I think, these last few months were quite a display of strength from the Mac Developer community, and I was happy to watch all of it unfold. Let's hope 2007 will be as interesting as the last year.
P.S.: "remember, new year": Nice touch, Scott :-)
Matt Tavares — Jan 02, 07 2982
I think the problem with Macheist was that people where confused what other people where getting angry about. It wasn't THAT they raised tons of money for charity, it was that they branded the entire week benifiting indie mac when all they did was pay them a VERY low set fee. Sure, 16 000 textmate users are nice, but when Allan gets back from his vacation hes going to have 16 000 people to answer to, most of whom will be totally oblivious to what TextMate even does.
Also, becuase MacHeist requested the developer to implement a special serial activiation exception in there app, there are tons of cracked MacHeist apps circulating the internet.
And all this was supposed to benifit developers...
Wincent Colaiuta — Jan 02, 07 2983
Chris Ryland — Jan 02, 07 2984
Hmm, drawers for styles seems rather "out of it". Everyone else (e.g., the DTP crop of apps) uses floating palettes, and Pages does too, but just not for styles.
Seems more like an attempt to find a usage for the drawer than a useful UI approach.
Jeff — Jan 02, 07 2985
I agree that the jury on HIG issues will have to remain out until Leopard's "top secret" features are out and see if/how they affect the GUI. Core animation in menu items? Makes me fear a bit for the future of bad designs. That said, the Apple guys seem confident the interface is moving along soundly, and they know more of what's coming than I do.
@Scott: ...in an effort to find creative sources of funding, the developers of both Cha-Ching and Disco introduced the unothodox idea of selling beta software at a reduced price.
This has happened for several OSes (BeOS, Rhapsody, Mac OS X Public Beta), and has happened before with Mac software. Some developers have consistently offered discounted early-adopter prices during their public beta periods, but perhaps it got more talked about this year for some reason.
Scott Stevenson — Jan 02, 07 2986
The thing that puzzles me about this is that the people that were supposedly shortchanged weren't the ones that were actually upset. I truly love the fact that there's so much compassion for fellow developers in the Mac community, but I think it's unnecessary to get upset on somebody else's behalf.
Chris robot — Jan 02, 07 2987
Isn't that what Parallels Desktop for Mac did? how come they didn't make the 2006 list?
Good Article BTW.
Jussi — Jan 02, 07 2988
Jose Vazquez — Jan 03, 07 2995
Back then, I was fortunate enough not to use a DOS machine. I had an Amiga 500 (a Timex Sinclair 1000, a VIC-20, and a Commodore-128 before that). And it was an incredible machine. I actually choose it over a Mac (and never regreted it). But as great as the Amiga was, it had a major problem for the average user. User interfaces were absolutely inconsistent. Every one drew their own buttons, and had their own slider, and made their own file dialogs and print dialogs... I was a teen age geek and I could figure it out, but even for me it was a relief when I started using a Mac in college and saw all the file dialogs were pretty much the same. Printing was SO Consistent. (In the amige you had rectangular pixels on the screen yet the dox matrix dots were still squarish)
Any ways the point is that the notion of consistency in user interface was crucial. But guess what... we are a lot closer to achiving wide-spread computer literacy. I mean... most people have now been using computers for years now. A lot of people (most people?) have jobs that depend on computer interaction to some extent. People are a lot more comfortable with computers now than back then. My grand parents never figure out computers, but they never needed them, probably never will (yes, I have to share pictures in paper with them...) Baby boomers I think had the hardest time adapting, but most of the got it, but even they are now retiring. We now have a new generation of user who can figure it out.
Users now a days have been using mice for a while. They have srfed the web, they have a notion of what computers can do. Sure, some are better than others, but the average is a lot higher than just 10 years ago.
So now we can let go of the HIG. At least we can stray away from it a little. Our users are smarter... not only that... developer are more in tune with GUI design now. It is now so easy to slap together a decent GUI. You no longer have to do custom everything. So that means that when you do want to create a custom GUI element that might stray from the HIG, you are (probably) doing so willingly, not out of necessity. You create a custom widget to facilitate some aspect of your software not because you had to reinvent the wheel.
mmalc — Jan 03, 07 3007
I've already provided a response on the subject elsewhere and don't want to repeat it, but to summarise:
(Assuming that the properties feature, and in particular the syntax, follows something akin to that described here.)
The "dot syntax" is just one aspect of the properties feature. If you don't want to use it, continue to use square brackets just as you do now.
The more significant aspect is that you can declare an object's properties (instance variables) in a way that makes information about the property immediately explicit. By looking at a header file you will quickly be able to tell that a particular instance variable is considered a property of an object, that assigned values are copied as opposed to retained, and so on. Even better, you can leave it to the compiler to create the corresponding accessor methods based on the specification you provide in the property declaration.
Properties thus supports a much more declarative style of programming. The intent is made explicit. This is of benefit not just to the originator of the code (who reaps the benefit of a considerable reduction in code size) but also of the consumer who can see immediately the properties that a class has and in turn what attributes and behaviours those properties themselves have.
Matt Tavares — Jan 03, 07 3011
Blocks are bassically functions that are not prototyped but rather declared right in your statement. Example from ruby code:
fruits.each { |fruit| print fruit + "\n" }Code in between the {} is actually its own temporary function. Having blocks in Objc will obsolete using ugly selectors when having to do any call that requires an already defined method (sorting arrays, managing NSAlerts, the list goes on).
Lexical Scopes are more of a rule than an language addition. Lexical Scopes allow you to declare temporary variables within blocks that will be destroyed when the block ends, like an NSAutoreleasePool that unsets objects. To demonstrate this, if you try to access the "fruit" variable after the block, you'll get an error becuase it was declared inside a different scope.
@Scott: The thing that puzzles me about this is that the people that were supposedly shortchanged weren't the ones that were actually upset
Well, people where angry at MacHeist for alot of reasons other than its profit distribution. The fact that they branded it the "Week of Indipendant Developers" (or something similar) kind of ticks me off, since grosly marking down prices benifits everyone except developers. But I agree that the whole event has far to much controversy for something that ultimately did alot of good.
Bret — Jan 03, 07 3016
GCC's done that for a long time.
My code is full of stuff like this (just to pull a contrived example off of the top of my head):
-(void)someFoo:(int)bar
{
while(bar--)
{
int myVar=bar*someOtherFunc();
myIvar+=myVar;
};
};
... and of course, if you try to access myVar outside of the while loop, the compiler complains.
You don't have to have your declarations at the top of the block either:
{
someFoo++;
int someBar=37;
someBaz+=someFoo*someBar;
};
P.s. - yeah, I like semicolons after my closing blocks. It's a style thing. **shrug**