Path: utzoo!utgpu!attcan!uunet!pyrdc!pyrnj!rutgers!att!poseidon!psrc
From: psrc@poseidon.ATT.COM (Paul S. R. Chisholm)
Newsgroups: comp.software-eng
Subject: Re: Cynic's Guide to SE #6: Forthcoming Revolt
Summary: big audience + standard environment -> good tools for PCs
Message-ID: <539@poseidon.ATT.COM>
Date: 17 Oct 88 17:24:51 GMT
References: <3969@enea.se>
Organization: AT&T Bell Laboratories
Lines: 64

In article <3969@enea.se>, sommar@enea.se (Erland Sommarskog) writes:
> But for program development? Can these small machines give the 
> same support for large-scale projects? I saw a demonstration of
> the debugger for Turbo-Pascal, and I wasn't too impressed. Nice 
> graphics, but it didn't seem to do better than the VMS debugger. 

I don't know which TP debugger you saw, but several companies make
*good* ones.  Borland's new Turbo Debugger (*not* the new integrated
debugger in TP 5.0 and TC 2.0) offers a multiple views of the
software:  variables and expressions, code shown as C or assembler,
registers (CPU and math coprocessor), stack, breakpoints, program
output, and a log that breakpoints and such can write to.  You can
break at a given line or instruction, or when a certain expression
comes true, or a certain variable gets modified.  There are actually
*three* debuggers:  one for vanilla 8088's and such, one for 80386-based
systems, and one for remote debugging of software running on a second
system.  (There's also a programmable interface for hardware debugging
boards like Atron's and Periscope's.)

> Source-code control? Make?

Yes.  Yes.  And lint, and C++, and ksh, and awk, and vi, and emacs, and
nroff/troff, and TeX, and some Scribe variants.

But wait, there's more!  Many (most?) of the new computer assisted
software engineering (CASE) tools are being written for desktop systems
(Macintoshes and high-end MS-DOS boxes).  Even the mainframe COBOL
programmers are finding lots of tools for their eventual platform
running on PCs.

What's going on here?  Companies that write software tools like writing
them for desktop systems, for three reasons.

1)  There are a *lot* of these boxes out there.  Literally millions,
even if you make a 286 or a 68000 your minimal requirement.  So there's
a large customer base.

2)  These boxes are *cheap*.  Yes, a dumb terminal only costs $400.
But a 286 or 68000 system can be picked up for $2000-$3000.  (And the
manager who buys such systems for his or her staff can buy word
processing software for a few hundred dollars more, making the PCs even
more cost effective.)  So there's a large *potential* customer base.

3)  The desktop platforms are reasonably standardized.  Text-only
applications are easier to write for MS-DOS than curses, and lots
faster.  Graphics applications for the Mac (screen and printer) are a
breeze.  (Granted, the initial learning curve looks like a cliff.)
Graphics applications in the CGA/HGA/EGA/VGA world of MS-DOS are
tougher; third party libraries help ease the pain considerably.  I can
write a graphics application for NeWS, and X, and Apollo; but the
graphics parts aren't going to share a lot of code.  (And I've got
binary compatibility of executables, not just source code compatibility.
And a standard medium and format for distributing code and data.)

It's a lot easier to write a software tool for a big box than to
squeeze it into a little one.  But it's a lot more *profitable* to
shoehorn such tools on to the desktop.  That's what a lot of companies
have done; and that's why PC programmers can get spoiled.

>Erland Sommarskog, ENEA Data, Stockholm, sommar@enea.UUCP 

Paul S. R. Chisholm, psrc@poseidon.att.com (formerly psc@lznv.att.com)
AT&T Bell Laboratories, att!poseidon!psrc, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.