Sep 95 Dialog Box
- Jan 95 Dialog Box
- Feb 95 Dialog Box
- Mar 95 Dialog Box
- Apr 95 Dialog Box
- May 95 Dialog Box
- Jun 95 Dialog Box
- Jul 95 Dialog Box
- Aug 95 Dialog Box
- Nov 95 Dialog Box
Volume Number: 11
Issue Number: 9
Column Tag: Dialog Box
Dialog Box 
By Neil Ticktin, Editor-in-Chief/Publisher
Symantec Responds
Dear MacTech readers,
I would like to take a moment to address some of the concerns which have been
expressed lately about Symantec.
Guy Nicholas, in the July issue, asked about supporting the standard SYM format
for debugging. You can use the external linker to produce SYM files now, but we
acknowledge that this is an incomplete solution. We expect to support the standard
SYM format by Symantec Developers Advantage 5, available January, 1996.
Fred Johnson wondered about Pascal. There is no further engineering effort
planned for THINK Pascal. Symantec does not wish to abandon it’s Pascal customers,
and we are working with Language Systems to provide a drop-in translator by January
1996. This strategy allows you to mix Pascal and C in the same project. Please
contact me or Language Systems (703/ 478-0181) for more information.
If there are any other questions you have about Symantec, I invite you to send me
email at:
Yours,
Will Iverson
Symantec Macintosh DevTools
Evangelist & Ombudsman
Go C & C++!
I found your July ‘Dialog Box’ particularly entertaining, in part because it so
well illustrates the myth about C, which you repeated in the words, “There are
definite advantages to C or C++ when you want to get closer to the machine.” Unless
you are programming for the PDP-11 (for which C is the quintessential high-level
assembler) or a PDP-11-like computer (the 68K comes moderately close; the
PowerPC does not), this is just plain not true. But like the Mazda ads, “it feels good,”
regardless of the facts.
The reason you have a Symantec Top 10 was clearly spelled out in the two letters:
it’s necessary. It’s less needed for Metrowerks, and not at all for Think Pascal.
Anybody reading the column without deeply tinted rose-colored glasses quickly sees
that it’s mostly about recovering from language and implementation deficiencies. It
also, no doubt, helps the MacTech bottom line by encouraging uneducated programmers
to believe that this is the language of choice, so they must continually come back to the
fountain for more help. The column may even perform a valuable public service by
helping smart programmers avoid the tar-pit before getting stuck in it.
Personally, I think C and C++ are wonderful languages, and I hope all my
competitors make full use of them :-)
- Tom Pittman
[Let us be absolutely clear here - this is a public service announcement -
program in Pascal, not C or C++! - Ed. nst]
From a Thread Initiated On Semper.fi
[name deleted] wrote:
>For most of us, *mentioning* Sys 6 in the same breath as
>”Macintosh development” is bizarre.
Again, the issue I raised wasn’t about System 6.x in particular; it was about how
Apple supports developers faced with the dilemma of adopting new technologies and yet
supporting their existing customers. Maybe it’s easy to ignore System 6.x guys now
that we are five years into System 7, but this is a general problem, one that’s only
going to get worse.
For yet another example, take System 8. Preemptive multi-threading is going to
become more useful for some tasks in System 8, and yet System 8 (right now) isn’t
slated to work on 68K Macs. Certainly, 68K Macs aren’t where the “decisive action”
is, and they will be even less so in a year, yet I can’t imagine that most companies will
be willing to abandon 7.x support. Especially since it will be ’98 or ’99 before the
installed base of Power Macs equals that of 68Ks.
So the question is, how do I write an app that takes advantage of preemptive
threading in System 8, and yet still works fine for most of my customers, and do this
with a minimum of headaches? One partial solution is for Apple to provide System 8
for 68K Macs. Another is for Apple to establish good guidelines and sample code
showing how to use preemptively multithreaded code in a
non-preemptively-multithreaded OS. Maybe it’s possible, maybe it’s not. But if
in the arrival of preemptively multithreaded software, a delay Apple can’t afford.
The rate of adoption of new technology does have a great impact on the outcome of
the OS war. This means Apple needs to create good APIs. This means Apple needs to
developers to support existing customers during the multi-year transition. And if
Apple doesn’t provide System 8 support for 68K Macs, there never will be a complete
transition; we’ll always have some 15 million 68K/System 7 Macs out there that most
developers won’t be able to ignore.
As you point out, good Mac people are scarce. We all have limited resources.
That is exactly why Apple should be the one to put engineers on this problem. It is far
better that Apple deal with the issue of finding ways for developers to support new
technologies and old users, than to have hundreds or thousands of us have to deal with it
individually. That’s a huge waste of Macintosh talent, and will be enough of a pain that
a lot of companies just won’t adopt the new technologies.
One more point. While we’re fighting the OS war with new technologies and new
ideas, let’s not be outflanked. One of the traditional benefits of the Macintosh is that
they are long-lived computers. Whereas PCs might have an effective lifetime of a few
years, a lot of eight- and nine-year-old Mac Pluses and SEs are still in use. And,
perhaps until recently, those old computers could still run a lot of modern software.
As President of a User Group, I’ve heard a lot of users mark this as a benefit of
owning a Mac. I’d hate to see us lose that benefit. I don’t think Apple and developers
need to bend over backward to support System 6.x, but I also know that a lot of
software out there can be written to support System 6.x with relative ease. Likewise,
I guarantee a lot of people who bought (or are still buying 68K Macs) are discouraged
to hear that Apple won’t be bringing System 8, with all its great features, to their
brand-new computer.
A one-year-old computer and already unsupported? In my opinion, that is not
the Macintosh way.
Nathan Tennies
Bootstrap Enterprises Inc
P.S. No, my company isn’t trying to corner the market on System 6.x users.
However, I consider supporting these users, as much as possible, a mark of good
programming just like fast execution speed and small code size. The dark side of the
force is Microsoft, which often doesn’t seem to care about fast execution speed, small
code size, or supporting users with older computers/operating systems (like those
ancient, obsolete 68030 users).
Don’t give in to it.
Dylan Doesn’t Stand a Chance
I’ve just read the MacTech August issue’s Dylan article and have an observation
to make: Apple’s Dylan has zero chance of success in the commercial programming
marketplace. The reasons why this is true have absolutely nothing to do with the
nature of dynamic programming or of Dylan itself.
First off, please understand that I am a fervent supporter of dynamic languages,
and support the Dylan team in much of their design goals. Dynamic languages solve
many problems and offer new solutions not allowed by the static languages in common
use today. The leading language in object oriented programming, C++, not only suffers
from its static nature but also from poor syntax design. C++ code and class
hierarchies are as a result obtuse and brittle over the life of an application. Dylan
solves many of these problems.
The difficulties stem not so much from the nature of Dylan, but rather from the
nature of Apple. It is unrealistic for Apple to propose and expect success from a
proprietary programming language of their own design. Apple’s track record in
development environments and languages is very poor. Developers such as myself
who’ve been with the Macintosh since the early days, have been rewarded by Apple
with the destruction of their source code base.
Early Macintosh code was developed almost exclusively in Pascal, but with the
advent of the PowerPC Macintoshes Pascal was abandoned by Apple with no viable
migration path provided. This lack of support of a company’s software development
environment is outrageous and unheard of amongst major hardware and software OS
companies. Those of us with the will and desire to migrate to PowerPC are forced into
converting our source code into C, a process that consumes much of a company’s
development resources and results in a source code base that looks like it was written
by Martians.
Now Apple trots out Dylan and asks the developer community to use it. I, for one,
will not. Even if I have to jump through arcane hoops, I will use C++. At least I’ll be
sure of the availability in ten years of development environments to build my code.
Jim Gagnon
Co-founder
Abacus Concepts, Inc.