Re: Why has the Metrowerks sign been taken down?

In article <1120907079.643393.113990@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
larry@xxxxxxxxxx wrote:

> > Of course, had they done this, then:
> >
> > a) some other feature would not have been released
> > b) other bugs couldn't have been fixed
>
> IB has so many bugs I doubt one or two more would make much difference.
> LOL

But you'd be complaining about those instead...

>
> > c) the development tool chain would have slipped, resulting in
> > slipping of the OS release.
>
> - You're basing this on the assumption that this feature would take one
> engineer 30 days to implement, but that's clearly unrealistic. IB can
> already import a menu bar and its menus, so the code is already there
> to read 'MENU' resources and convert them into menus in a nib. I
> wouldn't be a bit surprised if a good engineer could restructure the
> existing code and have a menu importing feature working in less than a
> day. Thirty days is completely out of the ballpark as an estimate for
> this task.

I didn't come up with the "thirty man-days to fix it" strawman, I'm just
playing along with this ridiculous "think how many lives could be saved
if you just made it 10 seconds faster" argument.


> > So for (a), instead of this one problem (which, personally, has cost
> > basically only a hour or two at best, since most things have been
> > created from scratch rather than dragged over from existing OS 9
> > codebases),
>
> There are too many of these kinds of baseless assumptions used to
> justify not addressing issues like this. You have no evidence to
> support your "only a hour or two at best" claim and I have no reason to
> believe it.

Actually, I have every evidence that it personally cost me only an hour
or two at best - I've only needed to convert a small handful of OS 9
rsrc based MENUs to NIBs. So I have just as much evidence as you
claiming that it took "3 days" to convert the File Buddy MENUs. I was
only speaking to the one data point that I had personally experienced.


> Another assumption is that there are very few applications left that
> haven't had their menus converted to nibs yet.

Another thing I've never claimed.

> > there would be others that potentially more people would
> > have been impacted with, many of which would have cost far more than 970
> > man-days.
>
> Like what? What need is more common that converting menus if you're
> porting an application to nibs?

Converting DITLs?

> Sure, there are other areas where IB
> could stand improvement, but Apple should have provided robust
> importing of dialogs and menus in the early releases and then attacked
> other things that will be useful longer term. Instead they just let it
> stagnate. I didn't have what I needed and you don't have what you want.
> There weren't as many tradeoffs as you seem to imply. I'd be more
> receptive to your position if IB were at least robust and had more
> features I'll be able to use in future projects.

Perhaps if you'd try Cocoa, you'd find IB far more robust and useful for
feature projects. IB is first and foremost an editor for Cocoa NIBs -
adding Carbon NIB support was secondary and bolted on. It's fairly easy
to imagine the meeting where they decided on having Carbon NIBs:

"What can we use to edit them?"
"We could write a Carbon IB from scratch, or graft it into IB"
"How long would the 'from scratch' take?"
"A long time, but it would provide the best answer"
"How long would the 'graft' take?"
"Much less time, but it would have some very rough edges"
"We need to ship in December - graft, and we'll try to grind down the
edges when we get time"

Had you been in that spot, you would have done the same thing.

> >
> > For (b) some feature wouldn't have been released, requiring everybody
> > who wanted something like that to spend time re-inventing the wheel.
> > Again, far more man days for everybody to reinvent, say, some scheme to
> > have internationalized way of adding help tags to controls (just picking
> > some feature of IB that may have been cut to make room for that fix).
>
> Well, the point is that Apple should have loosened the purse strings,
> hired another engineer, and done both.

This, of course, assumes they can find qualified engineers.

Not to mention that "hire an engineer" isn't the panacea that it sounds
- after all, 9 women can't make a baby in 1 month.

>
> > This assumes that they have X "extra" man-hours to spare to work on
> > them. It's the classic "bugs, features, schedule - pick two" dilemma.
>
> Yeah, well given how many features it lacks and how many bugs it has,
> I'd say they picked one: schedule.

"Schedule" certainly is at the top of the list - it's the nature of the
marketplace. And by choosing that as the priority, you're left
shuffling the other two.

>
> > No matter what choices anybody makes in this trade off, there are going
> > to be people unhappy about their choices. Personally, I'd rather see
> > those 30 man days being spent to make it possible to directly create a
> > toolbar in IB instead of having to do most of it in code - I'm guessing
> > that that has cost the developer community far more time...
>
> Maybe, maybe not. But toolbars weren't even introduced until 10.2, so
> not importing menus from the beginning couldn't have been traded for
> toolbars anyway. ;-)

But at this point, more people add toolbar support to apps than convert
rsrc MENUs.

>
> Look, you can make excuses for Apple all day long, but they're just
> excuses. Apple should have done better. Everyone with his eyes open
> knows this.

Hind sight is always 20-20. You can second guess everything they've
done, and guess what - at the end of the day, it doesn't matter.

> Apple isn't some two-bit company run by two guys in a
> garage anymore. It's a major multi-billion dollar corporation that's
> counting on people's cult-like loyalty to give it slack it doesn't
> deserve. They shouldn't be expected to deliver a 10.x.0 version of Mac
> OS X that's robust. People were happy to pay $129 for the second public
> beta, aka Mac OS X 10.0. Apple shouldn't be expected to provide solid
> documentation. It's okay if IB lacked useful functionality and was
> loaded with bugs after almost five years. It's fine that gcc is a much
> slower at compiling than CW. We're all one big happy family and iPods
> are selling like hotcakes. That's all that really matters, right?

If you have better solutions, write a better mousetrap - I'm sure the
marketplace will recognize it and you'll have all the fame and fortune
you deserve.
.

Relevant Pages

  • Re: Why has the Metrowerks sign been taken down?
    ... IB has so many bugs I doubt one or two more would make much difference. ... - You're basing this on the assumption that this feature would take one ... to read 'MENU' resources and convert them into menus in a nib. ... Well, the point is that Apple should have loosened the purse strings, ...
    (comp.sys.mac.programmer.codewarrior)
  • Re: Who wants to maintain KR list for stable releases?
    ... Tracking feature or implementation suggestions wouldn't make sense. ... write what they think the kernel should do but who never write a single ... 'My' Linux kernel subsystem has a long virtual TODO list, with bugs, ...
    (Linux-Kernel)
  • Re: starting with 2.7
    ... > interfaces are probably ready to go regardless. ... because you don't see any use to that particular feature that you can guarantee ... >> justify it anymore. ... It's possible that 2.6 has fewer of those known bugs, ...
    (Linux-Kernel)
  • Re: Why has the Metrowerks sign been taken down?
    ... >> I was trying to guess how many menus File Buddy has. ... Let's say it did take 2-3 days to covert those menus. ... Apple could have invested, let's err on the side against Larry's, ... For some feature wouldn't have been released, ...
    (comp.sys.mac.programmer.codewarrior)
  • Re: [opensuse] curl error-connection time out
    ... I think this would be a great feature and would greatly help the ... downloading. ... When i changed the URL for my repositories back to ... Note that this is to be regarded as a prototype and there may be bugs - ...
    (SuSE)