Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Computer Science" is Not Science and "Software Engineering" is Not Engineering

geocities.com

Post reply on HN
Print view View original

81–90 of 93 posts

Re: "Computer Science" is Not Science and "Software Engineering" is Not Engineering

#81

Post by betawolf33 »

SeanLuke wrote: post #70
betawolf33 wrote: post #39

The contention that Computer Science is not a science because on opening a CS textbook you get confronted with a number of mathematical concepts seems a fairly ridiculous one. The same argument could be made to say that Physics is not a science, after all. The problem is that there's a conflation in most people's minds of the terms 'computer science' and 'programming'. Computer Science courses teach you how to progra…

I think that this is basically saying "Computer Science is science because it uses science." But Electrical Engineering uses just as much scientific method in its research papers as CS does. Does this make EE a scientific field? To my mind, every engineering field has researchers who use the scientific method every day to produce stuff for the engineers to use. The field is not defined by those researchers -- it's de…

Interesting perspective. My thought is that CS is what we call what those researchers do to differentiate it from what the users do.

Creating a new tool through the scientific method would be the science, whereas implementing a system or product would be the 'software engineering' - the application of the science. I don't have a good basket term for both research and application, but I'd probably go for something like 'Computing'.

This could be applied to any engineering field as well, it's just a matter of naming practices. I'd be happy to admit that 'electrical engineering science' existed (though the name is horrible) to refer to the research in electrical engineering.

Re: "Computer Science" is Not Science and "Software Engineering" is Not Engineering

#82

Post by ten_fingers »

yanatan16 wrote: post #32

Quote from http://wikipedia.org/wiki/engineer "An engineer is a professional practitioner of engineering, concerned with applying scientific knowledge, mathematics and ingenuity to develop solutions for technical problems. Engineers design materials, structures and systems while considering the limitations imposed by practicality, safety and cost. The word engineer is derived from the Latin roots ingeniare ("to contr…

> Engineers design materials, structures and systems while considering the limitations imposed by practicality, safety and cost.

That's where I begin to say that computing comes up short as 'engineering':

The problem is that too often in computing the "design" work, just the design work alone, before construction, cannot really tell what the "practicality, safety and cost" will be. So, too often in computing we have to build the system and then test it to know what its "practicality, safety and cost" are. That was often the situation in the construction of medieval cathedrals: Some examples stood; some fell down; some on the borderline got weaker over time. Apparently eventually the strong cathedrals were built mostly drawing from experience, that is, closely copying what had already worked before. That technique is trial and error and copying and not really the 'design' of engineering.

If bridge engineering were the same as software construction, then just to know how strong the bridge was we'd just have to build the bridge and then test it. For rocket engineering, to know if it could reach orbit we would have to build and launch it. Indeed, instead, in rocket engineering we can determine the rocket trajectory that will put the maximum payload into the desired orbit.

I explained further in

http://news.ycombinator.com/item?id=4356303

in this thread.

Re: "Computer Science" is Not Science and "Software Engineering" is Not Engineering

#83

Post by AYBABTME »

Niten wrote: post #72
barik wrote: post #44

Earlier quoted context omitted.

"As someone with an engineering degree, it does irk me to constantly hear programmers referred to around these quarters as 'engineers', it's extremely introspective, and IMO a little disrespectful." I'm not certain it has anything to do with the physical world; after all Industrial Engineering is considered a valid disciplined that is entitled to an Engineering license, and many of the IE's I know might be better cha…

