Is Computer Science

My education is in math and computer science. My profession is writing successful computer programs and helping others do the same. My experience is that the education and the profession have little to do with each other. (Now, of course, that isn't true, I learned a couple of million useful things while studying those subjects. But none of the useful stuff was much like science.)

We've been talking elsewhere (BeautyAintMyBusinessNoSir) about how we'll never amount to anything until we start doing science. And we can't call ourselves engineers (oK with me) until there's science underlying what we do.

No complex system today, whether mechanical, electronic, or human, rests in any other than a trivial way upon science. Everything complex is modularized, simulated, tested.

There's materials science that says how strong a beam is, but what you really do is over-engineer, simulate, and let someone else stand underneath.

There's physics underlying chip electronics (and all that cool etching equipment), but all complex chips are modularized, simulated, and have bugs in them anyway.

In computer science, about the only thing we can prove is that traveling salesmen can't find their way from one place to another efficiently, and that unix hackers can't really decode 4o-bit keys by harnessing all the computers in the lab. And the hackers do it anyway, and the salesmen still make their rounds. Computational complexity, arguably the strongest concept in computer science, has little practical real-world value.

This is just naive. Computational complexity is a multi-billion dollar real-business-world issue. Just because you personally don't know anything about how big business applies such things doesn't mean they don't exist. As I said earlier today, don't bother to have opinions on topics that you know nothing of...or as the famous quote goes, absence of evidence is not evidence of absence.
Here's one tiny little example for you: packing trucks, ships, jets, etc, as optimally as possible. Quick, how many billions of dollars were saved just in the last year by applying computational complexity algorithms to that alone, world-wide, compared with if such things were not used? And there are many, many, many, many, many other application areas besides that. -- DougMerritt

Software systems are generally quite huge and complex. The effort of "proving" a system is by necessity be much larger than writing and testing the thing to begin with. The proof is by necessity harder to understand and verify than the program.

What can we do that works? Modularize, test our modules, build our systems from components, and test them. And let someone else stand underneath.

Sorry about that ...

-- RonJeffries

I tend to disagree strongly. If you've ever had to write a realtime system or a realtime oS, or develop mission-critical systems like military software or medical hardware control code, you know that there is in fact a whole lot of science out there to be had. You just need to know where to look. Read Knuth, or The Way of Z, or whatever. There's a lot of utility to computational complexity if you deal with large databases (corporate data mining, medical research, web searching) or cryptosystems or communications and routing. I'm sure there are dozens of other good examples; those just happen to be the ones that my background brings to mind.

Just because you don't use astrophysics doesn't mean it isn't useful in the real world. No, web designers and security engineers don't need computational complexity. I don't need color theory, nor do I need knowledge of generic attack schemes. They're still useful. Just not to me. Never mistake ignorance for absence, nor personal nonutility for nonutility.

Academia is very, very good at weeding out mental masturbation in under a generation. Knuth is Knuth for good reason.

-- JohnHaugeland?

Those are about "models that have proven useful in practice". It's almost a form of, 'Model X worked well for rocket A, therefore we'll use model X for rocket B also.' Whether that is "science" is another matter. Generally it's a management decision, and managers don't often document and codify their decision process such that we don't really know.

Aaargh! I never said we wouldn't amount to anything. By and large, what I said was that we never seem to test our claims re: how to build software.

We build software. We unit test our code, we send it out to the usability people, we do dry runs, we deploy it in limited arenas, we experiment with alternative approaches til we find the one that seems to work best, we watch we hope we sweat and we fix stuff until it does what it was supposed to do the first time round.

This is Good!!!

Do we do the same thing at the meta-level? Do we actually step back and say "Whoa there, GradyBooch. You claim that the right way to build software is via objectory. And you, Ron Jeffries, are an advocate of extreme programming. Can either of you offer me convincing evidence, not just anecdotes and vague appeals to beauty, but actual comparative experiments that evaluate your approaches? If not, why not?"

Do we do the same when we're talking about good code? Do we have actual non-subjective criteria ? There's loads of design patterns and there's loads of examples of building things, but are there studies showing why (beyond intuition and a sense of smell) certain ways to do things are better than others? Kent Beck made a wonderful point on InheritDontBranch [PolymorphismVsSelectionIdiom]. I answered the question, and mentioned that I wasn't sure why my answer was a good one. All I could think of were aesthetic reasons.

and after a brief sidetrack, Beck came up with

The if structure is bad because I cannot extend it without modifying it, thereby putting existing behavior at risk

Which is a much much much better reason for preferring one structure to another than "It's aesthetically pleasing."

I'm not saying *we* have to be scientists; I'm wondering if there is any science underlying the ways in which we do things.

In a sense, this does grow out of previous discussion about Computer Science. People have complained that an undergrad CS degree doesn't cover the right stuff. And I agree with that. What I don't understand is what this BeautyIsourBusiness? stuff brings to the table (and why people seem to regard it as a suitable replacement for actually testing various hypothesis about software development).

-- WilliamGrosso

In the novel TheDeadline, the protagonist tries to run parallel projects to test some hypotheses. The author makes the comment that people would love to do this, but who is really going to pay money to get a statistically significant number of teams to develop the same exact software under controlled conditions in order to do that kind of testing? -- MichaelFeathers

We know how to do this--it's research that could be done in universities. It would be fairly straightforward to put together controlled tests of various "methodologies" with suitably detailed objectives and test criteria. The only problem is that it would take a lot of work and many tests to factor out things like programmer competence. We all know how computer people feel about work: we got into this business to get machines to do it. --MarcThibault

But what exactly would such studies measure? And how would maintainability of the code be measured? I think following actual projects may be a better approach so that realistic change scenarios are used. I suspect that if some kind of Caper Jones productivity metric is used (features per hour) and developers are allowed to use their favorite tools, then Meta-heavy languages and techniques such as Lisp and Tcl would probably "win". However, not many developers are skilled in meta techniques and employers generally don't want them because they are harder to find or train into, and tend to not get along well with "suits".

If you can't measure it, what is it? You can measure maintainability by introducing errors and/or requirements changes and measuring the effort needed to respond to them. You don't need to invent productivity units. The challenge was related to methods, not languages. The appropriate experiment would involve the combinations of various methods, many tasks, and many developers in various governance arrangements.

The "favorite tool" and "favorite language" factors would have to be factored out by appropriate controls. If you are looking at overall effectiveness, you have to include learning curve and competence effects. "Discovering" that extra-intelligent, highly-trained developers using very high-level meta techniques are also highly productive would tell us nothing of value. What we want to know is how the choice of technique and organization impacts the effectiveness of a team of ordinary developers using common tools. We have no interest in the productivity of academics using Lisp to build yet another language parser. --mt

Running parallel projects is only one way to verify that discipline A is better than discipline B. Another way is to have companies that use discipline A survive and companies that use discipline B die. or not...

IsComputerScience? Well, I've heard people say that mathematics is the queen of sciences. In that sense, I'd say yes. An object oriented program is a practical piece of logic. If we've been around for a while, our guts tell us whether a piece of code is good or not. William's guts told him above, and Kent pointed elaborated the intuition: one of the things that makes it good. There is a kernel of truth at the center of occamsRazor, DoTheSimplestThingThatCouldPossiblyWork, and mathematical elegance. IMHo, if there is science in all of this, it is like a logic of form and structure. -- MichaelFeathers

2 bits: science is invalidating hypotheses by devising empirical tests in order to restrict the range of hypothesis. Engineering is employing whatever hypotheses have not yet been invalidated by science in order to effect social change. Computer Science exists; Software Engineering exists; their relationship is, or should be, complementary. CS tells SE what tools might work, and SE builds working tools. -- PeterMerel.

This is not done often, and it's a shame. I'm not sure it would be computer science, but whatever kind of science it is, it'd be valuable. With very rare exceptions, there aren't any controlled experiments. What we can do is talk about what we've observed. We think experimentally in XP: we try things, observe results, change things again until we get what we want. Beyond that ... not yet. -- RonJeffries

It's amazing to what extent this is not done in ANY discipline - even scientific ones. Medicine, of all things, is only now pushing for "evidence-based" practice. Current medical practice is usually based on accumulated wisdom and extrapolation from very restricted scientific experiments, but not on rigorous double-blind comparisons of treatments. You would think that it is but the fact is it is too expensive. MichaelLewis?' book "MoneyBall?" makes this point well. Even in baseball where, there are stats galore, all the decisions about hiring, managing, training, everything, are made by the seat of the pants by old baseball guys. Only recently have the cybermetricians begun to change this. The only industry I know of that rigorously examines as much data as possible to determine the best course of action is the financial arbitrage business. So I don't think software is at all peculiar in this regard. It's as "scientific" as anything that is not academic science, that is, not very scientific at all. -- PeteProkopowicz

[Kent said, The if structure is bad because I cannot extend it without modifying it, thereby putting existing behavior at risk] Which is a much much much better reason for preferring one structure to another than "It's aesthetically pleasing." -- WilliamGrosso

Well, it is, yes. But the reason BeautyIsOurBusiness, in my opinion, is that it is quite possible to train the inner eye to see what we come to call "beauty" in a design or code, and, also in my opinion, beautiful systems are "better" in the objective sense that Kent reaches in his statement.

It is quite difficult to reach down to the kind of simple reason Kent states: I know this because in doing XP I've been called upon to do that a lot. What I've experienced in learning this process is that the rules we have devised help produce code that is objectively good by every objective standard we can find. What I've experienced is that "Listen to what Smalltalk is telling you", as you begin to get it, educates you to sense early when you are deviating from real quality.

In short, I hold that it is very true that Quality = Beauty. -- RonJeffries

Here is another example like Kent's, this time about hierarchies: You should keep hierarchies shallow because

Classes deep in a hierarchy are defined relative to all their parents, so that they cannot be easily understood in isolation. So they are difficult to use and hard to change.
Because they carry so much context, they cannot be easily reused elsewhere.
Deep hierarchies are hard to evolve because making changes to parents in a hierarchy can have mysterious effects on their children as the children's context changes.
It is hard to resolve the tension between hiding implementation decisions in the parent, and defining a child by a small change to the implementation. Hierarchies get convoluted because of this schizophrenia, especially when different people are involved.
There are different reasons to derive a class from another. In a complex hierarchy, these reasons become hard to distinguish, so the hierarchy loses architectural coherence.

This is also a reason to prefer composition over inheritance: two independently understood concepts are easier to combine and take apart, than one concept defined only in relation to another. Further, you can also reify the composition itself.

In short, I hold that it is very true that Quality = Beauty. -- RonJeffries

I find it hard to tell whether reasons like this are about quality or beauty; as a rule, beautiful programs are elegant, simple, and easy to understand once you have grasped their philosophy. Is "easy to understand" quality or beauty? -- AamodSane

It's both. -- BillJamison

If an expression of something (e.g. a program) is very repetitive, it can be easy to understand even though the repetition makes it ugly. Conversely, a highly "compressed" expression may be seen as beautiful once it is understood, but take considerable time or effort to understand. -- David Hopwood

see ShallowHierarchies

-- WilliamGrosso

Even if there are hard-science principles under computing, they don't generate new stuff. Judgment is important because all the work gets done, not on the science dimension, but on the engineering dimension. Engineering works from experience-based rules more than it does from hard principles. I believe that while it would be nice to do experiments between methodologies, you would be doing social science, not real science. Far as I'm concerned, the best you can do now is listen to Grady, listen to Kent, try it, and do what works for you. -- RonJeffries

Art and Science; Beauty and Truth. Can the monks teach us about these things? The meaning of the term science has narrowed to mean empirically falsifiable. It used to have a broader meaning of anything rationally falsifiable, and thus, mathematics was considered a science.

Likewise, art has not always been limited to the fine arts. That you have a Bachelor of Arts degree harkens back to a time when grammar and logic were numbered among the seven liberal arts. Then term art referred to the honest skill of the worker, not the thing hanging on museum walls.

If it is true that logic is an art but mathematics a science, we need not suffer from physics envy in speaking of the computerists art.

Modern engineers may enjoy the what ancient monks have to teach us about art as an intellectual virtue in http://www.nd.edu/Departments/Maritain/etext/art1.htm . When reading that essay, bear in mind the Maritain uses 'art' and 'science' in the older broader meaning, not the narrow modern meaning. -- AlanWostenberg 9/98

Art and Science; Beauty and Truth

Art does not need to be beautiful, just made by man. or if you're going for a less precise definition, made by man to communicate meaning of thematic importance. Science never deals with the truth, per se, but only what is supposed to be true ala the PessimisticInduction?.

Art and Science; Beauty and Truth. Can the monks teach us about these things?

I believe the QuotationOnBeautyFromPlatosPhaedrus is relevant to this question. Maybe not, but it seemed connected.

I think IsComputerScience == true, mostly because of the very fact that it is not quantifiable. If you give one thousand programmers who don't know each other the same language to use and the same exact specification, you will get one thousand distinct solutions with none that are alike. So, since much of science has to do with theoretical explanation, discovery, observation, and experimental investigation, I think it is perfectly reasonable to consider (specifically the development of software) as a science and an art. I'm just not so crazy about the "Computer" part of ComputerScience - some other word might be better - Software?, Programming? ...ah, who cares, its all just semantics anyway. Remember that (just like programming) much of the research into higher dimensions, string theory, and so on are also unquantifiable as well.

Programming will never be quantifiable (much less reproducible) until our programming languages change radically. Right now we mix algorithmic (component creating) features and compositional (component using) features together in a single language. Do bridge builders create their own nuts and bolts? When building a house do we mill our own 2X4's? Since we mix these (component creation and component use) in a single language, we are prevented from taking common, proven, and predictable constructs (like square, rectangle, or circle) and composing them into reproducible systems.

Until that day comes, a programmer is better off embracing the unquantifiability of existing languages rather than fighting it - use this weakness of CS as a creative strength. We can't achieve predictable development until we have the tools that allow even ten separate programmers to come up with the same solution. Man, I doubt even a single programmer could reproduce a system the same way twice without consulting their old source code!! Now, if we can't even reproduce our own systems, how could someone else?? I seriously doubt that quantifiable engineering will happen within our lifetimes - certainly not with any of our existing programming languages. -- RobertDiFalco

Speaking of Nuts and Bolts... didn't CharlesBabbage have a problem because there were no standards for nuts and bolts at that time? And similarly plumbing got easier with the American invention of standard fittings and tools (I keep an advert for these above my desk Circa 189o). The whole idea of ``2X4`` is that it is a standard piece of wood. Similarly with chips. Somehow research and development on software components has not produced as many standard components. But time may tell. -- DickBotting

Hey, AWESoME! I would love to have such an ad. -- DanielKnapp

This is not an analogy. Algorithmic would mean to design the concept of the nut or plank, and composition the actual manufacture. A builder may very well mill his boards, and a programmer write his own libraries. Scientist may have come up with both the concept & theory behind threads and the methods for calculating bridge strength & other construction methods. These are analogous in pairs. They are not being mixed.

I have proposed a solution to is it science or art... see NutsAndBolts for hopefully what will be a good discussion. -- WyattMatthews

I wonder if "software engineering" is more like the culinary arts than engineering. In such a way the "extreme programming" school could produce a given software product analogously to the way the French school of cooking could produce a given food product. In cooking, if the customer orders a pizza, and you deliver a pizza, that is by definition success even though there may be many ways to get from "raw ingredients" to "cooked pizza". Cooking is bound to the laws of physics and chemistry just like software engineering is bound to the laws of physics and mathematics, but I don't need to be a chemist to be a great cook, and I don't need to be a mathematician to be great at producing software. Likewise, it would be folly to attempt to rationally and/or empirically "prove" that French cooking is superior to Japanese cooking, again in analogy to comparisons between software producing methodologies. The great chefs of the world also do not feel inferior when you tell them, "you're not a real chemist!" -- AndyPierce

Cooking success generally depends on Argument-by-Popularity.

The effort of "proving" a system is by necessity be much larger than writing and testing the thing to begin with.

Argh, NOOOO! When you wrote the program, you had a proof in your mind. It WAS there, otherwise how did you know the program would work? And if now, why did you release it, nuthead?! You dont randomly whack the keyboard until your tests pass by chance, you think when coding.

The proof is there. It just needs to be written down and checked by the machine. In exactly this order:

think of the program and the proof
write down the program and the proof
compile both

Nothing else works. Thinking of the program first, then the proof gives you an incomprehensible proof; thinking of the proof first gives you nothing to execute, not thinking of the proof at all gives you a security nightmare at best.

That self proclaimed "practicing programmers" still insist that proving programs is impossible, is a clear sign that information science is still stuck at the level of alchemy and has yet to be elevated to that of chemistry. The pity is, we were almost there, back in the 50s or 60s.

That's easy for simple programs, where the proof is obvious. For any reasonably complicated program it's quite difficult to prove that the proof proves what you think it proves.

TopMind's suggestion that "computer science" is not science: http://www.geocities.com/tablizer/science.htm

Summary: Science finding and forming models that attempt to reflect the "real world", and then test these models against the real world to see how they "stack up" to it. However, programming is not the "real world". ProgrammingIsInTheMind. Thus, "computer science" is not science except in terms of WetWare sciences, such as psychology. There are multiple ways to achieve the same output with a given input set, and so far "computer science" says nothing about which path is the "best". (Industry domains may attempt to model the real world, but that's industry-specific science. Also, machine performance, such as speed and disk space, is subject to real-world empiricism, but software itself is not hardware, by definition. The interaction between software and hardware may be subject to performance empiricism, but most of the "important" issues on this wiki are not about machine performance.) -t

As usual, you're confusing SoftwareEngineering with ComputerScience. ComputerScience is a branch of mathematics -- no more, no less.

I'm not sure there is universal agreement over that. But if true, then the term "computer science" is clearly a misnomer because math is not science (by itself).

True, math is math. A firedog isn't a canine, either. Deal with it.

So "computer science" is not really "science" in the same vein? Good, we settled the topic question then. Time to go home.

Computer "science" is indeed a misnomer. Computer science is a mathematical discipline. Software engineering is an engineering discipline. There are certainly sciences closely allied with computing -- cognitive science, computational linguistics, computational psychology -- but these are generally considered distinct from computer science, which is the study of computation itself.

Re: "Considered distinct" -- I don't see that. They are often rolled under the title "computer science". What you describe would best be called "computational mathematics" in my opinion; and "computer studies" would be a better name for the group of disciplines normally under the CS umbrella. Related: CsStandsForComputerStudies.

Yes, colloquially and outside the field, "computer science" is frequently used as a convenient handle for everything from mathematical computer science to the study of the socio-political impact of computing, but within these fields clear distinctions are made. Your terminology is not unreasonable, but they're now considered somewhat outdated. "Computer Studies" and "Computational Mathematics" and the like were once popular course titles in various universities, but they're tending to be replaced with the more familiar "Computer Science", "Software Engineering", or "Computing" (usually covering the variety of non-mathematical subjects.) In particular, "Computer Studies" was often seen to be little more than lightweight computer appreciation, attracting weak students who liked playing videogames but who were otherwise unteachable and unemployable.

I agree that "computer studies" sounds "wimpy" (for lack of a better word), but is it better to lie to get tuition money? (And often the kind you described as "unemployable" have well-paying careers because they had the people skills to move into management etc. "Soft" skills are valued, for good or bad, especially deeper into one's career. Being a heads-down "bit-head" seems to plateau early.)

There's no lie. "Computer Science" is typically taught as computer science -- perhaps leaning toward the pragmatic side in many institutions, but still plenty of theory of computation -- with some software engineering. Software Engineering is taught as software engineering with some computer science. Sometimes the balance of software engineering and computer science shifts one way or the other, but that's no great harm. Teaching "computer studies" with neither software engineering (or only a little) and no computer science (perhaps only a 1st year smattering of computer architecture) has largely fallen out of favour.

Currently, soft skills are expected along with serious technical skills. It's not one or the other; now it's both.

Re: "Computer Science is typically taught as computer science" -- please elaborate.
It focuses on computational theory and related disciplines (e.g., statistics), typically with a pragmatic bent, like programming and programming paradigms, formal verification, etc.
A lot of that is math or psychology (or what should be psychology if done right), not really "science".
There's not a lot of natural science in the biology or geology sense. There's plenty of math, and programming is math whether you like it or not. Psychology, no, except maybe some HCI and/or cognitive science.
What about calling it "computer technology"? That's non-specific enough to avoid category headaches, and doesn't sound fluffy like "computer studies".
"Computer technology" generally implies a strong hardware component. It's sometimes called "Information Technology", though that now seems to be fading in favour of "Analytics and Informatics" and the like.

I've seen very few who seem to master both. I know a fair amount of gifted "techies" who are very polite and diplomatic, but are poor at explaining things. And I know a few who are good at explaining things, but are temperamental or overly willful. The best managers are GoodEnough in all 3: diplomacy, tech, and clarity. Average managers, the more common type, tend to suck in at least one of these 3. I should add #4: priority management or perhaps general project management. Many managers obsess on wasteful, silly things. Techies tend to have fastidious personalities, and sometimes are fastidious about the wrong priorities, such as documentation that nobody reads, or one-size-fits-all file structures that create a lot of extra busy work to follow.

Mastering both is indeed rare. Being professionally competent at both is expected by employers.

Based on the obtuse writing style from some members of this wiki, some should be fired.

Could you given an example of what you consider obtuse?

I'm sure I encounter such fairly soon, and I'll link it when I do.

CategoryScience

DecemberThirteen