nigam@pcsc-sun (Alok Nigam) (07/06/88)
Soft-Eng Digest Tue, 5 Jul 88 V: Issue 16
Today's Topics:
Basics of Program Design (3 msgs)
C programming standards
Cynic's Guide, part 5: Bookshelf
Cynic's Guide, part 5: Bookshelf(long)
Please post on SOFT-ENG. Thanks
Project documentation
Reporting progress on a software project (7 msgs)
Short Course: Hierarchical Data Structures for Computer Graphics...
UNIX SHELL AS 4GL
What books does a software manager need?
----------------------------------------------------------------------
Date: 20 Jun 88 15:12:01 GMT
From: pacbell!ptsfa!jmc@ames.arpa (Jerry Carlin)
Subject: Basics of Program Design
In article <900@td2cad.intel.com> brister@td3cad.UUCP (James Brister) writes:
>What I mean is: do experienced programmers usually write flow charts,
>or pseudo code. Do they write the whole program out by hand first or
>build it up in their favorite editor?
>
>What's a good way to organize the writing process? I have all these
>great ideas running around in my head that I find difficult to get
>out without making mistakes in the task itself.
Good question! In spite of all the theory and people that say we can
reduce programming to a "factory", it is still a "craft" (in the
highest sense). There are a lot of aids, and experienced people will
use them when appropriate. It is almost never (as in <1%) a good idea
to code at the keyboard without knowing what you are doing.
On the other hand, for relatively simple programs, I'll code the comments
first, then the mainline and then fill in the functions without ever
using pseudo code/diagramming techniques etc. For complex systems,
I'll use everything under the sun.
The best way to organize the process comes with experience: some
problems need "data structuring", some "data flow", some "object-oriented"
etc. Beware of snake-oil. There is no magic elixer.
By the way, you will always make mistakes. Murphy's law lives.
I hope this helped you. (In case you're wondering, I've been
------------------------------
Date: 20 Jun 88 19:12:35 GMT
From: spar!freeman@decwrl.dec.com (Jay Freeman)
Subject: Basics of Program Design
That's a fascinating subject; there are probably as many different answers
as there are programmers. When I am doing a big system, I usually spend as
long a time as possible in a design phase, thinking about data structures,
algorithms and control flow at a quite abstract level, often accumulating
large stacks of notes on paper, backs of envelopes and so on. I don't use
software tools too much for this phase, not because there aren't any (an
excellent text editor and perhaps a database tool for chasing down reference
material would be the premier items), but because I do much of this work in
places where there is no computer (in the shower, commuting, sitting in
coffee houses, lying in bed trying to get to sleep ...).
A key part of the design is figuring out how to bring the system up; I'm
sure your professors tell you that getting everything all written, then
compiled, then starting to test, is NOT the way! It's important to define
a development path that starts with only a few pieces of the whole thing
up and running, and ends with a complete system, such that you can move
from point to point on the path by adding small modules to the system, in
such a way that each module is separately testable by itself and that the
system is immediately testable after module installation to see that the
integration worked. If the modules are large, then each module is a project
in its own right, and has its own development path. The overall development
path then becomes a directed graph. The graph may even have cycles -- one
does prototypes and throws them away, and so on.
When I start to code I generally use a text editor that is sufficiently
familiar that I don't have to think about using it, enter algorithms and
data structure either in source or in in psuedocode -- structured English --
and then transmogrify them into real source in the latter case. Depending
on the language, it is often easier to think about what's going on by
looking at psuedocode. With higher-level languages, the psuedocode is
less often necessary.
Subject to the constraint on maintaining a testable development path, there
are several ways to think about the order in which to implement various
modules. Top-down is nice and logical, but often leads to lots of stub
functions which are difficult to test until you have coded out to the leaves
of the call graph; then you have to do lots of careful incremental testing
as the effects of "real" functions propagate their way back to the root.
Bottom-up is useful if you are sure what primitives you are going to need;
you can then write them, test them independently, and start putting them
together. Sometimes I develop along the path of least resistance, working
on whatever part of the system I think I best understand and am most
prepared to deal with. That changes from day to day, of course. A case can
be made for thinking hard about what part of the system is riskiest and
working on that part as soon as possible -- if the whole thing isn't going
to work, you want to know about it as soon as possible so you can work out
a fix or do something else.
It is often very handy to use a system that provides some kind of top-level
interpreter so that you can call and test functions interactively as you
create them. Lisp is great for this, as are some of the interpreted Cs.
Most traditional systems and application languages fail badly on that score.
And in that context it is a useful rule of thumb never to create a data
structure without also creating a function that prints it out in a form
that humans can read; you end up inserting that function time after time
as a debugging aid.
My, how I ramble. Hope this is useful or at least provokes thought.
------------------------------
Date: 21 Jun 88 12:33:03 GMT
From: pdn!larry@uunet.uu.net (Larry Swift)
Subject: Basics of Program Design
In article <900@td2cad.intel.com> brister@td3cad.UUCP (James Brister) writes:
>What I mean is: do experienced programmers usually write flow charts,
>or pseudo code. Do they write the whole program out by hand first or
>build it up in their favorite editor?
Flow charts or state diagrams (I prefer the former) are better thought
organizers, but are difficult to maintain, so pseudo code usually wins out.
However, with flow charts it is difficult to forget about a path. Does
ANYONE write code by hand, anymore? I doubt it.
------------------------------
Date: Tue, 21 Jun 88 15:18:52 EDT
From: chuck@wooglin.scc.com (Charles Williams)
Subject: C programming standards
I am in search of C design and programming standards in the public domain.
Something of the nature of the infamous "Green Book" for Ada. Can anybody
help?
------------------------------
Date: Fri, 24 Jun 88 00:03:57 edt
From: shull@scrolls.wharton.upenn.edu (Christopher E. Shull)
Subject: Cynic's Guide, part 5: Bookshelf
I have a couple of books to add to the Soft-Eng bookshelf:
James Gleick, !Chaos: Making a New Science!, Viking Penguin 1987,
ISBN: 0-670-81178-5
Edward R. Tufte, !The Visual Display of Quantitative Information!,
1983, Graphics Press, Box 430, Cheshire, Connecticut, 06410
no ISBN on my copy.
------------------------------
Date: Sun, 05 Jun 88 19:27:43 PDT
From: PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU <Dick Botting>
Subject: Cynic's Guide, part 5: Bookshelf(long)
Last year, with much help from SF-Lovers I put together a list of good
bad and indifferent non-technical/fictional books about computers.
It has about 40 items and probably has MORE of this type of thing
than any Software Engineer would want, but if you see one of these
going for 5cents in a garage sale...
Barth, John Giles Goatboy fantasy R Rated humor(WESCAC)
Baum, Frank L The OZ Books fantasy sf juvenile (Tic-toc)
Bierce, Ambrose Maxon's Master horror short story
Bischoff, David Wargames sf juvenile
Brunner, John The Shockwave Rider sf(networked society)
Caidin, Martin The God Machine sf
Cameron, Lou Cybernia sf(DP complex out of control)
Card, Orson Scott ENDER'S GAME
Card, Orson Scott SPEAKER FOR THE DEAD
Chalker, Jack Quest for the Well World
Clark, Arthur C 2001 sf film(HAL 9000)
Clark, Arthur C 2010 sf film(SAL)
Creighton, Michael The Andromeda Strain sf thriller & Film
Deighton, Len The Billion Dollar Brain spy thriller
Ellison, Harlan I have no mouth, and I must scream sf horror short
Evans, Christopher The Micro Millenium non-fiction BBC TV Series
Gawron, Jean Mark Algorithm sf (weird)
Gerrold, David When Harley Was One sf(HARLEY)
Gibson, William Count Zero sf
Gibson, William Neuromancer sf
Heinlein, Robert The Moon is a Harsh Mistress sf (Mike)
Heinlein, Robert A Number of the Beast sf (Gay,Tic-toc, Dora...)
Heinlein, Robert A The Cat Who Walks Through Walls sf(Mike,...)
Heinlein, Robert A TIME ENOUGH FOR LOVE sf (Dora)
Herbert, Frank Destination Void sf (SHIP)
Hogan, James P. <Anything> sf author worked for computer Cos.
Hoyle, Fred The Black Cloud sf
Hoyle, Fred A for Andromeda,
Jackson, Bruce The Programmer ??
Kidder, Tracy The Soul of a New Machine. nonfiction dramatised
Ledgard, McQuaid et al From Baker St. to Binary Fictional Text Social
Milan, Victor The Cybernetic Samurai sf(TOKOGAYA??)
Nelson, Ted Computer Lib non-fiction (Tic Toc, PDP8 etc)
Nelson, Ted Dream Machines non-fiction (graphics, networks & fun)
Nelson, Ted Computer Lib-second Edn non-fiction (less fun)
Pohl, Fred The HeeChee Series: sf
Quinn, Simon The Human Factor Thriller(terrorism )
Robinett, Stephen The Man Responsible sf
Ryan, Thomas J. The Adolesence of P-1 sf? thriller(IBM 360 teleprocessing!)
Varley, John Press Enter sf(short story)
Vinge, Vernor True Names sf(Networks, bbs, role playing games)
------------------------------
Date: 8 Jun 88 17:46:00 EDT
From: Nahum (N.) Goldmann <ACOUST%BNR.BITNET@CORNELLC.CCS.CORNELL.EDU>
Subject: Object Oriented Programming
Everybody in Canada who is interested in the Object-Oriented Programming
(OOP) and/or in the Behavioral Design Research as related to the
development of human-machine interfaces (however remotely connected to
these subjects) - please reply to my e-mail address. The long-term
objective - organization of a corresponding Canadian bulletin board.
------------------------------
Date: 15 Jun 88 20:21:17 GMT
From: tikal!sigma!uw-nsr!john@beaver.cs.washington.edu (John Sambrook)
Subject: Project documentation
My research group is interested in improving its software development
methodologies. One area of concern to our group, and I imagine to other
groups as well, concerns project documentation. I would be interested in
learning what types of documentation other groups produce when executing
software development projects.
In particular, I am more interested in document types and content, and
less interested in style issues. Of particular interest would be general
outlines of specification documents, design documentation, statement of
work, test plans, etc. It would be great if we could establish a
working repository of such information. TeX and/or LaTeX sources are
also of interest to me personally, but perhaps not to other sites.
I will point out that the IEEE publishes some standards in this area.
We are ordering copies of these standards, but I thought I would ask for
some net-input as well.
------------------------------
Date: 13 Jun 88 14:14:35 GMT
From: mailrus!caen.engin.umich.edu!conliffe@husc6.harvard.edu (Darryl C. Conliffe)
Subject: Reporting progress on a software project
I would like suggestions and/or reports on how others accomplish
the following: having convinced management that an iterative
approach to a software design project is appropriate, how do you
report progress on same? Since you are not proceding linearly
through a series of measurable milestones, what *DO* you use to
indicate that the development is "on schedule"?
This seems to be a corollary of the question "why aren't you
coding yet?", but it also represents management's valid need to know
if the appropriate resources are allocated to a job and that the
plan of attack is correct.
Finally, when employing Structured Analysis and while still working
out the layout and definition of your "bubbles", how do you project
how long it will take? (This is a new system and the design tools
and approach have not been used before on ANY project, no no "history"
is available.)
------------------------------
Date: 14 Jun 88 20:07:37 GMT
From: agate!garnet.berkeley.edu!csm@presto.ig.com
Subject: Reporting progress on a software project
conliffe@caen.engin.umich.edu (Darryl C. Conliffe) writes:
>the following: having convinced management that an iterative
>approach to a software design project is appropriate, how do you
>report progress on same?
>...how do you project how long it will take?
> Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069
If management cannot judge from the prototype itself how you are
progressing, they sure as hell are not in any position to judge
from a (possibly fudged) PERT chart. Arrange periodic hands-on
demonstrations (but no more frequently than every two weeks).
You must have the following guarantees from the powers that be:
1) Hardware and Software for the project will be delivered
to you on schedule or the project will be extended on a day
for day basis. If you are not responsible for procurement
and/or installation make sure that delays in this process are
documented and added linearly to expected delivery date.
2) End-user time will be available. You must be able to get
personnel when you need them. Remember, verbal assurances from a
middle manager are going to be forgotten when you say you need
two secretaries and a supervisor this Friday, all day. The
middle manager has someone checking his/her department's progress, too.
Ok, how long will it take?
For each manager involved in initial meetings add one month.
For each manager who says "data flow analysis" add another month.
For each unique end-user type add one month.
For each unknown software package to be employed add two months.
For each unknown hardware device add two months.
For each 100 miles between developer and installation add one month.
For each type of communication channel add one month.
If an IBM mainframe shop is involved and you are working on a non-IBM
system add 6 months.
If an IBM mainframe shop is involved and you are working on an IBM
system add 9 months.
Round up to the nearest half-year.
--Brad Sherman
By the way, ALL software projects are done by iterative prototyping.
Some companies call their prototypes "releases", that's all.
------------------------------
Date: 15 Jun 88 15:08:52 GMT
From: wor-mein!pete@uunet.uu.net (Pete Turner)
Subject: Reporting progress on a software project
csm@garnet.berkeley.edu writes:
>You must have the following guarantees from the powers that be:
> 1) Hardware and Software for the project will be delivered
>to you on schedule or the project will be extended on a day
>for day basis. If you are not responsible for procurement
>and/or installation make sure that delays in this process are
>documented and added linearly to expected delivery date.
Has any engineer out there EVER been able to get "the powers that be" to
sign up to slip a project schedule in this fashion?
This sounds completely unrealistic to me, even if it does make sense.
------------------------------
Date: 16 Jun 88 20:00:55 GMT
From: helios.ee.lbl.gov!pasteur!agate!garnet.berkeley.edu!csm@tis.llnl.gov
Subject: Reporting progress on a software project
In article <1377@wor-mein.UUCP> pete@wor-mein.UUCP (Pete Turner) writes:
>Has any engineer out there EVER been able to get "the powers that be" to
>sign up to slip a project schedule in this fashion?
>This sounds completely unrealistic to me, even if it does make sense.
If you can point to a history of delivering good products on-time
(it is possible), you can begin to make the rules. If you are in the
position of setting schedules for project delivery, you have to decide
whether to tell the people with the $$$ the truth or what they want to
hear. I was predicating my statements on the former, although I admit
the latter will get you more first-time business.
One thing we should all learn about negotiations from the Reagan DoD
budgets is that if you need 50 demand 150. Then howl like a banshee as
you grudgingly settle for 133.
------------------------------
Date: 18 Jun 88 12:45:09 GMT
From: attcan!utzoo!yunexus!geac!david@uunet.uu.net (David Haynes)
Subject: Reporting progress on a software project
In article <917@blue.engin.umich.edu> conliffe@caen.engin.umich.edu (Darryl C. Conliffe) writes:
>I would like suggestions and/or reports on how others accomplish
>the following: having convinced management that an iterative
>approach to a software design project is appropriate, how do you
>report progress on same?
One tool I have used from time-to-time is a system I call todo.
When a pert chart has been made for the project, the tasks are then
fired off to the appropriate personnel as todo items. The person
receiving the todo item has the option of accepting, refusing or
delegating the item. If the item is accepted, the acceptor places
a personal priority on the item and the initiator of the message
is notified. If the message is delegated, the new person has the
option for accepting, refusing or delegating. However, since the
todo item has been delegated, the originator is also notified of
the delegation.
Now, when an item is pending (or almost pending) the person who
accepted the item is notified of its prescence. As the task is
completed, the acceptor releases the todo item, which is date
stamped and returned to the originator of the item. Tracking
projects then becomes a much easier task.
All this was implemented using unix mail and a special todo daemon.
An enhancement I would like to add at some point would allow
for percentage complete and problem tracking, but, it isn't
what I get paid for, so it may take some time.
------------------------------
Date: 19 Jun 88 12:31:23 GMT
From: attcan!utzoo!yunexus!geac!david@uunet.uu.net (David Haynes)
Subject: Reporting progress on a software project
In article <1377@wor-mein.UUCP> pete@wor-mein.UUCP (Pete Turner) writes:
>In article <10941@agate.BERKELEY.EDU> csm@garnet.berkeley.edu writes:
>>You must have the following guarantees from the powers that be:
>> 1) Hardware and Software for the project will be delivered
>>to you on schedule or the project will be extended on a day
>>for day basis. If you are not responsible for procurement
>>and/or installation make sure that delays in this process are
>>documented and added linearly to expected delivery date.
>
>Has any engineer out there EVER been able to get "the powers that be" to
>sign up to slip a project schedule in this fashion?
>
>This sounds completely unrealistic to me, even if it does make sense.
>
>
>Pete
There is an old tried and true method for attaining the correct
response (on your part) from the powers that be. It goes like this:
M E M O R A N D U M
To: Powers That Be
From: Mindless Worker Lackie Drone
Subject: Slippage in Schedule
Dear PTB:
Since we have not yet recieved our Frobotz 1200
which is required at this time to continue work according
to the Project Plan dated 19th June, we are now faced with
a potential slippage in the schedule provided at that date.
#ifdef KNOW_WHEN_FROBOTZ_IS_DUE
Since the Frobotz is now estimated to arrive in
three weeks, please adjust the schedule provided in the
Project Plan to reflect a new completion date of xxth
May 19xx. We are currently looking at re-scheduling some
less other work to fill in this unexpected gap in our
planned schedule.
#else
Since we have received no word on when the Frobotz
is to arrive, we appear to have two options on how to
proceed:
1) If we can determine the date of expected arrival
of the Frobotz 1200 we will attempt to re-schedule
for its arrival and will inform you of the new
scheduled completion date based upon this new
information.
2) We can re-work the schedule to push the requirement
for the Frobotz further down the schedule. We estimate
that this rescheduling effort will take one month
and involve a series of meetings with other managers
in order to co-ordinate our new delivery schedules
with thier personnel and resources. Naturally, we
will automatically incur a slippage of one month
for this re-planning effort.
#endif
In the first ifdef, you are practicing an ancient and honorable business
tradition of covering your ass. You have informed management that a slippage
is occuring and you have said you are trying your best, and you have
made the manager both aware of the problem and responsible for its
solution.
In the second ifdef, you are making the manager make a choice -- what they
get paid for. Either s/he has to find out the expected arrival date of
the Frobotz *and* accept that the project will slip *or* s/he will have
to fund a re-planning effort with the fact that the project is slipping
being broadcast throughout the company as you have the "meetings with
the managers of other departments". This is (potentially) of great
embarassment to the PTB and is to be avoided at all costs. Notice
that if the second plan is adopted, you get some time to determine
what affect the non-arrival of the Frobotz will have on the project.
This works for some managers -- others just refuse to make the decision.
So what? You have done your corporate duty by pointing out the slippage
and may now go back to trying to build the project.
------------------------------
Date: 22 Jun 88 15:50:50 GMT
From: wor-mein!pete@uunet.uu.net (Pete Turner)
Subject: Reporting progress on a software project
>There is an old tried and true method for attaining the correct
>response (on your part) from the powers that be. It goes like this:
>
> M E M O R A N D U M
I reiterate: This sounds completely unrealistic to me, even if it does make
sense.
If you work for Teeny Tiny Products, Inc. and they are under contract to ship
10 Profit Making Widgets by next month then any suggestion that the schedule
must slip will be either ignored or thrown right back in the face of the
suggestee, even if the Frobotz hasn't shown up yet.
Fortunately, such situations have not arisen at my current place of employment.
However, they were quite the norm at my previous jobs (hence their
previousness).
The usual solution was to pressure all developers to work 80+ hour weeks at
no extra pay and then refuse to discuss comp time because the next project
schedule can't be slipped (hence their previousness).
------------------------------
Date: 10 Jun 88 21:07:05 GMT
From: agate!saturn!saturn.ucsc.edu!chucko@ucbvax.berkeley.edu (Chuck Stein)
Subject: Short Course: Hierarchical Data Structures for Computer Graphics...
The University of California
Eighteenth Annual
INSTITUTE IN COMPUTER SCIENCE
presents courses in:
* Scientific Visualization * Fault Tolerant Computing
* Parallel Computation * Image Engineering
* Data Compression * Machine Learning
at
Techmart, Santa Clara
and
on campus in Santa Cruz
Following is a course description for:
-------------------------------------------------------------------------
Hierarchical Data Structures for Computer Graphics,
Image Processing, and Geographic Information Systems
September 14-16
Instructor: HANAN SAMET
X418 Computer Engineering (2)
The objective of this seminar is to introduce and understand the use of
the current and emerging developments in hierarchical data structures
for multi-dimensional data applications in computer graphics, image
processing, and geographic information systems. Attendees will gain
an appreciation for the simplicity of these methods, the differences
between them, and how to evaluate their appropriateness for their
applications.
Who Should Attend
This course is designed to introduce a wide range of professionals to
the use of hierarchical data structures in the handling of spatial data.
Engineers, mathematicians, analysts, programmers, cartographers, and
technical managers will all benefit by learning about how to use these
new methods in applications in areas that include computer graphics,
image processing, solid modeling, and geographic information systems.
Description
This three day seminar provides a comprehensive introduction to the
use of hierarchical data structures for handling multidimensional data.
It consists of three parts. In the first part, hierarchical data structures
such as the quadtree are defined and motivated in the context of
representing two-dimensional region data. You will be shown the
basics of manipulating a quadtree and how it is interchangeable with
more traditional region representations. Operations that find use in
computer graphics applications such as the computation of geometric
properties, overlay translation, and image approximation are
discussed in greater detail. Hierarchical representations are
compared to other related data structures by examining their time and
space requirements.
The second part stresses hierarchical representations of points, lines,
rectangles, and three-dimensional data. The representation of point
data is important in applications that require searching and finds use
in dealing with large off-line databases found in geographic
information systems, computer graphics, image processing, and
numerous other applications that involve spatial databases. For line
data the representations are evaluated in the context of preserving
accuracy. For rectangle data the evaluation is in the context of
searching and set operations. Rectangle data arises in the
approximation of data of a geographic nature and in VLSI applications.
Uses of the octree (a quadtree in three dimensions) are also
reviewed.
The third part examines an existing geographic information system
which employs hierarchical data structures to represent point, line, and
region data in a consistent manner.
Prerequisite: A familiarity with computer terminology and some
programming experience.
Seminar Outline
Part I: Two-Dimensional Region Data
l. Introduction
*Sample application
*Historical background
*Why use quadtrees instead of hexagons or other tessellations
2. Alternative Quadtree Implementations
*Explicit pointers
*Linear quadtrees
*Tree traversals
*Bintrees
3. Manipulating Quadtrees Using Neighbor Finding Methods
*Alternatives
*Horizontal and vertical neighbors
*Diagonal neighbors
* Ropes and nets
*Expected execution costs
4. Interchangeability with Other Representations
*Building quadtrees from binary arrays
*Building quadtrees from boundary codes
*Converting a quadtree to a boundary code
*Building quadtrees from rasters or run representations
*Converting a quadtree to a run representation
5. Geometric Operations
*Perimeter
*Connected component labeling
*Euler number or Genus
*Linear quadtree methods
6. Transformations and Computer Graphics
*Set operations
*Areas, centroids, moments
*Translation
*Rotation
*Windowing
7. Quadtree Approximation Methods
*Pyramid-based
*Compression
*Transmission
*Successive Approximation
8. Skeletons
*Distance
*Quadtree skeletons
*Quadtree medial axis transforms (QMAT)
*Construction of a quadtree from a QMAT
9. Space Requirements
*Storage
*Optimal quadtrees
Part II: Points, Lines, Rectangles, and Volumes
l. Multidimensional Point Data
*Non-hierarchical representations
*Grid method
*Point quadtrees
*K-d trees
*MX quadtrees
*PR quadtrees
*Bit interleaving
*EXCELL
*Grid File
*Range searching
2. Line Data
*Boundary codes
*Vectors
*Strip trees
*Binary Searchable Polygonal Representation
*Edge quadtrees
*Line quadtrees
*PM quadtrees
3. Rectangle Data
*Plane-sweep methods
*Quad-CIF trees
*Grid File
*R-trees
4. Three-Dimensional Data
*Arrays
*Boundary methods
*Constructive solid geometry
*Octrees
Part III: Quadtree-Based Geographic Information Systems
l. Example System
*Experimental results
*Query language
Text: Notes and copies of the instructor's transparencies will be
provided. Participants will be provided with the survey
"The Quadtree and Related Hierarchical Data Structures" by
H. Samet.
Instructor: HANAN SAMET is a Professor of Computer Science at the
University of Maryland, College Park.
Fee: Credit, $875 (EDP C6031)
Dates: Three Days, Wed.-Fri., Sept. 14-16, 9 a.m.-5 p.m.
Place: Techmart, 5201 Great America Pkwy., Santa Clara
-----------------------------------------------------------------------
RESERVATIONS:
Enrollment in these courses is limited. If you wish to attend a course
and have not pre-registered, please call (408) 429-4535 to insure that
space is still available and to reserve a place.
DISCOUNTS:
Corporate, faculty, IEEE member, and graduate student discounts and
fellowships are available. Please call Karin Poklen at (408) 429-4535
for more information.
COORDINATOR:
Ronald L. Smith, Institute in Computer Science, (408) 429-2386.
FOR FURTHER INFORMATION:
Please write Institute in Computer Science, University of California
Extension, Santa Cruz, CA 95064, or phone Karin Poklen at (408) 429-
4535. You may also enroll by phone by calling (408) 429-4535. A
packet of information on transportation and accommodations will be sent
to you upon receipt of your enrollment.
------------------------------
Date: 14 Jun 88 20:39:40 GMT
From: pacbell!pbhyf!rsp@ames.arpa (Steve Price)
Subject: UNIX SHELL AS 4GL
Without permission, for your edification & entertainment I post this quotation:
UNIX Shell is the Best Fourth Generation Programming Language
It is the UNIX shell that makes it possible to do applications in a small
fraction of the code and time it takes in third generation languages. In
the shell you process whole files at a time, instead of only a line at a
time. And, a line of code in the UNIX shell is one or more programs,
which do more than pages of instructions in a 3GL. Applications can be
developed in hours and days, rather than months and years with traditional
systems. Most of the other 4GLs available today look more like COBOL or
RPG, the most tedious of the third generation lanaguages.
"UNIX Relational Database Management: Application Development in the UNIX
Environment" by Rod Manis, Evan Schaffer, and Robert Jorgensen. Prentice
Hall Software Series. Brian Kerrighan, Advisor. 1988.
------------------------------
Date: 9-JUN-88 2:16p
From: dan@WILMA.BBN.COM
Subject: What books does a software manager need?
I'm not sure I'd consider myself a "manager type", but here
are two books I'd recommend for software managers:
CRUNCH MODE: Building Effective Systems on a Tight Schedule
John Boddie, Yourdon Press Computing Series
This slim book describes all the essentials for doing a whole project
in "crunch mode". Very useful, even if you don't spend all your time
that way.
Managing for Excellence
David L. Bradford and Allan R. Cohen
(don't have publisher here)
Perhaps not really a reference, but it was this book that convinced me
that supervision of other programmers might actually be as worthwhile
an activity as programming itself. Maybe even more worthwhile, if you
do it well.
------------------------------
End of Soft-Eng Digest
******************************