[net.micro.mac] Info needed on Macintosh Programmer's Workshop

riddle@emory.UUCP (Larry Riddle) (07/18/86)

In the Winter 1986 issue of Wheels for the Mind there is mention
made of a forthcoming Macintosh Programmer's Workshop and
accompanying Workshop languages.  It says the Workshop will
ultimately consist of at least separate products:

1. The Macintosh Programmer's Workshop itself, consisting of a new
assembler, linker, shell/editor, debugger, resource editor, and
various utilities.

2. Macintosh Workshop Pascal, an add-on product to the Workshop
itself, with roots in Lisa Pascal.

3. Macintosh Workshop C, another add-on product to the Workshop.

Product manager is Paul Zemlin.

Does anyone have additional information about this product?  Is it
available from Apple?  Expected release date?  Recommendations from
anyone who has tried it?

I would appreciate any information that might be available.  Thanks.

-- 
Larry Riddle
Emory University
Dept of Math and CS
Atlanta, Ga 30322

{akgua,sb1,gatech,decvax}!emory!riddle   USENET
riddle@emory                      CSNET
riddle.emory@csnet-relay          ARPANET

shebanow@ernie.Berkeley.EDU (Mike Shebanow) (07/21/86)

( are there REALLY line eaters out there? )

MPW (The Macintosh Programmer's Workshop) is currently in beta test. It
should see wider release later this year (September???). As a beta-tester,
I can tell you that it is pretty wonderful. It is easily as powerful and
complete as any development system available on any machine (including UNIX,
all you diehards). About the only thing it really lacks is a source level
debugger.

The C compiler is based on Green Hills C, and generates very good code.
The libraries which Interface to the ROMs all expect C strings, which
I don't particularly like. The standard C library is extremely complete.
Most UNIX text processing utilities will compile without changes (this
includes yacc). The library even includes such rare features as ioctl(),
fcntl(), faccess(), and the entire signal handling library.

The Pascal compiler is also pretty nice. It supports all of the Lisa Pascal
features, which isn't surprising since it is a port of Lisa Pascal. It also
supports Object Pascal, which is used as a base for MacApp. The libraries for
this compiler are very good. My only complaint about this compiler is that it
is SLOW. Code generation is not of the same caliber as the C compiler.

The assembler is also very nice, and it supports a very powerful macro
facility. Haven't used it much, so I cannot really say much about it. It
is fairly quick, however.

The Shell is a combination editor and program execution environment. MPW
programs are special tools, and they can have their output piped, or
redirected. Almost all features of csh are here, in one form or
another, including aliasing, environment variables, and programming
constructs (for, if, loop, etc). The editor is better than MDS edit,
but not quite as nice as QUED. Where it shines, though, is in the
area of search and replace. MPW's regular expression language is as
full featured and powerful as that of the UNIX tools (ex, vi, grep).

Finally, there are two very powerful tools that deal with resources, Rez
and DeRez. Rez is a replacement for RMaker, with a c-like syntax and the
ability to define your own resource types. DeRez can take your types and
dissasemble a resource file into a file usable by Rez. These two tools are
incredibly powerful when combined with the Resource Editor.

The one major negative thing about MPW that I can say is that it is a
bit of a resources hog. It chews an incredible amount of disk space
(although Apple claims it can be used on a dual 800K floppy system,
I wouldn't want to try it), and it also requires large amounts of
memory. On my MacPlus at work, its fine, but my 512K at home runs out
of memory far too often. Unfortunately, running out of memory usually
crashes the machine as well.

All in all though, it is a new standard in development environments. The
power and flexibility are unmatched by any system I have ever used. When
it does come out, I expect it to become the new standard.

Andrew Shebanow

saunders@batcomputer.TN.CORNELL.EDU (kevin eric saunders) (07/25/86)

In article <14933@ucbvax.BERKELEY.EDU> shebanow@ernie.Berkeley.EDU.UUCP (Mike Shebanow) writes:

>MPW (The Macintosh Programmer's Workshop) is currently in beta test. 
> . . . It is easily as powerful and
>complete as any development system available on any machine (including UNIX,
>all you diehards). 

Ummmm.  All without multitasking, eh?

My preference is that development software should run under a REAL 
operating system.  Something standard and portable, like, say, 
uhhhh..... UNIX.

"Accept no substitutes,"
kev

-- 
kevin eric saunders

ARPA: kevin@lasspvax   or   kevin%lasspvax.tn.gvax.edu@cu-arpa
UUCP: {ihnp4, allegra,...}!gvax!lasspvax!kevin

chuq@sun.UUCP (07/27/86)

> In article <14933@ucbvax.BERKELEY.EDU> shebanow@ernie.Berkeley.EDU.UUCP (Mike Shebanow) writes:
> 
> >MPW (The Macintosh Programmer's Workshop) is currently in beta test. 
> > . . . It is easily as powerful and
> >complete as any development system available on any machine (including UNIX,
> >all you diehards). 
> 
> Ummmm.  All without multitasking, eh?
> 
> My preference is that development software should run under a REAL 
> operating system.  Something standard and portable, like, say, 
> uhhhh..... UNIX.

That is your Unix tunnel vision talking, not common sense.  Having
programmed a Mac with a Unix-like development environment (Mac C), all I can
say is that I thought it was wonderful until I met up with LightSpeed C.
What works for Unix may NOT work for other machines (surprise, surprise).
All I can say is one of these days I plan on writing LSC for my Sun -- I
only with I had as good a development environment on my Unix machine as I
did on my mac.

chuq (there are none so blind as those who will not see, and Unix zealots
	are the worst of the bunch)
-- 
Chuq Von Rospach	chuq%plaid@sun.COM	 CompuServe: 73317,635
		{decwrl,hplabs,ihnp4,seismo}!sun!plaid!chuq

	O how they cling and wrangle, some who claim
	Of Brahamana and recluse the honoured name!
	For, quarrelling, each to his view they claim,
	Such folk see only one side of a thing.
		-- Buddha -- The Elephant and the Blind Men

shebanow@ernie.Berkeley.EDU (Mike Shebanow) (07/27/86)

(beware the wrath of the line eater!)

As far as multitasking goes, I agree that it would be nice to have, but I
don't think it is absolutely necessary. In practice, even experienced
UNIX hacks use multitasking very little: mostly for print spooling & running
make. Apple got around the make problem rather nicely, so all that is missing
is print spooling and the ability to run background tasks. Given the
architecture of MPW and the environment, it is quite possible that a version
of MPW which supports multitasking will show up when the oft-rumored 020 macs
become available. Until then, I can live without multitasking...

Regarding Chuq's comments on LightSpeed, I halfway agree. In practice, I spend
more time with LightSpeed than I do with MPW. For my purposes (writing
simple Mac applications for fun), LightSpeed is more than adequate. But
if I ever start doing Mac stuff full time, I will probably use MPW. The reason?
LightSpeedC, despite its speed and power, lacks two key things: flexibility
and extensibility.

LightSpeedC is great if you are writing a simple, standard application or desk
accessory that doesn't have speed or size constraints. If you need to use 
assembly language, LightSpeedC is very awkward (Running MDS, then converting,
then removing the old library from your project and adding it again). And
LightSpeed lacks support for the 128K ROMs and HFS, which makes it difficult
to write sophisticated programs.

But what really hurts is the lack of extensibility. If I have a repetitive
task that I need to run, like a resource compiler or editor, LightSpeed makes
life very difficult. I can transfer into an application, run it, get dumped
into the Finder and then run LightSpeed again, but this gets tedious after
four or five repetitions. Or I can write my own tool, keep it as a project,
and run it whenever necessary by closing my current project, opening my tool's
project, running the tool, quitting, close the tool's project, and reopen my
application's project. (I get annoyed just typing that, never mind doing it).

There will never be an SCCS for LightSpeedC, or a lint, or an awk, or whatever,
because LightSpeed makes it impossible to use these tools. MPW, on the other
hand, makes it EASY to write (or port) these tools. I have written many tools
for MPW already, and I expect that all of the tools I mentioned above will
become available for MPW soon after its release (even if I have to write them
myself!). A friend of mine has already ported awk.

I understand that there will be a new version of LightSpeed available soon,
which will have inline assembly and support for the new ROMs. At that point,
LightSpeedC will have answered my complaints about flexibility. But the
extensibilty question will remain unanswered. I really like LightSpeed,
but I do have my doubts. If they ever put it out with a builtin source level
debugger, I will probably forget MPW ever existed and "make do" with an
unexstensible environment. But until then, I think that MPW is a better
environment for the professional Mac programmer.

Andrew Shebanow
mouth for hire

wca@ut-sally.UUCP (William Anderson) (07/28/86)

In article <15027@ucbvax.BERKELEY.EDU>, shebanow@ernie.Berkeley.EDU (Mike Shebanow) writes:
> As far as multitasking goes, I agree that it would be nice to have, but I
> don't think it is absolutely necessary. In practice, even experienced
> UNIX hacks use multitasking very little: mostly for print spooling & running
> ---------------------------------------

(emphasis is mine)

Ah, c'mon!  We use multitasking all the time.  Everytime I type:

% ps aux | grep fubar

I take advantage of multitasking.  In particular, _pipes_ are used by all
of the "UNIX hacks" I know.  No flames about the U word showing up in
net.micro.mac, please.

Willie Anderson - University of Texas Computation Center

UNIX is a registered trademark of AT&T Information Systems (yawn).

shebanow@ernie.Berkeley.EDU (Mike Shebanow) (07/29/86)

(beware the line eater)

RE: UNIX, mulitasking, and pipes

Allow me to clarify my point: I do realize that pipes are implemented in
UNIX as a connection between processes, but that is not, strictly speaking,
at all necessary. MPW does pipes, and so does MSDOS, but neither of these 
environments (if you call MSDOS an environment :-) ) use multitasking to do it.

So my point still stands, even if it is quivering a bit.

Andrew Shebanow