dstalder@TAFS.MITRE.ORG ("Stalder D S") (11/09/89)
I used to be in a CS program. I already knew ``trade-school'' type
knowledge; I had been in the work force for 3 years then. I wanted a
degree to learn some of the theory and to get a degree. I went to classes
and all I was taught was a tiny bit of theory and how to write my own sort
programs and the like. I got disgusted and am know about to graduate with
a Psych/Human Factors in CHI. They only taught me how to write programs, I
could pick up a good book at B. Daltons for that. I was interested in
theory. With that knowledge, here is my opinion:
I think that education should be 75% theory and 25% practical knowledge.
Someone can get an associates and work for two years and have more
practical knowledge than a BS does. You can get practical knowledge at
work. What you can't get in the work force is theory. That is what
college is for is to teach you knowledge more esoteric than that you find
out in the ``real-world.'' A student should know how to program in at
least one language and should know their way around in 1-2 operating
systems. More importantly though, they should be taught theoretical
knowledge that they can apply to whatever language they might be using.
(I don't know why but I keep wanted to spell knowledge without the `d'.)
--
Torin/Darren Stalder/Wolf
Blessed Internet: dstalder@mdf.mitre.org
Be! Bitnet: dstalder@gmuvax
ATTnet: 1-703-883-5747
Hail uucp: multiverse!uunet!pyrdc!gmu90x!dstalder
Eris! Snail: 1350 Beverly Rd.,Suite 115-223/McLean, VA 22101/USA
DISCLAIMER: I have enough problems getting credit what I do do for
work, much less this stuff.madd@world.std.com (jim frost) (11/12/89)
dstalder@TAFS.MITRE.ORG ("Stalder D S") writes: >I think that education should be 75% theory and 25% practical knowledge. >Someone can get an associates and work for two years and have more >practical knowledge than a BS does. You can get practical knowledge at >work. So what you're telling all those employers is that you want them to pay people for a year or so while they learn how to write good code? I don't think that'll go over so well. jim frost software tool & die "The World" Public Access Unix for the '90s madd@std.com +1 617-739-WRLD 24hrs {3,12,24}00bps
albaugh@dms.UUCP (Mike Albaugh) (11/14/89)
From article <1989Nov12.044511.992@world.std.com>, by madd@world.std.com (jim frost): > dstalder@TAFS.MITRE.ORG ("Stalder D S") writes: >>I think that education should be 75% theory and 25% practical knowledge. >>Someone can get an associates and work for two years and have more >>practical knowledge than a BS does. You can get practical knowledge at >>work. > > So what you're telling all those employers is that you want them to > pay people for a year or so while they learn how to write good code? > I don't think that'll go over so well. As a sometimes "employer", I'd far rather pay someone for a year to learn how to write good code, than hassle for a year with someone who _thinks_ he already can, and won't learn. I have more problems with people who seemingly never learned about things as simple as linked lists (or arithmetic overflow) than I ever had with someone simpy being not quite up to speed on the latest "hot" language. To add a few more logs to this fire, I also find a fair number of uses for the stuff I learned in those "useless" O.S. courses, and having written a "toy" compiler is a godsend when attempting to unravel the obscure error messages from other "state of the art" compilers. Mike | Mike Albaugh (albaugh@dms.UUCP || {...decwrl!pyramid!}weitek!dms!albaugh) | Atari Games Corp (Arcade Games, no relation to the makers of the ST) | 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709 | The opinions expressed are my own (Boy, are they ever)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/15/89)
From albaugh@dms.UUCP (Mike Albaugh): > having written a "toy" compiler is a godsend when attempting to unravel > the obscure error messages from other "state of the art" compilers. Then it's obviously high time that the market started to demand better error messages. Users should not have to understand the internals of a product in order to make use of it. Bill Wolfe, wtwolfe@hubcap.clemson.edu
psrc@pegasus.ATT.COM (Paul S. R. Chisholm) (11/15/89)
What good are compiler courses? Well, when writing code I want to run fast, I always feel more comfortable when I know more or less what the compiler is going to turn my code *into*; and the only way I can do that is at least read about compiler implementation techniques. From albaugh@dms.UUCP (Mike Albaugh): > having written a "toy" compiler is a godsend when attempting to unravel > the obscure error messages from other "state of the art" compilers. In article <7044@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847) writes: > Then it's obviously high time that the market started to demand > better error messages. Users should not have to understand the > internals of a product in order to make use of it. The dreaded, justifiably famous CS 701/702/703 compiler course at the University of Wisconsin at Madison had a project to implement a language with a large subset of Ada's features. I pulled my grade up from a high B to a low AB by rewriting all of my error messages to be more readable. Is that the right kind of training a grade student should get? Better believe it! Most people worked in pairs, and you had to build on your earlier work, so it was a good de facto course in software maintenance as well. The UW-Madcity "systems programming" curriculum strongly emphasized lots of non-trivial programming, though when I was there (1979-1981), there wasn't a "software engineering" course per se. A cute anecdote to finish with: Near the end of semester, we were told to turn in some sort of internal documentation on how our compilers worked, suitable for turning over to a maintenance programmer. Someone suggested, "Should we write a flowchart?" The entire class burst out laughing. > Bill Wolfe, wtwolfe@hubcap.clemson.edu Paul S. R. Chisholm, AT&T Bell Laboratories att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind.
djones@megatest.UUCP (Dave Jones) (11/16/89)
From article <1989Nov12.044511.992@world.std.com>, by madd@world.std.com (jim frost):
... [ In response to somebody's suggestion that C.S. curricula be
75% theory and 25% practice. ]
>
> So what you're telling all those employers is that you want them to
> pay people for a year or so while they learn how to write good code?
> I don't think that'll go over so well.
>
Are you kidding? Any large employer would be overjoyed to get a C.S.
grad right out of school who could learn to write good code in
only one additional year. Ecstatic. But it just don't happen.
(I can say this in relative safety just now, because at the moment I
don't know anybody working in programming who is a recent grad.
At least not anybody who knows where I live.)rsd@sei.cmu.edu (Richard S D'Ippolito) (11/17/89)
In article <4251@pegasus.ATT.COM> Paul S. R. Chisholm writes: >What good are compiler courses? Well, when writing code I want to run >fast, I always feel more comfortable when I know more or less what the >compiler is going to turn my code *into*; and the only way I can do >that is at least read about compiler implementation techniques. Nonsense -- this has nothing to do with software engineering, the original topic. At the engineering level, you don't care what the compiler is doing with the code anymore than an architect cares how electricity flows through wires. If you wish to specialize in designing compilers, take the course. Rich -- We use kill ratios to measure how the war is going. We use SLOC ratios to measure how our software is coming. (Idea from Gary Seath) rsd@sei.cmu.edu -----------------------------------------------------------------------------
crcraig@athena.mit.edu (Chris Craig) (11/17/89)
In article <4967@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >Nonsense -- this has nothing to do with software engineering, the original >topic. At the engineering level, you don't care what the compiler is doing >with the code anymore than an architect cares how electricity flows through >wires. Reasonable in some cases, but kind of naive in others. Sometimes what the compiler does with the code determines whether or not your program satisfies its specifications. >If you wish to specialize in designing compilers, take the course. What if I just want to learn about lexical analyzers, parsers, etc. so I can apply them to *other* areas? What about a little breadth in education? There are lots of reasons to take a compiler design course, not the least of which is masochism :-) ----------------------------------------------------------- Chris Craig MIT '89 crcraig@athena.mit.edu MIT/Project Athena
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/17/89)
In article <15947@bloom-beacon.MIT.EDU> Chris Craig writes: >In article <4967@ae.sei.cmu.edu> Richard S D'Ippolito writes: > >>Nonsense -- this has nothing to do with software engineering, the original >>topic. At the engineering level, you don't care what the compiler is doing >>with the code anymore than an architect cares how electricity flows through >>wires. > >Reasonable in some cases, but kind of naive in others. Sometimes what >the compiler does with the code determines whether or not your program >satisfies its specifications. Indeed, that's precisely why it's not software engineering! Any need to do this should tell you that you are not doing engineering. Architects are not doing architecture if they are worrying about how their designs are implemented at the beam and rivet level Architects and other engineers can only work effectively when the working models exist. How can there be working models when the lowest-level specifications are interpreted differently? The lowest-level components in engineering disciplines are truly standardized and portable. >>If you wish to specialize in designing compilers, take the course. > >What if I just want to learn about lexical analyzers, parsers, etc. so >I can apply them to *other* areas? What about a little breadth in >education? ... Of course, as long as you realize exactly what you are learning and are not told that you are studying engineering. Cheers, Rich
barnes@Xylogics.COM (Jim Barnes) (11/17/89)
In article <4967@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >In article <4251@pegasus.ATT.COM> Paul S. R. Chisholm writes: >>What good are compiler courses? Well, when writing code I want to run >>fast, I always feel more comfortable when I know more or less what the >>compiler is going to turn my code *into*; > >Nonsense -- this has nothing to do with software engineering, the original >topic. At the engineering level, you don't care what the compiler is doing >with the code anymore than an architect cares how electricity flows through >wires. Nonsense, unless your definition of a software engineer doesn't care about performance. ;-) ---- Jim Barnes (barnes@Xylogics.COM)
reino@cs.eur.nl (Reino de Boer) (11/17/89)
rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >In article <4251@pegasus.ATT.COM> Paul S. R. Chisholm writes: >>What good are compiler courses? Well, when writing code I want to run >Nonsense -- this has nothing to do with software engineering, the original >topic. At the engineering level, you don't care what the compiler is doing >with the code anymore than an architect cares how electricity flows through >wires. >If you wish to specialize in designing compilers, take the course. Although a compiler course is relevant to software engineers, if only to understand more about designing languages and their implementation. Didn't someone once say: each program is in fact an interpreter for a language (where the language defines all legal input to the program, and the semantics of the various inputs) If noone ever said it, how about your comments ? -- Reino R. A. de Boer Erasmus University Rotterdam ( Informatica ) e-mail: reino@cs.eur.nl
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/17/89)
In article <1989Nov17.090716.11068@cs.eur.nl> Reino de Boer writes:
-Although a compiler course is relevant to software engineers, if only to
-understand more about designing languages and their implementation.
-Didn't someone once say:
- each program is in fact an interpreter for a language (where the
- language defines all legal input to the program, and the semantics
- of the various inputs)
-If noone ever said it, how about your comments ?
I'm sorry -- If this is directed to me, I am unable to answer you as I do
not understand the point you are trying to make.
Rich
--
When you can measure what you are speaking about, and express it in numbers,
you know something about it.
Lord Kelvin rsd@sei.cmu.edu
-----------------------------------------------------------------------------lfd@cbnewsm.ATT.COM (leland.f.derbenwick) (11/18/89)
Richard D'Ippolito appears to think engineering (specifically software engineering) ends with high-level design. The engineering disciplines apply all the way down to implementation details. In article <4979@ae.sei.cmu.edu>, rsd@sei.cmu.edu (Richard S D'Ippolito) writes: > In article <15947@bloom-beacon.MIT.EDU> Chris Craig writes: > > >In article <4967@ae.sei.cmu.edu> Richard S D'Ippolito writes: > > > >>Nonsense -- this has nothing to do with software engineering, the original > >>topic. At the engineering level, you don't care what the compiler is doing > >>with the code anymore than an architect cares how electricity flows through > >>wires. > > > >Reasonable in some cases, but kind of naive in others. Sometimes what > >the compiler does with the code determines whether or not your program > >satisfies its specifications. I would have said _extremely_ naive; Chris Craig is more tactful. > Indeed, that's precisely why it's not software engineering! Any need to do > this should tell you that you are not doing engineering. Needing to meet specified performance is common in all branches of engineering. How one goes about that is part of engineering. Why should software be different? For example, a chemical engineer who doesn't understand how spray towers work could design one that's 99% fluid and 1% air. (Which isn't a spray tower, it's occasional bubbles in a pot of fluid, and it's _not_ going to work as intended!) > Architects are not doing architecture if they are worrying about how their > designs are implemented at the beam and rivet level Architects and other > engineers can only work effectively when the working models exist. How can > there be working models when the lowest-level specifications are interpreted > differently? The lowest-level components in engineering disciplines are > truly standardized and portable. Very bad example. The Hartford Civic Center's roof collapsed (when the place was empty, luckily) because "beam and rivet level", as understood by the architects (and their CAD programs), didn't match the reality of how things are put together. And people _died_ a few years ago (the multi-level pedestrian walkway that collapsed) largely because an architect didn't properly understand the "beam and rivet level". Architects routinely provide "detailing" of how buildings are to be constructed. The detailing for the joints to attach each level of the walkway wasn't feasible to build, so the contractor used a feasible method that had only about half the strength that the architect intended. > >>If you wish to specialize in designing compilers, take the course. > > > >What if I just want to learn about lexical analyzers, parsers, etc. so > >I can apply them to *other* areas? What about a little breadth in > >education? ... > > Of course, as long as you realize exactly what you are learning and are not > told that you are studying engineering. > [...] That's like saying that a chemical engineering student who is learning about how to design chemical reactors isn't learning engineering. And even the high-level portions of software engineering can be taught (or at least practiced) in any course that involves software development. A compiler course is no exception. -- Speaking for myself, -- Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ -- lfd@cbnewsm.ATT.COM or <wherever>!att!cbnewsm!lfd
dar@nucleus.UUCP (Dario Alcocer) (11/18/89)
In article <1989Nov17.090716.11068@cs.eur.nl>, reino@cs.eur.nl (Reino de Boer) writes: > rsd@sei.cmu.edu (Richard S D'Ippolito) writes: > > >In article <4251@pegasus.ATT.COM> Paul S. R. Chisholm writes: > > >>What good are compiler courses? Well, when writing code I want to run > > >[text deleted...] > > >If you wish to specialize in designing compilers, take the course. > > Didn't someone once say: > each program is in fact an interpreter for a language (where the > language defines all legal input to the program, and the semantics > of the various inputs) > If noone ever said it, how about your comments ? > > -- > Reino R. A. de Boer > Erasmus University Rotterdam ( Informatica ) > e-mail: reino@cs.eur.nl In the book "The Unix Programming Environment", by B. W. Kernighan and R. Pike (ch. 8, pg. 233): "We chose to implement a language because it's representative of problems encountered in large programs. Furthermore, many programs can profitably be viewed as languages that convert a systematic input into a sequence of actions and outputs, so we want to illustrate the language development tools." -- Dario Alcocer dar@nucleus.mi.org
dstalder@TAFS.MITRE.ORG ("Stalder, D S") (11/20/89)
Jim Frost <madd@std.com> writes: >So what you're telling all those employers is that you want them to pay >people for a year or so while they learn how to write good code? I >don't think that'll go over so well. No, that is why you need some practical experience. To graduate with a CS degree without being able to write code is ridiculous. But don't tell me that work on the job is going to be tailored to the person's education. A college education is general experience. You can't learn everything you need to know at work in school. If you have experience with one language, you can generally pick up others of the same type quickly and other types without the difficulty you had learning the first language. In any job that I undertake, I hope to learn something, otherwise, I am a well-paid bottle-washer. -- Torin/Darren Stalder/Wolf Carpe Internet: dstalder@gmuvax.gmu.edu Diem! Bitnet: dstalder@gmuvax ATTnet: 1-703-883-57477 Snail: 1350 Beverly Rd., Suite 115-323/McLean, VA 22101/USA DISCLAIMER: A society where such disclaimers are needed is saddening.
mjl@cs.rit.edu (11/20/89)
In article <4994@ae.sei.cmu.edu>: >In article <1989Nov17.090716.11068@cs.eur.nl> Reino de Boer writes: >-Didn't someone once say: >- each program is in fact an interpreter for a language (where the >- language defines all legal input to the program, and the semantics >- of the various inputs) >-If noone ever said it, how about your comments ? > >I'm sorry -- If this is directed to me, I am unable to answer you as I do >not understand the point you are trying to make. > > >Rich The point is that the study of compilers (or whatever) may give you insights and models that are useful in the specification and development of software. I think you're taking an overly restrictive view of engineering, as if the form of the inquiry is somehow independent of the content of the final product. This is the engineering equivalent of the generic MBA who can manage anything! I don't think one can study any branch of engineering in a vacuum, totally devoid of relevant conceptual models that give substance to the discipline. As far as I know, electricial engineering students still take *engineering* courses in ciruit analysis; undoubtedly they learn something about the design process as a result, but I'll bet they come away knowing a thing or three about circuits to boot. >-- >When you can measure what you are speaking about, and express it in numbers, >you know something about it. >Lord Kelvin Contrapuntally: There's no sense being exact about something if you don't even know what you're talking about. John von Neumann. Also, Kelvin also used his immense scientific stature to deep-six most research into the age of the earth (unless the results agreed with his estimate of at several 10's of millions of years). I guess that means he liked some numbers better than others. :-) Mike Lutz -- Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {rutgers,cornell}!rochester!rit!mjl INTERNET: mjlics@ultb.isc.rit.edu Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {rutgers,cornell}!rochester!rit!mjl INTERNET: mjlics@ultb.isc.rit.edu
murphyn@cell.mot.COM (Neal P. Murphy) (11/20/89)
From two of the references, Richard writes, >>What good are compiler courses? Well, when writing code I want to run > >Nonsense -- this has nothing to do with software engineering, the original >topic. At the engineering level, you don't care what the compiler is doing >with the code anymore than an architect cares how electricity flows through >wires. and Reino writes, > >-Although a compiler course is relevant to software engineers, if only to >-understand more about designing languages and their implementation. >-Didn't someone once say: >- each program is in fact an interpreter for a language (where the >- language defines all legal input to the program, and the semantics >- of the various inputs) >-If noone ever said it, how about your comments ? > >I'm sorry -- If this is directed to me, I am unable to answer you as I do >not understand the point you are trying to make. First, Reino eloquently stated that every program written is a compiler, and knowledge of compilers will enable one to write better programs. Second, I must point out that an architect really couldn't tell you if his design is constructable. It remains the responsibility of the civil engineer to ensure that a building built to look like that which the architect envisioned will not collapse or be blown over in a strong wind. I do agree with Rich, an architect doesn't care how electricity flows through wires. He probably couldn't tell you how even if he wanted to. However, at the software engineering level, one should care very much what the compiler is doing. For example, I know of a compiler that generates a 32-bit address offset for an instruction that only uses a 16-bit address offset. One would care very much when that is the only compiler one has to use. Knowing how the compiler works allows a software engineer to design code that *will* compile, thereby allowing him to concentrate on ensuring that the code does what it should. NPN
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/21/89)
In article <7700@xenna.Xylogics.COM> Jim Barnes writes: >In article <4967@ae.sei.cmu.edu> Richard S D'Ippolito writes: >>In article <4251@pegasus.ATT.COM> Paul S. R. Chisholm writes: >>>What good are compiler courses? Well, when writing code I want to run >>>fast, I always feel more comfortable when I know more or less what the >>>compiler is going to turn my code *into*; >> >>Nonsense -- this has nothing to do with software engineering, the original >>topic. At the engineering level, you don't care what the compiler is doing >>with the code anymore than an architect cares how electricity flows through >>wires. > >Nonsense, unless your definition of a software engineer doesn't care >about performance. ;-) What's the point here, Jim? If you don't like the analogy, say so. Mature engineering design practice requires known architectural models. This means that the structure and performance of the models is fully known. How is it possible to do engineering design if the performance of the model components changes according to the implementor? If the architect has to worry about low-level implementation details, such as how the code is translated by various compliers, then he really can't be doing architectural design, can he? He is really doing model building, not model using, and this isn't engineering -- it's research. You are confusing implementation issues with design issues. Rich -- When you can measure what you are speaking about, and express it in numbers, you know something about it. Lord Kelvin rsd@sei.cmu.edu -----------------------------------------------------------------------------
reino@cs.eur.nl (Reino de Boer) (11/21/89)
rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >In article <1989Nov17.090716.11068@cs.eur.nl> Reino de Boer writes: >-Although a compiler course is relevant to software engineers, if only to >-understand more about designing languages and their implementation. >-Didn't someone once say: >- each program is in fact an interpreter for a language (where the >- language defines all legal input to the program, and the semantics >- of the various inputs) >-If noone ever said it, how about your comments ? >I'm sorry -- If this is directed to me, I am unable to answer you as I do >not understand the point you are trying to make. The point I'm trying to make is maybe best given in a simple example: Suppose we need a program to take the sum of 5 numbers, where these 5 numbers are the only input to the program. Futhermore, let's assume we want each input number to be positive and less than 1000. Each number will be entered on a line by itself. The program we will write can be viewed as an interpreter for a language with the following syntax: <input> ::= <numeral> <numeral> <numeral> <numeral> <numeral> <numeral> ::= <digit> [ <digit> [ <digit> ] ] <nl> | 0 <nl> <digit> ::= 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 <nl> ::= the representation of the terminating newline. The (informal) semantics can then be described as follows: The output of the interpreter consists of the sum of the numbers resulting from conversion of the numerals. Hope this explains -- reino -- Reino R. A. de Boer Erasmus University Rotterdam ( Informatica ) e-mail: reino@cs.eur.nl
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/22/89)
In article <6738@cbnewsm.ATT.COM> leland.f.derbenwick writes: >Richard D'Ippolito appears to think engineering (specifically software >engineering) ends with high-level design. The engineering disciplines >apply all the way down to implementation details. I'm sorry that's the message you got. The original context of this discussion was what to add/change/emphasize in CS to teach software engineering. Several folks suggested that courses on compilers and operating systems were valuable to teach SE. I strongly disagreed, especially with the comments made about worrying what the compiler does with the code during the _design stage_, arguing that at that stage, engineering design is possible only with fully captured models. What is missing here is an understanding of the engineering method, precisely that thing which is _not_ taught in any CS/SE program. You will not get it by studying compilers and operating systems. >Needing to meet specified performance is common in all branches of >engineering. How one goes about that is part of engineering. >Why should software be different? You must differentiate between model performance and system performance. >For example, a chemical engineer who doesn't understand how spray >towers work could design one that's 99% fluid and 1% air. (Which >isn't a spray tower, it's occasional bubbles in a pot of fluid, >and it's _not_ going to work as intended!) A chemical engineer who doesn't understand spray towers is not an engineer; HOWEVER, understanding how to apply one is not the same as knowing how to design one. >> Architects are not doing architecture if they are worrying about how their >> designs are implemented at the beam and rivet level Architects and other >> engineers can only work effectively when the working models exist. How can >> there be working models when the lowest-level specifications are interpreted >> differently? The lowest-level components in engineering disciplines are >> truly standardized and portable. > >Very bad example. The Hartford Civic Center's roof collapsed (when the >place was empty, luckily) because "beam and rivet level", as understood >by the architects (and their CAD programs), didn't match the reality >of how things are put together. There was a misapplication of the correctly working CAD program in the description of the joint. The failure was due to sloppy engineering procedure (work not independently checked), not due to a lack of adequate tools and methods. This does not contradict my statement that the working models must (and did, in this case) exist. When will it be the case that the failure of a SW system makes more news than the success of one? >And people _died_ a few years ago (the multi-level pedestrian walkway >that collapsed) largely because an architect didn't properly understand >the "beam and rivet level". Architects routinely provide "detailing" >of how buildings are to be constructed. The detailing for the joints >to attach each level of the walkway wasn't feasible to build, so the >contractor used a feasible method that had only about half the strength >that the architect intended. Think about what you just wrote -- an architect specified a design for which he had no working model. That's not engineering, is it? Again, it makes news in other fields, but not in ours as it happens all of the time. >> >What if I just want to learn about lexical analyzers, parsers, etc. so >> >I can apply them to *other* areas? What about a little breadth in >> >education? ... >> >> Of course, as long as you realize exactly what you are learning and are not >> told that you are studying engineering. >> [...] > >That's like saying that a chemical engineering student who is learning >about how to design chemical reactors isn't learning engineering. No, it isn't like that at all. Learning about lexical analyzers and parsers is not the same as learning engineering design anymore than learning how to hammer nails into is learning how to design walls. Chemical engineers learn models in the form of unit operations. >And even the high-level portions of software engineering can be taught >(or at least practiced) in any course that involves software >development. A compiler course is no exception. And what are these high-level portions of software engineering? Rich -- When you can measure what you are speaking about, and express it in numbers, you know something about it. Lord Kelvin rsd@sei.cmu.edu -----------------------------------------------------------------------------
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/22/89)
In article <1411@cs.rit.edu> mjl@cs.rit.edu (Michael Lutz) writes: >The point is that the study of compilers (or whatever) may give you >insights and models that are useful in the specification and >development of software. I think you're taking an overly restrictive >view of engineering, as if the form of the inquiry is somehow >independent of the content of the final product. Exactly the opposite is what I've been saying -- the final form of the product is precisely what is seen by the engineer. Without known models, this is impossible. >I don't think one can study any branch of engineering in a vacuum, >totally devoid of relevant conceptual models that give substance to the >discipline. See above. But one needs more than the models in order to be able to use them. >There's no sense being exact about something if you don't even know what >you're talking about. >John von Neumann. Please see the rest of Lord Kelvin's quote. What if it's being exact about what you don't know? Rich -- When you can measure what you are speaking about, and express it in numbers, you know something about it. Lord Kelvin rsd@sei.cmu.edu -----------------------------------------------------------------------------
crm@romeo.cs.duke.edu (Charlie Martin) (11/23/89)
In article <4979@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >>Reasonable in some cases, but kind of naive in others. Sometimes what >>the compiler does with the code determines whether or not your program >>satisfies its specifications. > >Indeed, that's precisely why it's not software engineering! Any need to do >this should tell you that you are not doing engineering. > >Architects are not doing architecture if they are worrying about how their >designs are implemented at the beam and rivet level Architects and other >engineers can only work effectively when the working models exist. How can >there be working models when the lowest-level specifications are interpreted >differently? The lowest-level components in engineering disciplines are >truly standardized and portable. > Richard, I don't mean this to be derogatory, but this really reads like you haven't had much exposure to engineering in the field, or for that matter to a working engineering organization that does much of anything BESIDES software engineering. While an architect is doing design, they should not be worrying about the nail, screw, and rivet level. They certainly do worry at the beam level, because strength and cost optimizations determine things like maximum clear span. But an architect's job usually includes construction supervision: sometimes with the architect acting as the general contractor, more often with the architect working as a sort of independent review of the general contractor. They must by law and by custom do this, becuase unless they have an explicit waver they are liable for flaws in the building that cause damages. Ev en if they are explicitly taken of the job in writing before contruction, the architect is liable for flaws in the design (cf the Kansas City flyway -- the architect was named in the liability suit. I don't know if they were found liable, since the failure was apparently due to an out-of-spec change made by the contractor.) It is true that most engineering disciplines use prebuilt components when available, but not all. Mechanical engineers will design special components for fabrication, they just have the choice, something that software engineers often don't (yet.) >> >>What if I just want to learn about lexical analyzers, parsers, etc. so >>I can apply them to *other* areas? What about a little breadth in >>education? ... > >Of course, as long as you realize exactly what you are learning and are not >told that you are studying engineering. > I don't think anyone is under the impression that you are learning engineering when learning about finite state automata and the executable models of them. I think many of us are holding that learning things like FSA's and parsers is a useful an necessary part of a good education in the things which ground software engineering. No one thinks that Diff Eq courses are studying engineering; they are just things that are necessary to *do* engineering on the continuous world. FSA's, computability, etc aren't engineering per se, but I think they are as necessary for we engineers of the discrete world as DE is for the other guys. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/23/89)
In article <1989Nov21.141820.5263@cs.eur.nl> Reino de Boer writes: >The point I'm trying to make is maybe best given in a simple example: > [example of summation program deleted] >Hope this explains -- reino It explains your words, but that wasn't my problem. There is near-total disconnect on ideas. How this relates to the original points on OS and software engineering, I cannot get. Sorry. Rich -- When you can measure what you are speaking about, and express it in numbers, you know something about it. Lord Kelvin rsd@sei.cmu.edu -----------------------------------------------------------------------------
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/23/89)
In article <16169@duke.cs.duke.edu> crm@romeo.UUCP (Charlie Martin) writes: >Richard, I don't mean this to be derogatory, but this really reads like >you haven't had much exposure to engineering in the field, or for that >matter to a working engineering organization that does much of anything >BESIDES software engineering. Let's try for a little closure here -- I am a registered professional engineer with 25 years of industrial design experience, with about 40% of it in software. >While an architect is doing design, they should not be worrying about >the nail, screw, and rivet level. They certainly do worry at the beam >level, because strength and cost optimizations determine things like >maximum clear span. The way they 'worry' about those things is to use model structures where they are certain that the detail designers can fill in the detail to create an instance of the model which meets the engineering specifications. Agreed that in small firms or for small projects, the architect may fill more than one role, but that isn't the point. The problem in software is that the roles of designer and implementer have not yet been distinuished. We've got carpenters and bricklayers trying to design houses. Every programmer is now a software engineer, but you won't find an architect in the field with a hammer. >It is true that most engineering disciplines use prebuilt components >when available, but not all. Mechanical engineers will design special >components for fabrication, they just have the choice, something that >software engineers often don't (yet.) All of the components are created from known models, otherwise the engineer is doing science and not engineering. We (in our project) are giving software engineers the choices, as we are helping to develop the design-level models. >I don't think anyone is under the impression that you are learning >engineering when learning about finite state automata and the executable >models of them. This is true for you, but not for those who suggested (and still insist) here that courses in OS and compilers were good ways to learn software engineering. >I think many of us are holding that learning things >like FSA's and parsers is a useful an necessary part of a good education >in the things which ground software engineering. No problem. We agree. Rich -- When you can measure what you are speaking about, and express it in numbers, you know something about it. Lord Kelvin rsd@sei.cmu.edu -----------------------------------------------------------------------------
chrisp@regenmeister.uucp (Chris Prael) (11/23/89)
In article <6738@cbnewsm.ATT.COM> leland.f.derbenwick writes: >And people _died_ a few years ago (the multi-level pedestrian walkway >that collapsed) largely because an architect didn't properly understand >the "beam and rivet level". Since my wife is a structural engineer and we have discussed this incident, I think I can consider myself informed about it. According to my wife, the basic problem was unprofessional conduct on the part of the STRUCTURAL ENGINEERS on the project. (Please note that the architect was not at fault.) The specific misconduct was the failure to have their work reviewed by independant peers. The engineers who were responsible lost their licenses. >Architects routinely provide "detailing" of how buildings are to be constructed. While this is generally done by the architect for minor structures such as a house or a carport, this work is all done by structural engineers for any building larger than that. Chris Prael
crm@romeo.cs.duke.edu (Charlie Martin) (11/25/89)
In article <5072@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >In article <16169@duke.cs.duke.edu> crm@romeo.UUCP (Charlie Martin) writes: > >>Richard, I don't mean this to be derogatory, but this really reads like >>you haven't had much exposure to engineering in the field, or for that >>matter to a working engineering organization that does much of anything >>BESIDES software engineering. > >Let's try for a little closure here -- I am a registered professional >engineer with 25 years of industrial design experience, with about 40% of it >in software. > Fair enough: you've got 5 years on me, but 100% of my design experience is in software (although I spent a lot of time with hardware people); I've also -- to fend off the obvious question -- spent a lot of time watching architects and engineers, and asking lots of questions, in order to broaden my knowledge of the real processes involved. Also, no PE (if there WERE a PE exam in software engineering, I'd take it!) but a CDP and by next month sometime a PhD (ghods willing.) > >>While an architect is doing design, they should not be worrying about >>the nail, screw, and rivet level. They certainly do worry at the beam >>level, because strength and cost optimizations determine things like >>maximum clear span. > >The way they 'worry' about those things is to use model structures where >they are certain that the detail designers can fill in the detail to create >an instance of the model which meets the engineering specifications. Agreed >that in small firms or for small projects, the architect may fill more than >one role, but that isn't the point. The problem in software is that the >roles of designer and implementer have not yet been distinuished. We've got >carpenters and bricklayers trying to design houses. Every programmer is now >a software engineer, but you won't find an architect in the field with a >hammer. I think we're beginning to converge on a point here. One counter-argument to point out is that in fact most architects work in small firms, even though they design big buildings. Even Frank Lloyd Wright and Corboisier (sp? I think that's right) don't/didn't have massive organizations. What discussions I've had with architects and what I've been able to glean from the design literature suggests that architects are in fact conscious of the engineering problems of things like maximum clear span, or rather increase of cost as clear span increases optimized against client's goals, from the first moments of design. And a Wright or Corboisier may not be on site supervising construction, but a junior member of the firm is: the architect or his firm is responsible for the nuts and bolts. But you've got a major point here that I think needs serious consideration: the designer is not yet separate from the carpenter in software. It's like the mechanical engineer being the machinist or toolmaker. The opposite side of this is that while mechanical engineers don't need to be machinists, mechanical engineers need to understand machine tools and manufacturing operations. In some countries, this is done by requiering engineering students to take a machine-work (construction work, etc) course as part of the introduction. When I was an engineering student, we had to take a course that included projective geometry, drafting, slide rule, and discussions of standard practices as one requirement, a course in project management as another, and a course on surveying as a third. (This is all before software engineering was a defined term.) The purpose was to make sure that we understood practical constraints and practices as well as ODEs and strength of materials. One reason SE doesn't make a distinction in teaching where ME does is that there is little distinction in practice: most people hire a CS grad to be a "software engineer" even though what they mean a new grad to do is be a real SE's machinist. The new grads aren't all that good as "machinists" but they aren't well prepared to software engineer either. (Or worse, they hire a new grad to DO a software engineer's job and think what they get is the best possible.) The other side of this is that we can't TEACH software engineering without requiring the students become machinists; there's not much you can teach about programming without teaching programming. The solution in my opinion is that we have to make sure that part of teaching computer science is teaching the low-level skills that have been considered part of software engineering up to now. I don't think any computer science grad ought to be able to graduate without understanding how to write a good program at the 1000--10,000 SLOC level. It seems as silly to allow the contrary as it would be to give a degree in English in which the recipient cannot write a competent sentence, paragraph, or 5,000 word paper. [Of course, that happens too...] > > >>It is true that most engineering disciplines use prebuilt components >>when available, but not all. Mechanical engineers will design special >>components for fabrication, they just have the choice, something that >>software engineers often don't (yet.) > >All of the components are created from known models, otherwise the engineer >is doing science and not engineering. We (in our project) are giving >software engineers the choices, as we are helping to develop the >design-level models. > Well, I can't respond to your research because I don't know enough about it. But when an engineer designs a bearing that is needed, which is not in the parts catalogues from the acceptable suppliers, but which is within the common state of art, he is not doing science: there is no hypothesis/experiment cycle going on. He just designs a left-handed double-roller frammistan because he knows there are right handed ones, but he can't find the left-handed one he needs to go on his new left-handed power pipe wrench. Similarly, all engineered software is created from known models (check e.g. the plans work of Soloway) and most other algorithms are designed on the basis of existing models as well. In designing a bearing, a designer had better know about the properties of other bearings, and of the materials that make them up. He will certainly hve seen a bearing in use, and will probably hav had experience with various kinds of prefab bearings in various uses. A software designer needs to know the properties of his "materials" -- which means understanding something about architectures; needs to have a background in the properties of his working stuff to know how to make design choices -- which means a working knowledge of analysis of algorithms, operating systems concepts, files systems, concurrency and parallelism; and needs to have experience with other successful artifacts which make use of the principles, and to have learned about them in the context of the tradeoffs and optimizations that can be made. > >>I don't think anyone is under the impression that you are learning >>engineering when learning about finite state automata and the executable >>models of them. > >This is true for you, but not for those who suggested (and still insist) >here that courses in OS and compilers were good ways to learn software >engineering. > I *am* glad that we have your infinite knowledge to draw on, Richard. That is ever so much clearer now. Funny, I had thought that the others were mostly arguing that OS etc courses were a good place to *present examples* of software engineering and its problems. But being a mere mortal, I can only draw on what I read, not on my intimate knowledge of what other people know. But as I recall the arguments presented (not just mine), the idea has been all along that operating systems courses and compilers courses were opportune places to expose students to large and complex programs. There seem to me to be three tiers here: - the theory: analysis of algorithms; concurrency and parallelism; finite state automata, computability, NP-completeness; discrete maths; discrete circuits; programming language semantics; correctness and safety; queueing theory and Markov systems. - central concepts that apply to most or all computers: languages and their differences; architecture (both in the Brooks sense of opcode-set design and in the higher-level circuit sense); constraints on resources and performce; organization of file systems and file stores; tradeoffs and optimizations; important algorithms uses in practice, like hierarchic chains of ordered sets. - the backround needed to work in practice: code "hygiene"; commenting; modularization; concepts of reuse; maintenance and the special skills that go with it; the idea of the life cycle and its models (waterfall, spiral, etc); the idea of metrics. I'm not wedded to the *names* of the courses; call them Larry Moe and Curly for all that I care. But many of the theory topics presented must (in my opinion) be reinforced with realistic examples, and courses like compilers, operating systems, and oh, data base courses are a convenient place to do this. Contrariwise, it appears to me that once one has seen the theory topics above, and seen them in practical applications for reinforcement, that one has studied the content of the "objectionable" courses no matter what they are called. So I don't know -- what doesn't the list include? What do you think is *not* appropriate for a software engineer to know? Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
crm@romeo.cs.duke.edu (Charlie Martin) (11/25/89)
All of these discussions (teaching SE, productivity, and licensing) bring up the question that more and more interests me; it is subtext to the whole discussion. What is software engineering? Boehm claims (Software Engineering Economics, pg 16) _Software engineering_ is the application of science and mathematics by which the capabilities of computer equipment are made useful to man via computer programs, procedures, and associated documentation. ...but that doesn't give much guidance to the detailed examination of what is or is not applicable to learning to be a software engineer. (It could be read to require the software engineer to know everything about nearly everything.) So let's re-cast the question: assume that there existed a professional engineer's exam for software engineering. (I am convinced that one will exist at sometime in the future, but that's not germane -- let's just assume that one DOES exist.) What is on the exam? I'd propose as a starting point the list of things I laid out in a previous posting today: theory, major historical applications as examples of how the theory is applied, some details of the techniques of software engineering, some discussion of modularity and other tradeoffs. Does anyone have other topics of interest? How about topics to be deleted? Rich d', Bill Wolfe, I'm specifically interested in your thoughts. (What is on the PE exam for, say, an electrical engineer? Does it still include, for example, questions on power engineering in your state?) Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
crm@romeo.cs.duke.edu (Charlie Martin) (11/25/89)
Has it struck anyone else in this discussion that the reason we can't trust new graduates to write good code on graduation is that we the academics have taught them to write BAD code BEFORE graduation? Is this soluble? Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
jmi@devsim.mdcbbs.com ((JM Ivler) MDC - Douglas Aircraft Co. Long Beach, CA.) (11/26/89)
In article <16189@duke.cs.duke.edu>, crm@romeo.cs.duke.edu (Charlie Martin) writes: > Has it struck anyone else in this discussion that the reason we can't > trust new graduates to write good code on graduation is that we the > academics have taught them to write BAD code BEFORE graduation? > Cripes, I can go to a high school and get someone to "write code" (both good and bad). I need more than that! I want a person who knows how to become part of the team. I need someone who understands that they are *not* supposed to create esoteric solutions to problems, but maintainable ones. I need someone who wants to problem solve, not just make "big engineering bucks" in aerospace. I need someone who can maintain trash software one day and create modular design the next. I need someone who cares about what they produce. I need quite a bit, and college degrees (and the associated "programs") don't provide me with any of it. This should make you smile... One of the best engineers I have ever worked with had a degree in music. That's the answer, we should be hiring music majors. :-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | J.M. Ivler at Douglas Aircraft in Long Beach, CA - VOICE: (213) 496-8727 | | INTERNET: jmi@devsim.mdcbbs.com | UUCP: uunet!mdcbbs!devsim.mdcbbs!jmi | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
crm@romeo.cs.duke.edu (Charlie Martin) (11/28/89)
In article <464.256f4723@devsim.mdcbbs.com> jmi@devsim.mdcbbs.com ((JM Ivler) MDC - Douglas Aircraft Co. Long Beach, CA.) writes: >In article <16189@duke.cs.duke.edu>, crm@romeo.cs.duke.edu (Charlie Martin) writes: >Cripes, I can go to a high school and get someone to "write code" (both good >and bad). I need more than that! I want a person who knows how to become part >of the team. I need someone who understands that they are *not* supposed to >create esoteric solutions to problems, but maintainable ones. I need someone >who wants to problem solve, not just make "big engineering bucks" in aerospace. You won't catch me disagreeing with you: all of these things are important, and I guess I've gotten old enough to find myself thinking "people just had higher standards in the Good Old Days." But I don't think I know the answer to teaching students to have higher standards, or to take pride and feel fulfillment in working on a useful part of a team effort. If I did, I'd write a book like the ONe Minute Manager, get rich, and spend my time on my hobbies. It seems as if we *might could* teach people to write decent code in their programming courses, however. But my strong impression is that we don't, in general, insist on anything except that it will compile and that it will compute the right answer in the one test case the grader applies. >This should make you smile... One of the best engineers I have ever worked with >had a degree in music. That's the answer, we should be hiring music majors. :-) I once read a bit of industrial psych that claimed that musicians were the people who had the closest match to the personality traits and skills of the really top-rank programmers. I guess it doesn't surprise me at all. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
sullivan@aqdata.uucp (Michael T. Sullivan) (11/28/89)
From article <16195@duke.cs.duke.edu>, by crm@romeo.cs.duke.edu (Charlie Martin): > > It seems as if we *might could* teach people to write decent code in > their programming courses, however. But my strong impression is that we > don't, in general, insist on anything except that it will compile and > that it will compute the right answer in the one test case the grader > applies. Don't forget that CS courses don't teach programming, they teach (start the choir) "SCIENCE" (the choir finishes). I seem to recall that of my classes at UC Santa Barbara, the only class with the word "programming" in it was "Programming Languages", an overview of several different languages. Even the introductory courses were "Introduction to Computer Science". If schools ever got around to teaching programming they might just do a swell job. -- Michael Sullivan uunet!jarthur.uucp!aqdata!sullivan aQdata, Inc. aqdata!sullivan@jarthur.claremont.edu San Dimas, CA
reggie@dinsdale.nm.paradyne.com (George W. Leach) (11/28/89)
In article <1989Nov27.230724.12252@aqdata.uucp> sullivan@aqdata.uucp (Michael T. Sullivan) writes: >Don't forget that CS courses don't teach programming, they teach (start >the choir) "SCIENCE" (the choir finishes). I seem to recall that of >my classes at UC Santa Barbara, the only class with the word "programming" >in it was "Programming Languages", an overview of several different languages. While programming may not be the main focus of these courses, it certainly is the vehicle for conducting laboratory experiments for many. A course in simulation is not very useful without hands on practice using a suitable simulation language. Algorithms may be studied independ of programming, but a lab program will aid in understanding them (or an animation). >Even the introductory courses were "Introduction to Computer Science". Yes, but at least when I was an undergrad *and* when I taught this course, half of the material (al least) was Pascal Programming. These are the courses where the students must learn programming skills and they must be reinforced throughout the curriculum. A certain quality of programming should be expected in all lab assignments no matter what the course. This requires the entire faculty to enforce such policy. >If schools ever got around to teaching programming they might just do a >swell job. WellI certainly was taught programming and taught well. BTW: I learned to hack in BASIC in high school. I learned how to program well in introductory courses and was never allowed to deviate in advanced courses where programming was secondary. George W. Leach AT&T Paradyne (uunet|att)!pdn!reggie Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/30/89)
Charlie, you start off OK, but include sarcastic remarks later in your article. I will try to close most of this discussion down: In article <16185@duke.cs.duke.edu> Charlie Martin writes: >In article <5072@ae.sei.cmu.edu> Richard S D'Ippolito writes: >>In article <16169@duke.cs.duke.edu> crm@romeo.UUCP (Charlie Martin) writes: >> >But you've got a major point here that I think needs serious >consideration: the designer is not yet separate from the carpenter in >software. It's like the mechanical engineer being the machinist or >toolmaker. > >The opposite side of this is that while mechanical engineers don't need >to be machinists, mechanical engineers need to understand machine tools >and manufacturing operations. Agreed -- but it's not the opposite side. Process knowledge is always necessary in order to be an effective engineer. >The other side of this is that we can't TEACH software engineering >without requiring the students become machinists; there's not much you >can teach about programming without teaching programming. Here is where we might part. I agree with the second clause, but am not sure about the first, which seems to imply that the mechanics of software engineering is programming. If this is true now, will it always be? And why are there good mechanical engineers who are not machinists, good EEs who couldn't design and lay out an IC, etc.? >The solution in my opinion is that we have to make sure that part of >teaching computer science is teaching the low-level skills that have >been considered part of software engineering up to now. I don't think >any computer science grad ought to be able to graduate without >understanding how to write a good program at the 1000--10,000 SLOC >level. Here you seem to have equated CS with SE. Is there no difference? What does it mean to have a 'good' program? Can we measure that? Will it scale up to 1,000,000 SLOC? >...But when an engineer designs a bearing that is needed, which is not >in the parts catalogues from the acceptable suppliers, but which is >within the common state of art, he is not doing science: there is no >hypothesis/experiment cycle going on. An EE can buy some resistance wire and wind his own resistors, but he would try like heck to avoid that and wouldn't consider marketing the results. Consider the technology that he would have to know in order to guarantee the performance of them. There would be a great deal of science and experimentation involved. In fact, my view of a good systems EE was one who knew better than to design his own switching-regulator power supplies. >Similarly, all engineered software is created from known models (check >e.g. the plans work of Soloway) and most other algorithms are designed >on the basis of existing models as well. You are down at a very low component level, here, what we consider to be implementation. Systems engineers try to stay out of it. >In designing a bearing, a designer had better know about the properties >of other bearings, and of the materials that make them up. Right, but isn't this a speciality generally out of the reach of the average mechanical engineer? >>>I don't think anyone is under the impression that you are learning >>>engineering when learning about finite state automata and the executable >>>models of them. >> >>This is true for you, but not for those who suggested (and still insist) >>here that courses in OS and compilers were good ways to learn software >>engineering. >> >I *am* glad that we have your infinite knowledge to draw on, Richard. Please, let's not trade gratituitous comments. Your next statement shows you knew exactly what I meant: >That is ever so much clearer now. Funny, I had thought that the others >were mostly arguing that OS etc courses were a good place to *present >examples* of software engineering and its problems. But being a mere >mortal, I can only draw on what I read, not on my intimate knowledge of >what other people know. OK, here is what they said: In article <7036@hubcap.clemson.edu> A. Jeff Offutt writes: >Here's one of my ideas for a perfect software engineering project: > An operating system. ...Another one: A compiler Notice that he did NOT say computer science project. In article <4251@pegasus.ATT.COM> Paul S. R. Chisholm writes: >What good are compiler courses? Well, when writing code I want to run >fast, I always feel more comfortable when I know more or less what the >compiler is going to turn my code *into*; and the only way I can do >that is at least read about compiler implementation techniques. Notice that he is writing code, i.e., doing implementation and not design. Drawing on what I read and just presented, I will stand by my analysis of the intent. Let's just disagree on our readings of the above... >I'm not wedded to the *names* of the courses; call them Larry Moe and >Curly for all that I care. But many of the theory topics presented must >(in my opinion) be reinforced with realistic examples, and courses like >compilers, operating systems, and oh, data base courses are a convenient >place to do this. Not one of those will prepare you for emgineering your first MCCR system, believe me! Good luck! >So I don't know -- what doesn't the list include? What do you think is >*not* appropriate for a software engineer to know? >Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm) Well, the last question has the appearance of, but not the unassailability of Motherhood. EEs who specialize in radar design do NOT have all of the scientific knowledge (beyond principles of E&M) necessary to design heavy rotating machines. There is a fundamental gap between being able to understand (even intimately) how an operating system works and how to engineer one. Rich -- When you can measure what you are speaking about, and express it in numbers, you know something about it. Lord Kelvin rsd@sei.cmu.edu -----------------------------------------------------------------------------
crm@romeo.cs.duke.edu (Charlie Martin) (12/01/89)
In article <5132@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: > >Charlie, you start off OK, but include sarcastic remarks later in your >article. I will try to close most of this discussion down: > I was trying to be pointed without being personally offensive, so please accept my apologies for anything you took personally. This is first draft stuff and tone-of-voice is hard to get across. >> >>The opposite side of this is that while mechanical engineers don't need >>to be machinists, mechanical engineers need to understand machine tools >>and manufacturing operations. > >Agreed -- but it's not the opposite side. Process knowledge is always >necessary in order to be an effective engineer. Agreed one hundred percent! > > >>The other side of this is that we can't TEACH software engineering >>without requiring the students become machinists; there's not much you >>can teach about programming without teaching programming. > >Here is where we might part. I agree with the second clause, but am not >sure about the first, which seems to imply that the mechanics of software >engineering is programming. If this is true now, will it always be? And >why are there good mechanical engineers who are not machinists, good EEs who >couldn't design and lay out an IC, etc.? Wow, about 17 good questions here. Let's see: I think it is true that the "machining" of software engineering is and always will be "programming," and as with Brooks's No Silver Bullet paper, I am suspicious that the process that leads to the final realization of the system will always be complex and always will require substantial detailed effort. I don't think it is true that all programming is or will be software engineering; in fact, my opinion of the future of programming is that "languages" very specific to very limited domains -- like spreadsheets -- will eventually replace general programming with user-defined and user-modified specifications that happen to be efficiently executable. Once we grow past very limited programming domains, I think we begin to hit very basic softs of computation-theoretic and cognitive limits, which in turn I think account for Brooks's NSB phenomenon. The reason there are good MEs who are not machinists I think is that there are good machinists who aren't ME's. The skills really are different, but a good machinist has no reason to feel ashamed of their skills. (And good tool and die makers usually make as much or more than even the most experienced engineers in that kind of environment.) As far as whether it will always be true that we must teach programming to teach software engineering, I don't know. On the one hand, by analogy it seems not; on the other hand, unlike a mechanical engineer, we run into Church's Thesis in software engineering: a mechanical engineer can manipulate drawings and strenth-of-matericals rules and ODEs without manipulating the basic materials; on the other hand, anything that we manipulate that describes a computation is in itself a kind of or model of computation. So my *guess* is "no, but someday we'll have better programming notations that will make programming better and/or more intuitive." The formal methods work that I have been doing recently seems to me to be aimed in that direction, but there is a long long way to go. I don't even have a hint of what the end product will be like. >>.... I don't think >>any computer science grad ought to be able to graduate without >>understanding how to write a good program at the 1000--10,000 SLOC >>level. > >Here you seem to have equated CS with SE. Is there no difference? What >does it mean to have a 'good' program? Can we measure that? Will it scale >up to 1,000,000 SLOC? > I mean instead to suggest that some large part of what we allocate to SE ought to be part of CS, thereby leaving us alone to figure out things like what the problems of scale are, and find solutions. The kind of "good" I'm thinking of is in part aesthetic (dammit) and so, no, I suspect we can't measure it. But I think we'd agree on the generalities: few non-standard transfers of control, layout of the code on the page that emphasizes important parts of the code structure, modularity and design that raises the probability that a change will require minimal changes (information hiding, paramterization, etc.) These kinds of things seem to scale badly; conversely, there are a number of things that seem important only after size > 10^4 SLOC. One reason that I suspect the "code hygiene" stuff is not "software engineering" is that I think it is important on a much lower scale than the other topics of SE are. > >>...But when an engineer designs a bearing that is needed, which is not >>in the parts catalogues from the acceptable suppliers, but which is >>within the common state of art, he is not doing science: there is no >>hypothesis/experiment cycle going on. > >An EE can buy some resistance wire and wind his own resistors, but he would >try like heck to avoid that and wouldn't consider marketing the results. >Consider the technology that he would have to know in order to guarantee the >performance of them. There would be a great deal of science and >experimentation involved. In fact, my view of a good systems EE was one who >knew better than to design his own switching-regulator power supplies. > I think we've reached a point of arguing where the optimal trade-point is, itself an engineering decision. But every engineer needs to deal with "build or buy" unless dealing with nearly trivial problems. > >>Similarly, all engineered software is created from known models (check >>e.g. the plans work of Soloway) and most other algorithms are designed >>on the basis of existing models as well. > >You are down at a very low component level, here, what we consider to be >implementation. Systems engineers try to stay out of it. > > >>In designing a bearing, a designer had better know about the properties >>of other bearings, and of the materials that make them up. > >Right, but isn't this a speciality generally out of the reach of the average >mechanical engineer? > I'm not an ME, but that's not my impression from talking to MEs. (I don't recall, did you say you were? May have been someone else.) In any case, my father in law is a mechanical engineer, and tells the story of needing a bearing, designing it, and then having his supervisor point out that he could have had one from the parts catalogue over his drafting board. Again, I think we've worked down to the point of considering where the optimal point of a trade off lies. A person who specializes in designing bearings will necessarily know more about properties and current art than someone who just needs one that doesn't show in the catalogue; if the ebaring will be a safety-critical component, then it is probably the correct engineering decision to hire a consultant or find an expert in the company. On the other hand, even I don't need an expert to tell me how to design a poured-babbitt bearing to replace the bearing in my ancient lawnmower that can't be purchased any longer. (I can look it up with a little effort, and the result is not critical in any meaningful way.) > >Drawing on what I read and just presented, I will stand by my analysis of >the intent. Let's just disagree on our readings of the above... > Actually, given your comments I think there is an interesting question here: are techniques for writing (maintaining) 1000-10,000 SLOC programs part of software engineering vs. being part of computer science? My opinion (as I said) is that they ought not be; on the other hand, I feel constrained to accept what appears to be the common definition, at least without making an explcit argument for my own. I'm sorry, but I just munged the remaining stuff from you, so I'll paraphrase rather than recovering it. (Stupid vi....) In any case, the last part of your message first suggested that the basics of operating systems, file structures etc wouldn't be any use while designing your first MCCR system. The acronym isn't familiar to me; tell me what it is and I'll tell you if I believe it. I find it unlikely, since I find it hard to imagine a program that doesn't use *one* of the basics of any of the topics I mentioned as seeming essential. But I can't argue on that basis. The last issue is the question of what a software engineer needs or doesn't need to know. My expectation with reference to this was based on current techniques and current art, not based on the assumption that *someday* people will be able to software engineer without knowing how to program, and I think it's still a valid question. The way I understood your response before I mashed it was essentially that the topics of a course in operating systems are not useful for software engineering, but that it was a motherhood statement that people ought to know everythig about everything; that it was unnecessary to know anything in particular about designing the physical carriage for a large antenna if you're designing the RF paths. But what this comes down to is the assertion that designing an operating system is "a different kind of" software engineering than designing these MCCR systems, for example. But this implies that MCCR system designers need to know something as different from what operating systems designers need as Young's modulus is different from cavity resonance. In other words, it seems to assert that MCCR designers don't need to know about operating systems design because they aren't designing operating systems. Since this is a paraphrase, I can't assert that it is circular reasoning, but my recollection of it sure seems to be. I don't accept the axiom that operating systems are that difference; I think there is good reason to assert that they are not, and that they in fact (a) illustrate good SE principles, and (b) are good things to know about in terms of the core knowledge a software engineer needs. So far, it *seems* that I and others have offered a number of reasons for this; the counterargument seems to be that operating systems courses teach things that aren't needed for people who build something else. All of this presumes that every operating systems course is presumed equal, which isn't fair. On the other hand, all the OS courses I've taken, and all the OS books I've read, illustrate (more or less well) much more general concepts about design of large or time-critical or performance-critical systems that I think very SE needs. So I'd still like to know: what was in YOUR OS course that shouldn't have been? If so, is it essential to a concepts of OS course in the sense that an OS course wouldn't be recognizable as an OS course without it? Or was it an accident of that particular text, that particular instructor, or the tools the instructor had with which to teach labs? Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)