From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,1042f393323e22da X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,1042f393323e22da X-Google-Attributes: gid1014db,public From: jmartin@cs.ucla.edu (Jay Martin) Subject: Re: Any research putting c above ada? Date: 1997/05/05 Message-ID: <5klamg$24da@uni.library.ucla.edu>#1/1 X-Deja-AN: 239650681 References: <5ih6i9$oct$1@waldorf.csc.calpoly.edu> <3359e813.340466234@news.pacificnet.net> <5iri6b$jn0@bcrkh13.bnr.ca> <5k60au$gig@bcrkh13.bnr.ca> <5k8b0p$25f2@uni.library.ucla.edu> Organization: University of California, Los Angeles Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.ada Date: 1997-05-05T00:00:00+00:00 List-Id: >In article <5k8b0p$25f2@uni.library.ucla.edu> jmartin@cs.ucla.edu (Jay Martin) writes: > > Huh? By definition, if the subject has to do with practical > > software construction then that is in software engineering. If it > > is worthless theoretical masturbation, then that of course lies in > > the domain of Computer "Science". > If you want to say that software engineering is about practical >software construction, fine. But if you don't know how to navigate >around the slippery shores of the halting problem, or NP-completeness, >you will spend an awful lot of time trying to solve problems that are >not practically solvable. Heh, if go my "definition" then practical algorithm design is software engineering just like mechanical engineers can use the concept of momentum from physics or equations from mathematics. But the difference is that SE concentrates on actual implementation of practical algorithms to solve real problems while CS would concentrate on the mathematical theory. Though sadly it seems the real Software Engineering field seems to be concentrating on "software management" leaving technical issues to CS who mostly punt. There is nothing magical about the "halting problem" or "NP (We think its exponential but we don't have a cool proof) completeness" that can't be understood by programmers with minimal theorizing. The "halting problem" is proved with like a 5 line proof. Computer Science stole most of he practical aspects of this stuff from Operation Research anyway. > Notice the wording there--if you know how >and where to draw the line, you can solve your problem without >generalizing it into a "simpler" case that is out of reach. I don't think it is so hard: If generalize to exponential problem => stop. If have exponential problem => try to simplify/restrict problem to non-exponential probem. If have exponential problem => pull approximating heuristic program out of ass or try a some search techniques like simulating annealing. Do you need a PHD in CS theory to do this? Probably not. >Or, if >you know what you are doing you can, with little trouble, solve an >NP-complete problem. For example, Ada compilers are required to solve >bin packing problems. In general, the bin packing problems the >compiler sees are easy to solve, and if you go to the effort of >embedding a large and difficult problem in your record representation >clause, well compiling it might take a while. Seems more like practical software engineering to me than theory. You have an exponential problem so you use some approximating algorithm that solves the problem for simple cases but punts optimality for complex cases. > Another example in an Ada context is the discussion we just had >about elaboration order. In theory, finding a "good" elaboration >order for any Ada program is equivalent to the halting problem. In >practice, any compiler can find a legal order, and most compilers will >find a "good" order for most programs. (A good order here is one >which does not raise Program_Error for any input.) Sounds like specific problem heuristics again, not theory. How much does this theory actually come up in real software development? When it does how much can be easily pulled out of standard references? Is it justified in Computer Science to only concentrate on and worship theory in some pathetic case of "Physics Envy" while basic software engineering research is not done and basic SE skills are not taught contributing to the reason why the whole software field to be a dispicable sewer? I think not. Jay