Apr 96 Dialog Box
Volume Number: 12
Issue Number: 4
Column Tag: Dialog Box
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.
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