LETTERS

NURB CURVES TYPO
I'm an M.S. student in the Department of Industrial Engineering at Bogazici University, Istanbul, Turkey. My thesis is about pattern recognition using implicit polynomials in CAD applications. While I was surfing the Internet, I found the article "NURB Curves: A Guide for the Uninitiated" in develop Issue 25 and read it. It's a very good resource for those (like me) with minimal knowledge of NURB curves and representations, and I liked it a lot.

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 sometimes 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.

TIME-SAVING TIPS
I really enjoyed Bob 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. *