Jun 94 Dialogue Box
Volume Number: 10
Issue Number: 6
Column Tag: Dialogue Box
Dialogue Box
By Scott T Boyd, Editor
e•World US-Centric?
In the “Newton Developer Conference” article (March 94) you mentioned Apple
claims that “cost issues (with AppleLink) will go away when Apple Online Services
moves away from the GE system to the new in-house Apple System (e•World).” That’s
probably true, unless you live outside the continental U.S. Then you’ll most likely be
hit with a $12 per hour surcharge, something that AppleLink does not have, but some
other on-line services do have, such as America Online. If e•World contains such a
surcharge, it will most likely be boycotted by those who do not live in the continental
U.S., just like AOL is now. Let’s hope Apple makes e•World financially accessible to
everyone.
- Bill Modesitt, Maui Software
[We contacted a spokesperson for e•World. They were unable to provide a
comment about Apple’s plan because this kind of thing is still under discussion, and has
not been decided upon as of this printing - Ed stb]
More intermediate stuff, please
I just want to thank you for the February issue again. The Think C Top Ten was
excellent! Please... more of that. That level of programming was perfect for me and I
bet for a lot of others. With all the crazy new techniques which are evolving, we as
programmers need to see the code and the examples. For me I felt that was about an
intermediate level. I need more intermediate level stuff and so do a lot of others. What
you really need is to get some of that on getting started. :-)
- mAtz, depaul.edu
[Thanks for the thanks. We take feedback like this to heart, and we’ll see what
we can do to bring you more of what you’re asking for - Ed stb]
MCL For Everyone?
You may be well-informed on this already, perhaps better informed than I am.
The internet newsgroup comp.lang.lisp.mcl has, in recent weeks, been filled with
discussion about Apple’s decision not to port Macintosh Common Lisp (MCL) to the
PowerPC, and about Apple’s plans to sell it to a third party. The newsgroup, as a
whole, views this with sadness. But what might be of interest to you and MacTech is
that the newsgroup outcry made it clear that lots of sophisticated and innovative work
is done with MCL. Just to drop one name: it’s the language of choice for one or more
research groups at MIT’s Media Lab.
I subscribe to your magazine, and often benefit from it. I use MCL for
exploratory programming, and I - like many others - find it to be a superb tool. The
binding to the Mac Toolbox is elegant and easy to use, accomplished with a set of CLOS
classes.
I suppose that someone will buy MCL from Apple, and do the PowerPC port, and
that the future of MCL will be reasonably strong, though not as strong as if Apple were
to continue with the product itself.
I wish to propose that MacTech offer regular coverage of this fine programming
tool. Thank you.
-- Paul Shannon, pshannon@nrao.edu
National Radio Astronomy Observatory
Charlottesville, Virginia
[I agree with you that development environments/languages like MCL (and
SmallTalk and Dylan) go under-recognized and under-utilized. Isuspect that most Mac
developers don’t know that a dynamic environment like it exists, and that development
in such an environment is richer, rapid, and completely missing the
compile/link/debug cycle we all know and love so much. If readers want to see more
coverage of tools like MCL, we need to hear from you. Please let us know at
editorial@xplain.com - Ed stb]
More challenge for the programmers?
Well, your March issue’s programmer challenge has finally motivated me to
write to the magazine, because I think the “Bitmap to Text” challenge is a useless,
“toy problem”, and I would like to see these challenges producing more useful
examples of source code.
I also think the parameters of the challenge should be changed to allow C++, C
with object extensions, as well as ANSI C, and to allow usage of MPW (Symantec and
Apple) compilers as well as Symantec’s stand-alone compilers. Since ROM calls are
allowed, the portability of code implied by ANSI C is irrelevant. Possibly routines
written in applescript, hypertalk, mpw scripting language, “awk” (aka “gawk”)
should be allowed also. And don’t forget Pascal and Modula-2.
Since almost all code that I write is owned by my Employer, I will not be able to
submit code to these contests myself. Your provision that “all entries are the
property of MacTech Magazine” would seem to imply exclusive copyright ownership
of the submitted code. I hope you can change that wording to explicitly claim
non-exclusive right to publish, with ownership of copyright retained by the
submitter.
As I stated earlier, I would like to see the programmer challenge show-casing
useful code, which may be larger than a small set of functions. In particular, I desire
tools for writing and understanding programs as well as tools to use in programs.
Here is a quick list of program challenge ideas: [edited for brevity and to keep up
suspense should we use any of these sixteen(!) suggestions - Ed stb]
If you've read this far, thank you.
- c. keith ray, khis.com
[Now to your other points. Ouch! “Toy problem” eh? We’ll see what we can do
to lean a little more in the practical direction.
When it comes to allowing different languages, we have to put some limitations on
things somewhere so Mike, (who’s keeping his day job - now at General Magic) has
time to try out all of the code, profile successful entries, and then put the article
together. He has the tightest deadline of any of our regular writers because we want to
maintain the two month turnaround time between printing the problem and printing
the solution(s). That leaves precious little time for him to add any additional
complexity to handling submissions.
As for the copyright and ownership issue, check out the rules printed with this
month’s challenge. Authors retain ownership, and we get a non-exclusive right to
publish without limitation. We hope you find this helpful.
We truly appreciate this kind of constructive feedback. Please let us know how
we’re doing as we go. - Ed stb]
Comments On Formatting
As a subscriber I would like to thank you and the rest of the staff for the ongoing
improvements in the content of MacTech. Just one suggestion: It would be very nice to
have the source code better formatted (e.g. function headers bold - I'm a Pascal-ist
:-) IMO, C is a hard to read language, without any "eye-catching" structure inherent.
So special formatting of key points of the source code could be a big plus!
- Peter Baral, Medienwerkstatt
[You may have already noticed that some changes have taken place. If you
haven’t, take a look throughout this issue, and see what you think - Ed stb]
Formatting Comments
I'd like to say that the new format of listing comments within code are great: very
readable and very clear
- Victor Lombardi, New York University
[We’d like to make more improvements, but find ourselves limited by how much
we can do by hand. If any of you have tips on how to do more to programmatically apply
styles to source code, we’d love to hear them. Anyone out there tried cross-breeding a
compiler with a word processor? We’re also interested in your suggestions for
additional stylistic things we can do to present code as clearly as possible. How about
it, any suggestions? - Ed stb]
Development Environments
I just received the April issue a few days ago. The quality and variety of articles
in addition to contributions by Apple and Symantec employees is excellent. Over the
past year the magazine has really improved. Coverage of recent and current
technologies is superb. What I believe might be a good idea for an article or a theme
for an issue would be develop environments for PowerPC computers.
MPW and Symantec THINK products used to be the main environments for
developers, with MPW being the more costly and most powerful environment. However
that has changed. Visual programming products in addition to CodeWarrior by
MetroWerks have added a new depth to Macintosh development. With the recent release
of C++ version 7.0, Symantec seems to have reversed the cost advantage that the
THINK products had over MPW. In two major releases, THINK C/C++ has jumped
from a $299 list price to a whopping $499. While this article or issue should not be
a public assault of Symantec's pricing policy, it should provide developers a good
picture of the advantages and disadvantages for each development environment.
One item that should be addressed is not only development for corporate or
commercial developers, but also the independent developer. This is someone who
works another job but develops Macintosh software in the evenings and on weekends.
These are usually the people with the most original software.
However, with the current price of some development environments, it is getting
too costly for these people to stay on top of the new technologies and development
products.
Well, I guess I will get off of my little soapbox now. Thanks for a superb
magazine and keep up the great work.
- Steven Kortze
[Take a look at the Symantec C++ 7.0 language review in this issue. It touches on
a number of the points you make, all without a “public assault”. Each tool has its
advantages - Ed stb]