I generally use Numpy NDarrays and Scipy's NDimage functions for graphics & image processing in Python. Aside from the NDarray data-structure itself, there's almost no O-O; everything in Numpy is either a method of this one workhorse data-type, or module-level functions that operate upon this data-type.
NDarrays are great because they can represent all of: - images (using 2-D arrays for binary or greyscale images, and 3-D arrays for colour images); - the vectors & matrices used in 3-D computer graphics; - the masks used in spatial image filtering; - the "structuring elements" used in morphological image processing.
Once you get used to the syntax, NDarray indexing & slicing are very efficient in both keystrokes & CPU cycles to get/set the values of pixels or arbitrary rectangular regions.
NDarray methods & the related Numpy functions offer element-wise operations (like pixel-wise Boolean logical ops, or "square every element in the matrix" / "square-root every element in the matrix" as part of the Euclidean distance calculation) and operations that can run over any dimension of the image (including the colour dimension, which is useful for calculations like the N-dimensional sum in dot-products or Euclidean distance). And the for-loops are in C, so they're blindingly fast.
NDimage functions provide filters and morphological processing capabilities. Plus, Numpy integrates nicely with Matplotlib so you can display images and plot histograms.
I wanted to stitch a few photos on friday and used Python w/ the Pillow library, and was once again impressed for easy and pleasurable the experience was (using mostly C and Go nowadays).
Effectively, even things like Android and IOS still use the same basic principle, and if you dig deep enough this is exactly the structure you'll see.
Plus cooperatively multitasked servers wipe the floor with almost any other kind. It's good to know how they are structured at a very low level and be able to write code to cooperate with them.
Cairo is quite nice and very different from Win3.1. It is more like GDI+ but nicer (and probably slower).
The GUI/event handling can also be done in different ways: functional reactive programming is very different from Win3.1/X/Old-Skool Macs.
I'm building a Haskell desktop app over winter break (DMX and light show controls), but after a fair bit of research, I came to the conclusion that its best to do the GUI in JavaScript and speak with a Haskell server over a WebSocket.
The package is on hackage[3] and has a website[4], but the github seemed more approachable/clear to me. There's also an awesome tutorial on making tic tac toe[5] by ocharles of the 24 days of hackage fame.
0: https://github.com/benl23x5/gloss
1: https://github.com/benl23x5/gloss/blob/master/gloss-examples...
2: https://github.com/benl23x5/gloss/blob/master/gloss-examples
3: http://hackage.haskell.org/package/gloss
4: http://gloss.ouroborus.net/
5: https://ocharles.org.uk/blog/posts/2013-12-10-24-days-of-hac...
BUT, if you mean "math" as in "abstract math" (which I believe is what you do) I don't think there's anything suitable for that ATM. You see, the thing is that computers behave in a certain way and languages/libraries are pretty much just tools that help you abstract away all the boilerplate associated to the many common tasks that you may want to do in a particular subject. That said, you can't easily escape the underlying paradigm, the "way of the machine"; which in this is case is pretty much "light on and off particular pixels on the screen in order to create shapes/effects".
There is not, however, anything stopping you from creating a new set of tools designed to do exactly whatever you'd imagine these tools should be. For what I see, you are at one of the most important stages anyone has throughout his life in order to innovate, that is, when you're barely starting and your mind is full of your ideas instead of someone else's. Take note of everything that comes up to your head and try to find a way to code it later, my only suggestions would be:
1) Don't give up, it's gonna be a very long and tedious process but don't give up.
2) Try to find the tools you feel are helping you in solving this problem, never the other way around (i.e. trying to adapt the problem to the tools). If you ever feel that you are not making any more progress with the toolset that you chose and have better options in mind just go for it; even if you have to recode everything from zero again just rinse and repeat until it's perfect.
You could be at the start of somethin very interesting, who knows; best of luck and don't forget to post your progress back here.