@RUTGERS.ARPA:RWK@SCRC-STONY-BROOK.ARPA (02/26/85)
From: Robert W. Kerns <RWK@SCRC-QUABBIN.ARPA>
From: umcp-cs!chris@topaz (Chris Torek)
Subject: Re: grisly grizzled programs
Date: 16 Feb 85 05:35:58 GMT
Ok, let's actually take this real example of "ls" bugs (4.2BSD
manual):
Newline and tab are considered printing characters in file names.
Now seriously, how often do you find file names with newlines and
tabs in them? Has *anyone* ever *really wanted* ls to print \n or
\t?
Gack! It's been 8 years or so since I used Unix much at all,
and I remember this one! I remember being Really Faked Out
by this one.@RUTGERS.ARPA:deutsch.PA@Xerox.ARPA (02/26/85)
From: deutsch.PA@XEROX.ARPA One of the comments on batch vs. interactive environments made a comment I would like to underline: "What happened [in the batch world] is that we were continually cutting back the scope of our projects." One of the arguments that has been made for interactive environments is that they allow us to continue to increase the scope of our ambitions, as the power of hardware increases. Indeed, the argument can be made that without the more powerful programming tools, we would never have been able to take advantage of the advances in hardware technology, because the complexity of the problems we wanted to solve would have overwhelmed us. I'm sure there are people here who have had experience with developing large, complex systems in both environments. (For example, I don't know if the airline reservation systems, the space program software, or the software used to keep track of design and parts for a 747 airliner were written in batch or interactive environments.) Let's hear some real examples. For myself, I don't think I would have been able to get some of my systems -- such as the interactive program verifier I wrote for my Ph.D. thesis, approximately 30,000 lines of Lisp code -- running in a batch world. But then again, much of the complexity of those systems comes from the fact that they themselves are interactive, and must go to considerable lengths to maintain data structures that allow them to respond quickly to user input. For that reason, I'm particularly interested in hearing about how people get interactive systems (like airline or bank) running in a world with few or no interactive programming tools.
eugene@ames.UUCP (Eugene Miya) (03/01/85)
> From: deutsch.PA@XEROX.ARPA > > One of the comments on batch vs. interactive environments made a comment > I would like to underline: "What happened [in the batch world] is that > we were continually cutting back the scope of our projects." > One of the arguments that has been made for interactive environments > is that they allow us to continue to increase the scope of our ambitions, > as the power of hardware increases. Agreed, and the people at livermore and los alamos would agree, but a great many not on this 'interactive' net would not agree, so we have a biased readership. > Indeed, the argument can be made > that without the more powerful programming tools, we would never have > been able to take advantage of the advances in hardware technology, > because the complexity of the problems we wanted to solve would have > overwhelmed us. I don't know if i agree with the latter statement completely. my cray has some of the poorest software i have ever seen. it it reached the point that more bugs are introduced into the compiler than are fixed. our cray people are embarassed, but it still gets a job done. it depends what you mean by advanced: sun are certainly advanced, but they are slow. > I'm sure there are people here who have had experience with developing > large, complex systems in both environments. (For example, I don't know > if the airline reservation systems, the space program software, or the > software used to keep track of design and parts for a 747 airliner > were written in batch or interactive environments.) Let's hear some real > examples. this is like the ongoing discussion in acm software engineering notes. in some ways i think 'real' systems would disappoint you. yesterday i was at a talk given by nico habermann, a person from the trw software productivity project, and hughes radar systems. the person at hughes was sad to mention large portions of their work in still in assembly language due to management familiarity and pressure. they were just now moving projects into jovial because young people were taking jobs. while computing science is making advances in micros, software, nets and workstations, lots of 'production environment' is reaching a stagnation point. some of this is due to dusty decks, but i think people are really discovering what they want to do with computing. i was asked want a real-world program was like by a student acm chapter, i bit down hard and thought about moving the SPICE circuit simulation program to a Univac 1100/81. SPICE was not easily portable to the 81 because of one statement: DIMENSION ARRAY(80000) the 81 has a process address space of 65K words. consider a future real-world computer graphics problem: i heard to do full 70mm screen star wars movies will require a 16Kx16K pixel resolution (let's skip color for a moment): how many machines can address that much storage (add 32-bit color if you wish) without a significant loss of performance [think of how many frames you need to compute for a movie]. the standard cs argument is to place high speed process servers on nets. this has two major problems: 1) while people are working on the nets and the workstation front ends, few people are working on the process servers. people are working on super computers, but this is not quite the same. 2) the bigger problem is the lack of an adequate software system to program this distributed system. distributed languages are not in common use, and i do not mean languages with system libraries using system calls ala the fps-164. this leaves the user to learn perhaps another operating system and do batch submission. what we have now. languages are needed which can handle distributed contexts in an easier way [note: i avoid using that popular word 'transparent']. what interests me in the next ten to 15 years of computing is: 1) as micros approach mainframes in speed, what's ibm going to do? are they going to enter the supercomputer market by necessity? are ibm's somewhat stagnate views of computing going to affect the rest of the market with pc/370 ideas? 2) are we going to create national computer facilities like Adam's hitchhikers guide to the galaxy: Deep Thought which run one program for years, without interaction? don't forget that the earth was a computer in this story too [last comment from vax135!alan]. 3) are there human conceptual limits to the size of program modules: intruction space, not data space? how really understands these million line dusty decks? my conclusions: 'batch' is here to stay, but its fundamental nature might change. this discussion started on finding multiple bugs in an interactive way. consider a simpler example: typographic errors in text. screen editors are nice, but if you consistently misspell a word it would be nice to do global search and changes rather than hand change [interactively] every occurence of the misspelling {certainly, the quality of interactively must be taken into account.}. > For that reason, I'm particularly interested in hearing > about how people get interactive systems (like airline or bank) running > in a world with few or no interactive programming tools. i would be mildy surprised to hear from many of those people [i know are are some] on this net.