Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!udel!rochester!rit!mjl From: mjl@cs.rit.edu Newsgroups: comp.software-eng Subject: Re: CS education [engineering, mathematics, and computer science] Message-ID: <1417@cs.rit.edu> Date: 27 Nov 89 15:49:19 GMT References: <1408@cs.rit.edu> <34795@regenmeister.uucp> Sender: news@cs.rit.edu Reply-To: mjl@prague.UUCP (Michael Lutz) Organization: Rochester Institute of Technology, Rochester, NY Lines: 107 In article <34795@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes: >From article <1408@cs.rit.edu>, by mjl@cs.rit.edu: >> Since I started this thread, let me toss out a few more thoughts. I >> think the most important contribution of mathematics to computer >> science/software engineering is its mode of inquiry. I'd say that it >> is the approach to problem solving -- defining a specification or >> reasoning about a program in the context of a rigorous axiomatic >> system -- that most closely ties mathematics and computing. > >My observation and experience is that this relationship is historical in >origin. It traces to the fact that most computer science departments >were spun off from mathematics departments. > >...From what I saw, it appeared that many of the >people who moved from math to computers did it not because they were >interested in computers but they were not particularly successful at >math. Well, if this is the case, then it's one of history's serendipitous accidents. And you slander those who did "move to computer science from mathematics." Certainly there is a range of abilities amongst those interested in computer science theory, but that's no different from mathematics itself. And I think we can safely say that Dana Scott, Michael Rabin, Richard Karp, and others like them are first-rate mathematicians in their own right. Unlike you, I don't denigrate my mathematical background as preparation for computer science and software engineering. I just wonder whether software engineers can make do with a variant of this background that emphasizes its application rather than the underlying formalism >There are two other sources of the mathematical misapprehension. The >first is that the earliest applications performed with computers were >mainly numerical analysis problems. This is a red herring. While numerical analysis is a particular application of computers closely tied to a branch of traditional mathematics, numerical analysis itself has had little influence on the direction of formal methods. You might as well say that optics had a huge impact on computer science because the ability to compute FFTs led to the design of more sophisticated lenses. >> In this respect, a good dose of discrete >> mathematics or basic modern algebra is appropriate, not so much because >> of the topics per se, but rather because the form of the proofs in >> these domains maps most closely onto the formal models of computation. > >Perhaps this is another way of saying that the formal models of >computation have been copied from that of modern algebra. Hey, if you've got a good model, why not use it? Group theory has been put to use in the design of error correcting codes, so why shouldn't we use abstract algebra to model computation if it fits (I'd argue that it's a pretty good fit for functional specification and design). >> (Of course, the topics themselves contain gems of abstraction and >> generalization, for those willing to do some mining). > >I found modern algebra to a little too long on recipies and a lot too >short on theoretical structure. Then I feel sorry for you. My course stressed the logical progression of ideas, with rigorous proofs all along the way. My instructors focused on the deeper intrinsic relationships between concepts with little surface similarity. Did you use Birkhoff and MacLane's "A Survey of Modern Algebra"? All in all, I took 4 semesters of standard algebra courses as well as a seminar in my senior year on group theory. Sounds esoteric, but it was superb preparation for my graduate work in CS (both *theory* and *practice*). >> What bothers me most is that this implies a significantly deeper >> understanding of mathematical principles than is required by other >> engineering disciplines. > >Which could be reasonably taken to imply that mathematical principals >have as much to do with software engineering as it does with the other >engineering disciplines. Or it could imply that software engineering is significantly different from other engineering disciplines in the *type* of mathematcal foundations it requires. David Parnas' curriculum, mentioned by David Lamb in a previous posting, implicitly disagrees with this assessment, but then I disagree with his curriculum :-). >> Or, to phrase it slightly differently: >> Formal methods of software engineering require the engineer >> to think like a mathematician. This is untrue of any other >> engineering discipline I am aware of. Why the discrepancy? > >The discrepancy is clearly in the formal methods. They have nothing >functional to do with software and nothing functional to do with >engineering. I STRONGLY disagree here. I think the formal methods have a lot to do with software engineering, I just don't think they are yet in a form that is approachable by most practitioners. It is not at all unusual for mathematical theory to precede its engineering applicability by decades. Or centuries -- look at the time lapse between Fourier's work and the development of computers and the FFT that made this work applicable to realistic problems. If I have a problem with formal methods, it is that the proponents seem to believe they're at the "FFT" level already. Mike Lutz Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {rutgers,cornell}!rochester!rit!mjl INTERNET: mjlics@ultb.isc.rit.edu Brought to you by Super Global Mega Corp .com