On Aug 24, 2011, at 12:06 PM, Ryan Schmidt wrote:

> And I think we all know that Apple prides itself on producing software that 
> has *few* options. Apple does *not* add an option to iTunes or iOS just 
> because one power user thinks it might be fun to play with. Apple provides 
> default functionality that is correct for maybe 80% of users, and a few 
> carefully-selected options for maybe another 10% of users, and tells the 
> remaining 10% tough beans. And this is great because what happens otherwise 
> is that inexperienced users get overwhelmed by settings and choices they 
> don't understand, or they select options without understanding their 
> consequences.

Hi Ryan,

I cannot disagree with your overall sentiment.  Adding another option for "use 
system bits" would almost certainly create a combinatorial explosion of 
different user scenarios and make debugging and "tech support" for MacPorts 
even more problematic than it is now.

I guess, then, that this is really an appeal to hide the details since you can 
only get away with doing things "the Apple way" if you also hide the majority 
of the working parts from the end-user.  In MacPorts' case, this would 
essentially mean having a GUI tool which allowed one to click away on various 
packages to one's hearts content and then click "Go!" and have all the right 
deps installed transparently and with a minimum of download and CPU resources 
consumed.

Until you have that, however, then the "few options" defense just doesn't work 
for you because that's not what MP provides, or anything even reasonably close 
right now.  Right now, it's a build tool created for experts by experts (and 
sorry, but anyone who knows how to open Terminal.app and type shit is an 
"expert" by the Apple definition).  The experts see all of the machinations and 
the extra bits being installed and then they go blog about how Homebrew is the 
future of package management for Mac OS X. :-)

And before anyone says it, yes, I know that Apple is currently assisting the 
project in creating just that sort of binary package delivery infrastructure, 
and I really hope the effort succeeds since god only knows how much even I am 
tired of listening to myself harp on that particular topic, I'm just saying 
that MacPorts is currently at that "awkward age" where it's neither fish nor 
fowl, and that means that you really can't wrap yourselves in the clothing of 
"ease of use" just yet.  Keep that argument warm for when it's actually 
applicable though, yes, indeed. ;-)

- Jordan

_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Reply via email to