NJ Geeks - New Jersey's IT Community

UPDATE: I got tired of looking at my original stupid title, "CompSci - Math = Big Mac - Secret Sauce". Clearly, my original title was mathematically flawed. :)

Want to be a computer scientist? Forget maths

I've been reading this headline this past weekend and I'm shocked. Actually, I'm a little indignant and frustrated because I recently came to the exact opposite conclusion not too long ago.

Before I continue, let me add the disclaimers.

DISCLAIMERS: I did not RTFB, and I'm not attacking the author's ideas as I haven't read the book. I'm very hopeful the author's main thesis is not that math is irrelevant, but that we've all missed an fundamental concept that's even more important.

For the past 10 years, I've been programming in blub. This has limited me to think about software in the context from a very insular perspective. One shouldn't be surprised as I'm entirely self-taught and never went to college.

While my career has been relatively successful, I've been been hitting a lot of barriers lately because of poor math skills, so I finally decided to take some classes to finally address this deficit. Let me tell you from experience, unless you experience the frustration of solving problems without a strong grasp of mathematical concepts, you'll never truly appreciate how vital math is when trying to solve complex problem, even trivial problems.

I hear people saying, "But I'm not creating compilers, search engines, spreadsheets and operating systems. I don't need advanced math!" Clearly they see these types of applications as being of the black-arts. These are the same people who see something like an order procurement system as being trivial.

Consider a child's perspective when it comes to complex programs. What's more complicated, a search engine or a program that manages Daddy's money? With a search engine, you're just scanning words and looking for matches, right? On the other hand, an accounting package is pretty complex to a kid. However, if you ask an adult programmer, he'll probably say a search engine is more complicated because he understands there's a hidden element. We know a search engine doesn't just scan text for matches, because they're is a fundamental performance problem with just scanning text for matches. You need to index the text to be efficient, but that's not obvious to a kid. A kid doesn't assume a search engine is going to be plagued by mathematical concepts that are expressed in terms of O(n) performance.

Accounting systems and order procurement systems are just based on arithmetic and algebra, right? Surely, one doesn't need to know O(n) theory for those. I just execute a few SQL commands and my database worries about O(n) theory. Right? If you're like me, you've seen programmers write some horrendous slow SQL queries, or worse, a completely aweful data access layer that undermines that database altogether. You know that some very basic O(n) theory would have gone a long way.

That's just the basics, and I'm sure a few of you were snickering the way I ignorantly regarded O(n) notation as a "theory". We haven't even gotten to the good stuff like relational algebra, set theory, graph theory, and every other branch of discrete mathematics. They all have had an amazingly profound impact on how computer scientists and lowely programmers approach and solve problems.

If you want to solve complicated problems with complicated solutions, don't learn math. I'm sure companies like IBM will pay you nice sums of money if you know how to complicate solutions and charge their customers a premium for awfully contrived solutions.

There's a reason why "trivial software" becomes complicated. I know this because I've been maintaining a fairly decent sized "trivial business application" for four years. It consists of trivial windows that implement trivial rules but all of this trivial code expands into way too many lines thus creating a ridiculous amount of complexity that's time consuming to maintain.

I don't even want to think about scaling this crappy software to hundreds of thousands of users, because everything would have to be ripped out. No one ever conceived distributing these rules across many machines, let alone orchistrate everything smoothly. Again, there is nothing conceptually complicated about our software, but all of these trivial implementation eventually contributed to a huge amount of complexity.

Ignorance contributed to this mess. The people who wrote the programs didn't understand functional programming, didn't understand O(n), didn't understand relational algebra, or set theory, or topology, or any other mathematically sound idea that would have saved them years in time. I know this, because I know the people who wrote it. George Boole would roll over in his grave if he saw the complicated if/else statements. Nevermind the many lines of code that could have been greatly simplified with an elegant SQL query.

Have you ever seriously considered how computer languages are different from spoken languages? I know, too many ways to count, but think about it. Spoken languages allows you to be very vague. Unlike spoken language, computer languages are essentially mathematical notations that are fundamentally designed to express precise meaning. This meaning translates into precise instructions and are executed consistantly. Unlike people, computers can't compensate for poor communication skills by reflecting on their personal experiences. They can't relate. Therefore the consequences for being vague are huge. That's why programming anything non-trivial is difficult, even if you understand the concepts.

You can't really talk about processes unless you're being very precise in your meaning. There's a reason why it's difficult to translate conceptual design diagrams, like UML, into actual working software. Ultimately, you have to ground your designs to very specific meanings with using very specific semantics. That's when the fundamental mathematical ideas come into play. When you can understand problems in terms of relational algebra, set theory, graph theory, topology, you're able to leverage a huge base of knowledge that allows you to simplify your processes. When you understand these theories, higher level concepts like concurrency, transactions, process flow, object-mapping and dependencies all make sense. You might get by like I did, but you're going to hit the wall.