Messed up Perl

[Scott Haneda]

On Oct 4, 2010, at 8:40 PM, Hal Vaughan <hal at halblog.com> wrote:

>  Here's an example: Tonight is Monday, so I'll put the garbage on the curb along with my recycling because they pick it up on Tuesday.  That's the default and the expected behavior.  Why should I check the city's website on that every Monday when they have stated that's how they work previously?  There's no reason I'd check every week to see if they're still picking up trash in my area on Tuesday.

This doesn't quite work though.  Everyone *learned* what day trash day is, and acts accordingly. That is what is happening here. 

The difference is, you just moved into a new home, the trash day is different from your previous home. You should call and ask or check the city website. 

That's fairly analogous to exactly what's going on here. 

When I first came to MacPorts I ran into a few issues wrapping my head around the p5's. Every port or package manager deals with them in their own special way. I've grown used to it and understand why things are the way they are. 

Nothing is permanent and banned from change, it just takes time and resources, something always running short handed on FOSS projects. 

I can say, the method in place now is the best for the current and new joining user base. You are the first to bring this issue to the list in some time. 

I recall PATH issues occurring much more often a while back, presumably before the prepending of the MacPorts prefix was added to the PATH methodology. 

Having a selector seems simple enough a contribution. However, I'm not sure that added decision complexity is worth it as the majority, old and new, understand the current approach. 

Shooting for majority understanding, at the expense of the minority, especially when the minority is able to easily understand the complexity of this method, is not a change I would like to see. It will burden the current developers from core fixes while dealing with a support issue that was never a problem before. 

I think the thing to take away here is yes, there may be a different method. This method may be technically better for you. It may even be technically better in general. That doesn't mean it is the right decision for all. That depends on the user base and nature of the software. 

A great example is to read the forum post from the DropBox founder about the removal of a custom location for your Public directory feature. 1% of advanced users were upset. 100% of an AB testing group failed to comprehend or need the feature. In worst case scenarios data was lost; no amount if verbiage, alerts, docs, or otherwise could solve this. 

The decision to cater to the masses at the expense of the minority was the right call in my opinion. I see this as the same thing. 
-- 
Scott * If you contact me off list replace talklists@ with scott@ *