Dialog Box

By Matt Neuburg, letters@mactech.com

Pascal Forever

The following exchange is reprinted with permission from TidBITS #305 (27-Nov-95 - email info@tidbits.com for more information). In that issue, Adam Engst interviews Peter N Lewis, author of Anarchie, FTPd, and other well-known shareware tools. We thought our readers might be interested in this excerpt, where Peter speaks about languages:

Adam: You and Quinn are known for being major Pascal supporters in a development world that has largely gone over to C and C++. You even had anti-C t-shirts at the last few World-Wide Developer’s Conferences. Without getting too technical, why do you continue to stick with Pascal, and does that cause problems at times?

Peter: The normal C argument goes like this: “Everyone else is using C, so therefore it must be good.” Every Mac user should recognize that statement in a slightly different form, “Everyone else is using PCs, so therefore they must be good.”

Basically, I continue to use Pascal because I’m more productive in it. I consider using Pascal to be a strategic advantage, doubly so when compared to C++. I’ve been reading a C++ book recently (know thine enemy), and every time I turn the page I see new ways to make tiny errors that are catastrophic and impossible to debug. I’m amazed that anyone can produce a working C++ program.

However, programming in Pascal does cause occasional problems. The Apple interfaces tend to be quite broken. I wanted to try out QuickDraw GX, and it took a year of new versions before they finally got one that I could hack to work with Pascal. By then I’d given up on GX. In some ways this is actually a good thing for me: I have way too many projects and not enough time to do them all, so not being able to work with GX or OpenDoc is helpful for limiting my options.

Please Don’t Kill The Umpire, He Is Doing His Best

There has been, of late, mild criticism of the premises of the programmer’s challenge, and now (Don Winston in November’s Dialog Box) of the style.

I am only an amateur on the Mac, yet I find your magazine stimulating, thought-provoking and - hell, that’s enough praise for the moment. My views cannot in this case reflect those of the majority of your readers, but may correspond to those of a significant minority.

The demands have been: (1) to play down optimisation, arguing that hardware will catch up (the Microsoft approach), and now (2) the rejection of the use of “goto” in a winning answer; plus (3) that the programmer’s challenge become more practical or open itself up to more languages.

That MacTech published these comments could mean two things (and most probably more): (1) it is an open forum for constructive criticism, including criticism of itself; (2) that it is preparing the minds of readers for changes in certain items.

And it is this second possibility that worries me the most.

The PC rules demand “correctness, speed, size and elegance (in that order of importance)”. While the first is obvious, the others are essential to the spirit of your magazine. Speed and size implies that you are looking at real joes working in front of real machines - we can’t all just run out and buy PowerPC dream machines. Each time I have to launch W*rd 6 on our 660AV, I wince, scream and plead - I don’t want all software evolving into this.

Elegance is subjective; it is in part what Don Winston is protesting about. He complains that “old notions of ‘efficiency’ are passé”. No, the Programmer’s Challenge is a mindfest that makes one jump up and shout, “Yes, of course, it’s so obvious now!” It is one of those nuggets that I, as an amateur who would never consider entering the challenge, cherish. And to change these subtle criteria would diminish your magazine as a whole.

Increasing the number of language platforms for the challenge has already been argued as impractical by the column’s flame-keeper in order for him to respect deadlines. Fine. Although I would be interested in the possibility to occasionally study just the winning algorithms, perhaps in pseudo code, rather than their implementations in a specific language, the crux of the challenge lies in the participants feeling/knowing the limits of the language, and then finding the best solution.

That particular readers are not happy with specific subjects chosen for the challenge will always exist, but if you try to render it more “practical” for one group, another will protest that it is still further from their sphere of interest, and when one looks back over a year’s challenges it is a mighty varied lot: a little for everyone, and a lot for most.

Keep up the good work.

jonathan munn
format@dialup.francenet.fr

Bob Boonstra Replies...

Jonathan,

Rest assured that we have no intention of changing the primary focus of the Programmer’s Challenge from efficiency to anything else.

The letter from Don Winston makes the valid point that improvements in technology have allowed software professionals to give other factors (usability, portability, encapsulation, reliability, etc.) greater consideration, at the expense of efficiency. But, as you point out, one need only look at the performance of some popular office automation applications to see that vendors are still able to generate sluggish code, despite the improvements in hardware. In fact, I believe that the demands on software will always exceed what the technology can support. The Challenge is intended to address techniques for those time-critical functions. It doesn’t pretend to be a balanced approach to teaching every aspect of software development. I think efficiency is still relevant - less universally so, but still relevant.

It is gratifying to hear that you find most of the subjects chosen for the Challenge to be interesting. We strive to find a variety of problems that are interesting to readers, interesting to participants, sometimes useful, solvable in the limited time available, and scoreable in even less time. Suggestions from readers are always welcome.

Thank you for your comments, and remember that anyone - including a self-described amateur - is invited to enter the Programmer’s Challenge.

Bob Boonstra
bob_boonstra@mactech.com

Hooray for the Umpire, the Players, and Everyone

I just want to commend Bob on such an interesting challenge. [But which one is he talking about? Probably January’s “Sliding Tiles”, we figure. - man] This is one of the few that I didn’t even know how to solve, let alone how to solve it efficiently. Hats off to anyone who breaks the brute-force barrier and applies some finesse to this one.

The test code was excellent and invaluable.

While I’m at it I’d also like to congratulate Eric Lengyel for such a clean solution to the Enclosing Bounds problem. I started working on it myself, but all of the various conditions (odd boundaries, different pixel sizes) made a simple-sounding problem too complex for the time I had. Eric, however, cut through the complexity and delivered some excellent code.

Xan Gregg