Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!pacbell.com!att!news.cs.indiana.edu!arizona.edu!ece.arizona.edu!dan From: dan@ece.arizona.edu (Dan Filiberti) Newsgroups: comp.object Subject: Re: Software Engineering (was Re: Documenting OO Message-ID: <1991Apr17.170635@ece.arizona.edu> Date: 18 Apr 91 00:06:35 GMT References: <3201:Apr705:40:4591@kramden.acf.nyu.edu> Reply-To: dan@ece.arizona.edu (Dan Filiberti) Distribution: world,local Organization: University of Arizona Dept. of Electrical and Computer Engineering Lines: 199 Nntp-Posting-Host: dialsun.ece.arizona.edu In article <1991Apr17.172806.23036@visix.com>, amanda@visix.com (Amanda Walker) writes: >In article <1991Apr16.133304@ece.arizona.edu> dan@ece.arizona.edu (Dan> Filiberti) writes in annoyingly poorly word-wrapped fashion: I'll try to fix that, damn editors... :) >>Wrong. I have a problem with people not interacting with a user >>interface, since that is the sole purpose of a user interface. >You are missing my point. I am distinguishing between a physical >construct and a symbolic one. What I think of as "engineering" is the >application of the physical sciences (principally physics and chemistry, >but not exclusively) to the construction of physical devices (or "engines," >hence the term "engineer"). This interpretation is supported by the >dictionary definition you yourself cited. >By this definition, designing and building a computer is engineering. >Writing a program is not; it does not involve the application of the >physical sciences, although it may sometimes involve application of >mathematics. Unfortunately, while your defn is supported, its not the only one. I'll admit that writing a program does not necessarily apply natural science (which I think is what you mean by physical sciences, etc), but the primary defn of science is the following: science - knowledge attained through study or practice Also, you're wrong. By your defn, designing a computer is NOT engineering. Sorry. Hardware designers hardly ever deal with the construction of devices on a physical science level. They symbollically represent the internal architecture of a computer, using CAD. Please point out the difference between working with symbols of "and" gates, etc...and microcode. That's right, the only difference is a difference in symbols and terms. In fact, by your defn, you could prob eliminate over half the fields in electrical engineering... >A user interface is not a physical device, like an automobile is. It is >a symbolic construct that has no meaning beyond that assigned to it by >a person observing or interacting with it. Think about it. Sure, I'll think about it. No matter who chooses "save" from the Mac file menu, a file gets saved to disk. That's the meaning of "save", whether the user thinks the computer is a brain and remembers his information, or thinks the computer etches the information in stone. The meaning doesn't change from the hardware's point of view...and that's all that counts. >>Have you ever microcoded? >Yup. Hands-on experience with AMD 2901 and 2903 bit slice machines, as >well as familiarity with other microcoded architectures. >>Microcode essentialy describes hardware connections (registers to >>bus, bus to memory, etc...), this is not virtual reality, unless >>hardware is virtual reality. >Microcode is nothing *but* the creation of virtual reality. The whole >idea of it is that you can build a processor with a specific virtual >architecture without having to design and build it in hardware. A microcoded >control unit lets you act as if you had a hardwired control unit without >incurring some of the costs of building one. How do you build a processor with "virtual architecture", and then not build it in hardware? Whether microcoded or hardwired, a control unit is a control unit is a control unit. You are trying to define a microcoded control unit as an abstraction from a hardwired control unit. Wrong! They are just different implementations of the SAME THING. The microcoded unit uses a ROM (hardware) and addressing to send the control signals. The hardwired unit uses digital logic...but they both accomplish the same thing, through hardware. And, the microcode you write is stored in the ROM as a physical reality... >Software conveys a virtual reality in terms of physical reality. I view >this as directly analogous to the way a novel, or a play, or a movie >implements a virtual experience in terms of an actual experience. When >I went to see "She Stoops To Conquer" last week, I didn't *actually* visit >the 18th century British Isles, but I nonetheless had some of the experience >of them. Likewise, my screen doesn't *actually* have a sheet of paper upon >which I am typing this article, but I nonetheless have some of the experience >of it. And, a civil engineer doesn't actually pound the nails, but is still an engineer. What's your point? How many engineers actually solder the parts of a computer together? *laugh* >>At its lowest level, a file system at some point writes its data to >>hardware, is that virtual reality, no. > Yes. Do you tell your computer how to orient the magnetic domains in the > media on your disk? No. You interact with a symbolic construct > called a "file system" which creates a virtual reality in terms of those > magnetic domains. Wrong. At its lowest level, there is always some software that controls the writing of the data onto the media. Sure, its probably embedded in the disk drives controller. >>Please, give me an example of one computer system that >>didn't benefit in some way from a software generated user >>interface...just one. >An analog guidance system. A step-by-step telephone switch. I could go > on... Please do, since neither one of these examples is a computer. Since when can a telephone switch be programmed and store, retrieve and process data? >> Is a computer system special purpose? > Some, yes. Although computers can be programmed for a special purpose, they are not usually specifically designed with only one purpose in mind. >> Please, show me a computer >> that was designed without the aid of software along the way... >Any analog or pre-Von Neumann computer. I gave a couple of examples >above. An old-fashioned electronic calculator chip. That's pretty good. Now, please show me a computer built within the last decade that was designed without the aid of software. We would still be using that old-fashioned stuff if it wasn't for the idea of programmability. >However, how it was designed is immaterial--very few things are >designed without the aid of software these days :). I agree. Hence the term "software engineering". >>At the expense of a reduced instruction set, meaning more software to >>make it do anything. >OK, take a non-microcoded processor, like the Z80 or the 6502. My point >stands. You can always trade off special-purpose hardware for software. Yes, its theoretically possible. But, as the number of instructions increase, the ability to design the hardware is stressed. And, like I said, special-purpose hardware increases the amount of software required to do the same stuff, in most cases. >>I`d really like to see you swap hardware while using exactly >>the same software on the new machine, and get anything to run. >I did it Monday. Same Emacs, same window manager, same Usenet, ... Oh? And, there was no software differences between the two machines. I like how you conveniently left the two machines you used out, so I couldn't point out the differences in software that allowed you to run Emacs, window manager, and Usenet. If the microprocessors are different, you can start with the kernel... >>Software engineering - the application of knowledge obtained through >> study and practice of writing software. >>How's that? > Not bad, but it violates your own definition of engineering. No it doesn't. My previous defn was general, I didn't feel like pulling out the old dictionary. It violates nothing, because you can't possibly build anything for people without using learned knowledge. > I still think it's a misnomer. Well, I have no problem with it. It fits with how engineering is defined in our society today. And, that's all that counts... Daniel Filiberti dan@helios.ece.arizona.edu [:)}