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]
