But in Figure 20 there's a mistake, I think. Control point B (2) has coordinates {2, 0,
0}, but I believe the last index (w) should be 1. Is that right?
-- Ugur Murat Erdem
Yes, in fact you've found a typographical error in the figure you mention: B (2) should
be {2, 0, 1}. We had a very good editor and several reviewers, but none of them caught
this. I hope it doesn't mislead anyone too much. Thanks for pointing it out.
-- Philip Schneider
TECHNICAL Q&A: WHERE?
In the Issue 25 Macintosh Q&A, you explain a new method for embedding GX pictures
into QuickDraw PICT files. It says that we can find sample code in the Macintosh
Technical Q&A "Embedding a GX Picture into a PICT" (GX 07). Unfortunately, I haven't
found this file on any developer CD I have. Could you please help me locate this
information?
-- Michel Renon
That Q&A can be found on the Web at
http://dev.info.apple.com/techqa/qdgx/gx07.html. In general, the Web site
http://dev.info.apple.com/techqa/Main.html has the latest and greatest Macintosh
Technical Q&As. They some- times take a while to find their way to the CDs, and that
was the case here. That Q&A is now available on the CDs as well. Sorry for any
inconvenience.
-- Dave Johnson
TIME-SAVING TIPS
I really enjoyed Bo3b Johnson's Veteran Neophyte column in Issue 25 about ways to
avoid wasting time. After programming the Mac for 10 years, I'm finally learning
many of the things he talked about. It' s funny looking back at all the mistakes I've
made while thinking I was so smart.
I worked at Berkeley Systems on After Dark. One of the first things I did was write
the Warp (or starfield) screen saver. I came up with a really cool assembly routine
that, given an x and y, would draw the pixel on any monitor at any bit depth. It was a
complicated routine (remember, I'm very smart) that used lots of shifts, multiplies,
and divides. Even though I commented it, I still had to sit down and work through it
each time I needed to make a change. Finally a coworker asked why I didn't just write a
separate routine for each bit depth. I scoffed and said my routine was really cool.
Needless to say, I rewrote it into separate routines; it was really easy, and is easy to
maintain and change as well.
These days, instead of banging my head trying to come up with a "smart" way to do
things, I just code in the most straightforward way I know how. I'm finding that I have
better things to do than screw around with a triply linked list that looked good in Dr.
Dobbs but isn't really appropriate for my problem. I hate reliance on C-isms that
aren't obvious: if you have to pull out the ANSI C book to figure it out, it isn't good
code.
By the way, another good book is The Psychology of Computer Programming by Gerald
M. Weinberg. It was written in 1971 but has some very interesting views on
programming and programmers.
-- Bruce Burkhalter
I'm not a windsurfer, but I am a Mac developer, so I read Bo3b Johnson's column in
Issue 25 with great interest. My boss (Markus Fest, the programmer of Toast
CD-ROM Pro) told me it was a PflichtlektÜre (something you just gotta read). He was
right.
There's a book that should have been in your Recommended Reading section: Code
Complete by Steve McConnell (Microsoft Press, 1993). It's worth checking out.
Enjoy!
-- Florian Dejako
It's amusing to look back and see how we learned the things we did, and how they' ve
helped or hindered us. That introspection is actually what spawned the column: I
realized that maybe others could avoid those mistakes if they read about them in
advance.
To this day I run into arguments about using the full "power" of C/C++. I hate to see
people writing code just to use some feature of C++ like operator overloading. If they
can redirect that creative energy to figuring out a better algorithm, it's a total win.
I think restrictions can actually be liberating, by freeing you from having to think
about everything. If the brace style in code were enforced, how many hours of wasted
brain time would we get back? Having the meaningless stuff like brace style fixed in
stone makes it easier to apply cleverness to the things that matter, like the quality of
the software.
And Florian: thanks. I've never been called a PflichtlektÜre before, but I kinda like it.
-- Bo3b Johnson
TELL US WHAT YOU THINK (PLEASE) We welcome your letters to the editor, especially
regarding articles published in develop. Write to Caroline Rose at crose@apple.com
or, if technical develop-related questions, to Dave Johnson at dkj@apple.com. All
letters should include your name and company name as well as your address and phone
number. Letters may be excerpted or edited for clarity (or to make them say what we
wish they did). Address subscription- related queries to
order.adc@applelink.apple.com. *