Slashdot Mirror
CS Profs Debate Role of Math In CS Education
theodp writes "Worried that his love-hate relationship with math might force him to give up the pursuit of computer science, CS student Dean Chen finds comfort from an unlikely source — the postings of CS professors on the SIGSE mailing list. 'I understand that discussing the role of math in CS is one of those religious war type issues,' writes Brad Vander Zanden. 'After 30 years in the field, I still fail to see how calculus and continuous math correlate with one's ability to succeed in many areas of computer science...I have seen many outstanding programmers who struggled with calculus and never really got it.' Dennis Frailey makes a distinction between CS research and applied CS: 'For too long, we have taught computer science as an academic discipline (as though all of our students will go on to get PhDs and then become CS faculty members) even though for most of us, our students are overwhelmingly seeking careers in which they apply computer science.' Frailey adds that part of the problem may be that some CS Profs — math gods that they may be — are ill-equipped to teach CS in a non-mathematical manner: 'Let's be honest about another aspect of the problem — what can the faculty teach? For a variety of reasons, a typical CS faculty consists mainly of individuals who specialize in CS as a discipline, often with strong mathematical backgrounds. How many of them could teach a good course in cloud computing or multi-core systems or software engineering or any of the many other topics that the graduates will find useful when they graduate? Are such courses always relegated to instructors or adjuncts or other non-tenure-track faculty?' So, how does this jibe with Slashdotters' experience?"
If you don't want math with your computer science, learn computers / networks / shiny jargon at a trade school
I don't know about calculus but doing formal proofs help me in learning programming because they are, in essence, the same thing. In a formal proof, you break down a problem into simple steps and state the authority for each. It is similar to programming. So some math is good.
Don't stop where the ink does.
Which is really the way it should be broken out. Computer Science should be about the math, theories, and algorithms that make up computation, and computer software engineering should be more about building applications. Sort of like how traditional engineering relates to physics.
I have seen many outstanding programmers who struggled with calculus and never really got it.
The summary is not absolutely clear on who makes this statement, but the article attributes it to "a professor". I don't know where this professor works, but the outstanding programmers I know can all do calculus in their sleep. Not all programmers, or even all good programmers, but the outstanding ones. It isn't about continuous versus discrete, which is a complete and utter red herring, but the ability to think abstractly. Hell the best programmer I know is a pure theoretical mathematician: his code is always beautiful, clear, easy to maintain, and, imporantantly, correct; he's prolific to boot. But he's an outstanding programmer. I know plenty of work-a-day programmers who are not outstanding, and whom I would suspect would have problems with integration by parts.
Based in part on my differing experience, I posit that the quoted professor does not work at a high-end institution where really outstanding programmers are likely to be found. This opinion is bolstered by the observation that discrete mathematics (the Z transform, difference equations, discrete Fourier transforms, and the like) and continuous mathematics really are not that different if taught properly. If an individual can't master continuous and discrete mathematics, then they are not going to be an outstanding programmer, because they can't think sufficiently abstractly.
Outstanding programmers can do system architecture, data structure design, algorithmic development. No one who can design and understand a Fibonacci heap is going to have problems with dx/dt.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
Thanks a lot. Like there weren't already enough religious warriors at this party.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
"It's like like suggesting that a mechanical engineering student should be taught how to fix the engine of a Ford Mustang or that an electrical engineering student should be taught how to install video cards into a PC."
No, it's not like that at all, because a mechanical engineer (or most of them anyway) are not going to be working on cars for a living, and electrical engineers are not going to be installing video cards for a living. But CS students are going to be doing mundane programming for a living.
The problem is that teaching practical, career programming is probably what a Software Engineering program should do. But that is a relatively new degree, and many colleges and universities still rely on Computer Science programs to (supposedly) teach those skills. But for the most part they do not.
It's all very well and good to say CS is one thing, engineering is another... but until academia fully catches up with that concept, many who intend to go into programming as a career are getting the short end of the stick.
And no, despite your derogatory comment, Software Engineering is not suitable material for a trade school, any more than Electrical Engineering is.
There is always going to be the some aspect of CS that's beyond your grasp, no matter what you take.
As someone who just graduated from a 4-year CS program and is about to get an MS in CS, and as someone who is a paid researcher on a major CS research grant, let me say this: CS is much broader than most people think.
Anyone who says that CS is just about the theory of computation has a very narrow view of CS. There's a sort of bullshit 'purity' argument that anything else should be put into another category like programming or computer engineering.
Some topics are easy to categorize. Design methodologies? Software engineering. CPU design? Computer engineering.
But then there are topics that defy classification. Is compiler design a CS topic, or is it CE? It's probably both. Is static verification a CS topic or a SWE topic? Both.
And then there are topics that obviously belong (at least partially) in CS but often have very little to do with computational theory. Computer vision, natural language processing, network theory, and quite a bit more.
If you limit CS to just algorithms and the theory of computation, students get a very limited view of what's out there. I would argue that students should have a good idea of how real computer systems work, how operating systems are designed, how network systems communicate, and how software is designed and built. None of these topics fit neatly and entirely under the "CS" banner, but that doesn't mean that they aren't important and it doesn't mean that there is not legitimate and ongoing research in those fields.
There is no getting away from the fact that most need to be able to write code after graduating from a CS program. Even in the academic community, most positions involve quite a bit of coding. There are a very few positions where academics can focus on the theory all day long. For most projects, though, publishable results depends on producing a working system, and that means writing code.