[comp.software-eng] The development tools

daryl@ihlpe.ATT.COM (Daryl Monge) (02/23/88)

In article <1252@eneevax.UUCP>, noise@eneevax.UUCP (Johnson Noise) writes:
> In article <2984@metavax.UUCP> chris@metavax.UUCP (Chris Collins) writes:
> >... Words about the UNIX linker operation...
> >It seems to me that if Unix is _the_ system for programmers, as it has
> >been described to me several times, why does this idiocy exist?
> 	BTW Unix is THE system, for programmers or otherwise, it does
> have one obvious drawback: it assumes the user is competent.

This gets to me every time I see it posted.  UNIX is the best development
environment IN TOTAL that I have used, but
	IT IS NOT PERFECT.
	IT CAN BE IMPROVED.
The above smacks as a "If you don't like it, you must be a bozo" message.

The UNIX linker leaves much to be desired.  And consider the C compiler.
Leave off a semicolon and the parser goes nuts.  Does this mean I would go
back to VMS where a decent compiler and linker exists?  Of course not.

Lets see more discussion on things to be IMPROVED.
	- Better syntax directed editing (>emacs has now)
	- Improved syntactic and semantic compiler recovery
	- Use of object oriented languages (C++ !)
	- object oriented data bases for those object oriented languages.
	- More powerful compiler compilers
	- Better debugging
	- Automation of regression testing
	- Conversion of specification into code.

But please, when someone writes "this does not do what I want or expect",
don't reply "Its UNIX, love it or lump it".  Lets improve it!  Or at least
discuss the relative merits of possible methods of operation.

Daryl Monge				UUCP:	...!ihnp4!ihcae!daryl
AT&T					CIS:	72717,65
Bell Labs, Naperville, Ill		AT&T	312-979-3603

breck@aimt.UUCP (Robert Breckinridge Beatie) (02/24/88)

In article <2673@ihlpe.ATT.COM>, daryl@ihlpe.ATT.COM (Daryl Monge) writes:
> In article <1252@eneevax.UUCP>, noise@eneevax.UUCP (Johnson Noise) writes:
> > In article <2984@metavax.UUCP> chris@metavax.UUCP (Chris Collins) writes:
> > >It seems to me that if Unix is _the_ system for programmers, as it has
> > >been described to me several times, why does this idiocy exist?
> > 	BTW Unix is THE system, for programmers or otherwise, it does
> > have one obvious drawback: it assumes the user is competent.
> 
> This gets to me every time I see it posted.  UNIX is the best development
> environment IN TOTAL that I have used, but
> 	IT IS NOT PERFECT.
> 	IT CAN BE IMPROVED.
> The above smacks as a "If you don't like it, you must be a bozo" message.

Yes, it does smack of "..." but then the original comment about "idiocy"
smacks of "Unix is an idiots environment.  (substitute favorite monolithic
system here) is the system for real programmers."  This bothers me about as
much as the other message.

> Lets see more discussion on things to be IMPROVED.
>	[Interesting list deleted in the interest of brevity]
> But please, when someone writes "this does not do what I want or expect",
> don't reply "Its UNIX, love it or lump it".  Lets improve it!  Or at least
> discuss the relative merits of possible methods of operation.

Yes, but then isn't it obvious?  Isn't the real power of UNIX in that it
is an environment that encourages tool building?  If a tool (and the linker
is just another tool) doesn't do what you want or need, then build a better
tool.  That is the UNIX philosophy?  (well, at least my interpretation)  If
you want to get something done, then use the tools that UNIX provides to
build a better tool.  

The only restriction that seems desireable is "LEAVE THE KERNEL ALONE!".
Don't add "just one more system call", especially not just because it seems
"a neat idea".  The more baroque the kernel gets, the less clear it becomes.
The UNIX kernel provides a delightful interface to an abstract machine.  It
seems an awful shame to sew a bag on its side.
-- 
Breck Beatie
{uunet,ames!coherent}!aimt!breck
"Sloppy as hell Little Father.  You've embarassed me no end."

raveling@vaxa.isi.edu (Paul Raveling) (02/27/88)

