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:

<mailto: wiverson@bedford.symantec.com>.

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

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 Apple doesn’t provide some kind of solution for us, then there is going to be a big delay 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 develop good developer tools. And this means that Apple needs to make it easy for 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.