in reply to Mathematics eq CompSci

Id just like to mention that you are basically begging the question by using the term compsci in the first place. CompSci is more or less defined as being the mathematics of computing so by that it would seem you have your answer.

But I dont think you meant to ask that question, mostly as it isnt that interesting a question. The question i suspect you really are asking is whether we consider math and programming to be the same thing. And i think the answer is quite clearly not at all.

Most programming tasks that I see require almost no advanced mathematical skills, instead they require a wide range of other skills and knowledge that are specific to the world of programming. For instance having an intimate knowledge of SQL syntax for various DB's is not a skill that almost any CS or Math course is going to impart on you. Having experience in coding means that you will implicitly make design decisions about your code that are superior to what a less experienced but better educated Math type would do. You can almost guarantee that the code quality from a 17 year old whos been programming open source C for two years will be superior to a PHD Math graduate whos primary programming experience is Fortran and Maple.

An analagy with automobiles that has been made elsewhere feels apropriate to this thread: in the automobile business you have three groups of people involved in the process of making cars (leaving out the management/marketers :-), Engineers, Assembly Workers and Mechanics. The Engineers are responsible for a lot of things. Designing the parts, the assmebly line, selecting materials, studying the system, and etc. IOW they do all that highbrow stuff. The Assembly workers generally require minimal skills, the engineers should have already solved most of the issues involved in the manufacturing process. That leaves the mechanics. Now these folks are responsible for fixing your car when it breaks. They need sufficient skills to read the tech-specs on the parts they work on. They need to know how to use the appropriate diagnostics equipement and the like. But they definately dont need to be engineers. They almost certainly will never have to select the exact alloy that will be used in an engine block.

To bring this back to programming, the point is that most programmers are mechanics. We reuse libraries that others have written, we know about the resources available to us, we know that despite the advertisments using product A with product B is a bad call. We know how to read the abstracts of the papers that the CS folks write, Etc etc.

Now the mathematicians will say that they are the most important part of the pie. But the fact is that it isnt true. There just arent that many places to get a job being an algorithm researcher. There arent that many places in R&D in computing in general. But there is an awful lot of call for mechanics that can change the spark plugs and put on a new muffler. IMO a lot of math types get upset by the fact that many non-math types can outcode them with their eyes closed. The reason of course is the same reason that a kitchen assistant can often chop vegtables faster than the chef. (Recent experiece.) Writing code and doing mathematical analysis and proofs are two different things that only rarely occur in the same job or project at the same time.

---
demerphq

Replies are listed 'Best First'.
Re^2: Mathematics eq CompSci
by adrianh (Chancellor) on May 03, 2005 at 15:38 UTC
    Id just like to mention that you are basically begging the question by using the term compsci in the first place. CompSci is more or less defined as being the mathematics of computing so by that it would seem you have your answer.

    There's also the issue that we're talking about CS degrees - not CS in the abstract. There's an enormous variation in subject matter in CS degrees - from the ones that are just a sideline of a pure maths department (and would prefer that those messy lumps of silicon didn't get in the way of all the nice theory), to those that are almost vocational training (and think big-O notation is a bit highfaluting).

    An analagy with automobiles that has been made elsewhere feels apropriate to this thread

    I can feel my pathological hatred of software development analogy/metaphor coming on :-)

[reply]

      There's also the issue that we're talking about CS degrees - not CS in the abstract.

      Agreed.

      I can feel my pathological hatred of software development analogy/metaphor coming on :-)

      Yeah, i can understand that. I hope the analogy worked for you more or less. All I was trying to get at is that not knowing the algortihm to calculate sin() correctly and efficiently on my favourite CPU doesnt stop me from using the function when its provided by the standard libraries to solve simpler problems like whether that tree in the back yard will fall on my house when it gets cut down.

      As an aside does anybody know if Shell sort has been fully analysed yet? I recall reading Knuth where he said that Shell Sort has stubbornly resisted complete analysis. (IE its not know what the optimal intervals are for the different passes over different data sizes etc....)

      ---
      $world=~s/war/peace/g

[reply]
        Yeah, i can understand that. I hope the analogy worked for you more or less.

        More or less - emphasis on the "less" :-)

        I understood what you were getting at after a couple of readings but statements like:

        The Assembly workers generally require minimal skills, the engineers should have already solved most of the issues involved in the manufacturing process

        really annoy me. You go up to a assembly worker and tell them their job requires minimal skills and that the "engineers" will have solved most of the problems in the manufactoring process and you'll probably get a thump :-) Automobile assembly work is a very skilled job. Especially in these days of lean manufacturing where you have teams following cars from one end of the line to the other.

        Factory floor workers may have different skills from the "engineers" - but they're certainly not minimal.

        Not to mention the way that lean/rapid product development processes are blurring the line between the "engineers" and the "workers" anyway.

        But I begin to rant.

        I think engineering/factories and architecture/building are deeply flawed metaphors for software development. Any time I see one little warning bells start ringing in my head. They are usually based on "folk" ideas of how these processes work that have little resemblance to reality.

        Ahem... sorry... still ranting... stop now :-)

        All I was trying to get at is that not knowing the algortihm to calculate sin() correctly and efficiently on my favourite CPU doesnt stop me from using the function when its provided by the standard libraries to solve simpler problems like whether that tree in the back yard will fall on my house when it gets cut down.

        Which is, of course, perfectly reasonable :-)

        As an aside does anybody know if Shell sort has been fully analysed yet?

        I seem to recall that Knuth had a chunk more on the analysis of Shell sort in the second edition of his Sorting and Searching volume - but I don't own a copy. Can't really remember the details, just that I recall it was different from the first edition. Anybody got one to hand?

[reply]

In Section Meditations