In article <644@aimt.UUCP> breck@aimt.UUCP (Robert Breckinridge Beatie) writes:
>In article <2673@ihlpe.ATT.COM>, daryl@ihlpe.ATT.COM (Daryl Monge) writes:
>
>Yes, but then isn't it obvious?  Isn't the real power of UNIX in that it
>is an environment that encourages tool building?

	No.  It REQUIRES tool building because the operating system
	itself doesn't offer good solutions to large sets of problems.

>
>The only restriction that seems desireable is "LEAVE THE KERNEL ALONE!".

	Many of the problems with Unix can't be solved without
	a different kernel.  I favor a substantially different
	kernel with a Unix compatibility layer over it to accommodate
	existing applications.  I'd write new applications for
	the new kernel's native facilities.


	To pick a few examples:

	We need asynchronous i/o.  What we did in EPOS was to issue
	a request as a signal (NOT like a Unix signal) to a device
	driver process; the device driver then issued an answering
	signal at completion.  These signals included event
	data and were queued if the destination process wasn't
	ready for them.  Lurking behind this terse description
	are about half a dozen things the Unix kernel can't do.

	We need GOOD interprocess communication.  The only
	Unix mechanisms that are standard enough to have some
	hope to contribute are pipes and signals.  There's
	nothing which efficiently communicates a small set
	of paramaters, such as those in typical C function calls,
	between processes.  Unix signals don't queue event data,
	and pipes are slow -- our benchmarks show that either
	the setup overhead for pipe i/o or context switching
	is easily an order of magnitude slower than it should be.

	We need to share memory among processes in a multi-process
	application.  There's no way to do this and keep
	application software portable between Unixes with different
	extensions.

	We need a single i/o interface with mutually consistent functions.
	We really don't want to have to check stream status, call
	Xpending, etc. before knowing it's safe to call select.
	In fact, it can never be totally safe to use select with
	streams or X connections without a polling time interval;
	if a context switch and input completion intervene between
	the stream/X connection check and the select, the select
	can leave the calling process blocked.

	We need to spawn processes without creating another copy
	of the entire address space (as in fork) and without having
	to fetch the new process from a disk file (as in vfork).
	The first part is especially important, since much of our
	project's software is Lisp running in a 40-megabyte address
	space, and we don't have enough swap space for another
	copy of it.

	I haven't even mentioned the question of user interfaces,
	but the problems there are equally dismal.


	Give Me Liberty or Give Me Unix!


---------------------
Paul Raveling
Raveling@vaxa.isi.edu

bill@wsccs.UUCP (Bill Housley) (03/13/88)

In article <2673@ihlpe.ATT.COM>, daryl@ihlpe.ATT.COM (Daryl Monge) writes:
> Lets see more discussion on things to be IMPROVED.
> 	- Better syntax directed editing (>emacs has now)
> 	- Improved syntactic and semantic compiler recovery
> 	- Use of object oriented languages (C++ !)
> 	- object oriented data bases for those object oriented languages.
> 	- More powerful compiler compilers
> 	- Better debugging
> 	- Automation of regression testing
> 	- Conversion of specification into code.
> 
Add to your list:
	- More modern user interface

Now I know that some of you are saying "That should be discussed else
where, not on comp.software-eng".  But a system "... for programmers..."
should also be "...for users..." somewhere, otherwise we're all just a 
bunch of geeks writing games for ourselves to play, on systems nobody
else understands or wants to.  I take the attitude "UNIX (user
interface) sucks, but it's so widly used that I guess I'd better learn
it and use it anyway".  I agree with you, if this is the small systems
(my emphisis) multi-user operating system of the future, let's fix it so
it acts like it.  Otherwise, we'll have another MS-DOS out there
pissing off users on tomorrow's super machines and they'll say "Why are
we using this $#%%&$@(}^@#^ criptic %&*@#!*^ machine!!?" (because to users
the terms hardware and software are synonomus with '...this flipping
silly machine I'm using...).  To which us the programmer will respond
"Because it's the best 'machine' for ME to do MY job on".  To which a
dozen pencils, paper weights, coffee cups and other assorted office
furniture responds "THUD! WHAK! SMACK! SMASH!" on your head.
 


Kirk: But this planet is destroying it's self around us!!!
Kruge: Invigerating, isn't it!!

---------------------------------------------------------------------
UUCP !ihup!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!bill  {WSC Utah}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Disclaimer: These opinions are my own, not those of my wife who neither
selects, sensurs, understands, nor cares about what I write here.-