> Perhaps the solution is to have legal weight (perhaps like 'Lawyer' or 'MD') behind the title, as countries like Canada have (the US has this to some extent, but it's not nearly as strong). But here you're taking it for granted that professional licensure of software engineering is actually desirable, which is not at all agreed upon. Among the organizations against the notion are the ACM.

I think one of the problems is that professional licensure of software engineering would require the codification and legalization of a set of knowledge and standard agreed upon. This set of knowledge would be used as a metric of what is expected from an 'reasonable' engineer, thus making any professional engineer liable toward society (and more specifically toward courts) to meet those standards.

The problem in this is that nobody agrees on this set of standard/knowledge (a Body Of Knowledge). For instance, if the document and the experts required to testify in court define that "a reasonable engineer has to use a waterfall methodology", then you could be liable for using an agile methodology (that's just an example). The domain being so young, there is not yet an agreed upon profile of what a 'reasonable software engineer' might be. The SWEBOK[1] attempt to define such a profile was initially supported by both IEEE and ACM, but - if I remember well - the ACM dropped their support in face of these concerns.

I think both organizations support the legalization of the "Software Engineering" field (and perhaps title), but also recognize that the field is not yet mature enough to be properly defined and regulated.

Disclaimer: I do not have sources for my claims on IEEE and ACM's positions on the matter; I merely read about it a few months ago. However, you can find interesting conversations on the subject by googling 'SWEBOK'.

[1]http://www.computer.org/portal/web/swebok

Re: "Computer Science" is Not Science and "Software Engineering" is Not Engineering

#84

Post by lvh »

barik wrote: post #66
padobson wrote: post #19

So, building a bridge is an engineering endeavor. Does this mean that drawing blueprints for the bridge is not engineering? What about working a crane? Laying brick? Sealing pavement? Sweeping the bridge? Could you say that an AWS datacenter is not a feat of engineering? Certainly writing the software that powers it is as important as any other discipline, and every piece of its execution has definable metrics to mea…

"Does this mean that drawing blueprints for the bridge is not engineering? What about working a crane? Laying brick? Sealing pavement? Sweeping the bridge?" Yes. None of these items, strictly speaking, qualify as Engineering work for purposes of licensing. If you are applying for an Engineering license, you will need to subtract these hours from your Engineering experience, and if a large portion of your day-to-day w…

Defining engineering in terms of what a legal definition somewhere undefined (I'm assuming you're talking about the US) seems unnecessarily narrow.

Re: "Computer Science" is Not Science and "Software Engineering" is Not Engineering

#85

Post by kilburn »

ten_fingers wrote: post #80
espeed wrote: post #14

"Underlying our approach to this subject is our conviction that 'computer science' is not a science and that its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology ­ the study of the structure of knowledge from an imperative po…

> Mathematics provides a framework for dealing precisely with notions of 'what is.' Computation provides a framework for dealing precisely with notions of 'how to.'" But some parts of math deal "with notions of 'how to'" and there commonly do so more "precisely" than computer science. There are such parts in optimization, control theory, statistics, and numerical analysis. E.g., numerical analysis says how to (1) sol…

Do you have a reference for "(2) how to assign interceptors to targets in the best possible way in guaranteed execution time"? I would love to read that paper!

Re: "Computer Science" is Not Science and "Software Engineering" is Not Engineering

#86

Post by eswangren »

I am first and foremost a software guy, but I work in a systems group. I write hardware device interfaces. I solve problems in the physical world. Motion control, digital imaging, electronics. Many of the problems I solve on a daily basis are problems of physics, yet I solve them (mostly) in software. I think the term "software engineer" applies here. Let's not forget that there are many, many engineers just like me who do not write CRUD and web apps every day.

Re: "Computer Science" is Not Science and "Software Engineering" is Not Engineering

#87

Post by kilburn »

dev1n wrote: post #67
dandrews wrote: post #31

Earlier quoted context omitted.

Agreed about the "engineer" label. My acquaintances at university were engineering students, and they would themselves correct me if I called them engineers - that requires licensure. (They're not even "engineers in training" until they've passed that monster FE.) You betcha, PEs are justifiably proud of the title. We have sysadmins around here who call themselves "Microsoft system engineers". It bugs me, but title i…

This is akin to a philosophy professor walking into a hospital and saying "I'm a doctor." The actuality; the professor is correct. The circumstances of the situation just make for misunderstanding and an apparent disrespect for the medical doctors walking around, from the perspective of the medical doctors. edit: changed the wording

The fun fact about this story is that -at least in my country-, a lot of those so-called medical "doctors" actually are not doctors. They completed medical school and some specialty, but they never completed a research thesis.

Re: "Computer Science" is Not Science and "Software Engineering" is Not Engineering

#88

Post by barik »

lvh wrote: post #84
barik wrote: post #66

Earlier quoted context omitted.

"Does this mean that drawing blueprints for the bridge is not engineering? What about working a crane? Laying brick? Sealing pavement? Sweeping the bridge?" Yes. None of these items, strictly speaking, qualify as Engineering work for purposes of licensing. If you are applying for an Engineering license, you will need to subtract these hours from your Engineering experience, and if a large portion of your day-to-day w…

Defining engineering in terms of what a legal definition somewhere undefined (I'm assuming you're talking about the US) seems unnecessarily narrow.

Then do you believe that the tasks outlined above are in fact Engineering. If so, why do you think so? And what is your definition of what would constitute Engineering versus non-Engineering efforts?

It's true, my definition is US-based (maybe even based on a single state), and even more narrowly, it's based on US PE licensing requirements, which isn't even necessary for many Engineering fields these days. But at least I'm not dodging the question, here.

As an example, drafting is billed at a different rate than Engineering precisely because drawing in CAD itself is generally not considered Engineering.

Re: "Computer Science" is Not Science and "Software Engineering" is Not Engineering

#89

Post by ten_fingers »

kilburn wrote: post #85
ten_fingers wrote: post #80

Earlier quoted context omitted.

> Mathematics provides a framework for dealing precisely with notions of 'what is.' Computation provides a framework for dealing precisely with notions of 'how to.'" But some parts of math deal "with notions of 'how to'" and there commonly do so more "precisely" than computer science. There are such parts in optimization, control theory, statistics, and numerical analysis. E.g., numerical analysis says how to (1) sol…

Do you have a reference for "(2) how to assign interceptors to targets in the best possible way in guaranteed execution time"? I would love to read that paper!

The specific problem is a special case of the 'assignment' problem. First cut, it looks like 0-1 integer linear programming and, thus, maybe in NP-complete.

Looked again, the problem is least cost network flows. That is a linear programming problem. In that problem, if the arc capacities are integers, and in this practical problem they are, then the simplex algorithm can easily start with a basic, feasible, integer solution, and the simplex iterations will automatically maintain an integer solution and, then, find an optimal integer solution which provides the optimal assignments.

When we apply the simplex algorithm to least cost network flows, we get to take advantage of the fact that the problem is not fully general linear programming, and the advantage we can take is huge. E.g., the arcs of a basic, feasible solution form just a spanning tree in the network; the 'entering variable' in the simplex algorithm just adds an arc to the spanning tree and, thus, yields a circuit; we run flow around the circuit in the direction that makes money until the flow on some arc is zero and that arc determines the 'leaving variable'. Using the 'strongly feasible' basis ideas of W. Cunningham, long at Waterloo, we can avoid cycling.

But, the simplex algorithm for least cost network flows, as far as I know, is not guaranteed, worst case polynomial.

However, read:

Dimitri P. Bertsekas, 'Linear Network Optimization: Algorithms and Codes', ISBN 0-262-02334-2, MIT Press, Cambridge, MA, 1991.

and in there, or elsewhere in Bertsekas's work, is an algorithm for least cost network flows and that is worst case polynomial.

Done.

And I covered nothing classified!

And for this thread, we have a "how to" with high precision from some applied math.

Re: "Computer Science" is Not Science and "Software Engineering" is Not Engineering

#90

Post by davidcuddeback »

ten_fingers wrote: post #77

For computing being 'engineering', that is an old sore point with me. I believe that computing should be engineering but so far really misses some key points. Here, close to the article, is an example of some of what is missing: In engineering for, say, a bridge, the design engineer can get quite comprehensive data on the 'engineering properties' of the materials, components, and processes he is intending to use. E.g…

You make a very good point. I had to do a trade study of different microprocessors (for embedded software) when I worked at a more engineering-focused organization, because one of our requirements was that a certain algorithm had to complete in under 30 seconds (or something like that---I don't remember the exact time requirement). One of the things we had to do was try to quantify how fast the algorithm would run on each processor, which as you mentioned was nearly impossible.

We ended up looking up the MIPS [1] and FLOPS [2] for each processor, whether it supported SIMD instructions, and how many pieces of data its SIMD instructions could process in a single instruction. Some processors didn't support floating point math, so we had to estimate how fast it could be emulated with integer registers. Then we had to have some formula to estimate the run time based on this data and the nature of the algorithm (what percentage of the code uses floating point vs integer instructions, what percentage can take advantage of SIMD, etc).

The problem with this is that even the published performance data, such as MIPS, aren't a measure of a single attribute that we can apply in any meaningful way. For example, MIPS is affected by clock speed, which instructions are executed (some may execute in a single cycle, others take several cycles), branch prediction, and cache coherency. How do you quantify stalled instructions? The final execution time is a result of an interplay between the hardware's characteristics and the algorithm's characteristics (as compiled by a certain compiler) over time.

Perhaps a more appropriate approach for software engineering would be statistics. Given normal distributions for MIPS, missed branch predictions, etc, similar characteristics of an algorithm, and perhaps the language and compiler used, then maybe we can give a confidence interval for an algorithm's run-time.

But like you said, in many cases it's probably easier (and cheaper) to just build the algorithm and then measure it.

[1] Millions of (integer) instructions per second.

[2] Floating point operations per second.

[3] Single instruction multiple data.

[4] Not to down-play the difficulty of that task. I'm sure it's very complicated as well.

Post reply on HN