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?

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

CategoryScience