I have seen programmers "battling" it out with really complex mathematical problems in their codes, particularly in the fields of game programming, physics programming, graphics programming, etc. I am a web developer, and I wonder if there are math concepts out there that I can use for web programming. I started web programming a year and 2 months ago, and all I have dealt with were complex analysis of systems, database queries, user interface designs, simple data structures, complex data manipulation and interpretation (regexes, parsing, etc) but I have not (yet) found a need for complex math.

So to repeat the question, are there mathematical concepts out there that can leverage my web development skills? If there are, what scenarios are do they come as an advantage or indispensable?

+1  A: 

Queueing Theory is one mathematical concept that relates to how your webserver can handle requests, looking at your incoming request rate and how long each request takes to serve.

+1  A: 

Domain specific functionality may or may not require strong math skills, no matter the platform used to deliver it.

For example, building a web-based recommendation systems that bases its recommendations on what others with similar preferences think would require decent math skills.

Another pertinent example is fraud detection.


With Silverlight and HTML5 (ie canvas and svg tags) graphics are on a steady rise and the line between web and desktop will likely be hard to distinguish in the near future.

Sounds like a great opportunity to use some of those math skills. The web skills will still be needed since a server will be involved at some point in the process.

Mitch R.
+1  A: 

There's no reason you can't use your math brain cells today in a web app. You mention game, physics, and graphics as if these are exclusive of web programming. They're not. There are quite a few online games implemented as web apps today, for example, which require non-trivial math (in Flash, Silverlight, or even JavaScript) to get the pixels in the right place on the screen, including 3D projections and transformations. Add HTML 5's Canvas to the mix and things get really interesting.

The web programming mentality is often preoccupied with server configs, databases, and cache performance, but construction of the web UI front-end is also part of web programming. As soon as you're responsible for placing pixels in front of the user (more than just text), you will need math. If those pixels need to move, you will need math.

+1  A: 

Last week I optimized a social insurance number validate function (Luhn algorithm) in javascript, and was able to break it down into a one-liner. Finding a solution involved an algebraic proof that I couldn't have done without higher mathematics.

I think the greatest benefit is that of thinking like a mathematician when coding.


Web programming is (or at least should be) mostly functional programming, which is really mathematical thinking.

Alexandre C.
I don't buy this. Virtually everything client-side JavaScript does involves side-effects. Obviously they're intended effects in practice, but still side-effects in functional programming theory. The page is mutable. As I type, right now, the web page I'm looking at is mutating in front of me. Sure, you can point to Haskell-style Monads, but that's just a way to reinvent imperative programming.
In any case, do-this-then-do-that - even as a "functional composition using an associative operator obeying the rules of a monadic algebra" is still just do-this-then-do-that - calling it "mathematical thinking" seems odd, as if normal people can't cope with ideas like "binding" two actions into a sequence. For this and similar reasons, I don't really buy "functional programming" as "mathematical thinking" any more than any other kind of programming.
@Steve: I agree with client side, even if CPS is widely used for asynchronous requests. For server side, it is always a matter of "transforming something into something else" (DB query -> HTML), which is the essence of FP.
Alexandre C.

There is a very nice presentation and upcoming book by Gregory Meredith on Monadic Design Patterns for the Web. (There's also going to be a Video Lecture Series about this topic by Gregory Meredith himself on Channel9 sometime in the next months.) It probably doesn't get more mathy than Monads or Category Theory (which is where Monads come from) in general.

Another nice example is the fact that Interactive Programming (and especially the Iterator Design Pattern) and Reactive Programming (and especially the Subject/Observer Design Pattern) are category-theoretical duals of each other. Also, it turns out that the Iterator Design Pattern can be implemented as an instance of the List Monad and the Subject/Observer Design Pattern can be implemented as an instance of the Continuation Monad. Since both are Monads, this basically means that you can deal with both using the same tools.

In other words, you can deal with event streams (which are generally thought hard to deal with) the same way you do with collections (which everybody already knows how to do). For example, in .NET, this means that you can "query" event streams using LINQ, since really LINQ is nothing but Monad Comprehensions dressed up as SQL queries so that enterprise programmers don't get scared by big words such as "Monad".

And, of course, Web Programming is all about Reactive Programming. The browser constantly fires events at you that you must react to. And all of the asynchronous I/O stuff (database, file, you name it) is all about firing off your I/O request and then waiting for a completion event.

Jörg W Mittag