For the CS topics you listed, e.g., programming languages, that field has for decades just cried out for some good math but gotten nearly none! Clearly compiling and executing a program are necessarily mathematically something, understood or not, powerful or not. For progress, we need to understand the subject mathematically. E.g., given a programming language statement, what are its mathematical properties so that given a sequence of two such statements, what are the mathematical properties? Can't see any? Okay: Change programming languages until can. Then with the properties, what can we conclude about the program? Anything useful, say, about correctness, running time, storage utilization, approaching limitations? Given some properties, can we have some code transformations with some known properties? Are some such useful? If not, can we define some useful programming languages that admit such transformations?
There are some simple, illustrative, pregnant cases that just leap off the screen: Write a collection of routines for sort by surrogate, i.e., finding a permutation, maybe honoring sort 'stability', applying a permutation to an array, chasing through the fact that each permutation is a product of disjoint cycles, etc. Then with such routines, will see some properties that are close to algebraic, e.g., where some combinations of the routines are the identity transformation, where one routine is the algebraic inverse of another, where we might have commutativity and/or associativity, or are equivalent to other combinations, etc. Can we preserve sort 'stability'? So, we see that we should have an 'algebra' of those routines and be able to derive known properties. Then we see that due to 'boundary' limitations, etc., our algebra is only roughly correct. So, maybe we should fix that.
This is old stuff. It has leaped off the screen for decades. We want some known properties we can use to derive new, useful properties. Instead all we get is programming languages that compete in some absurd 'beauty contest' or that 'encourage' programming 'styles' seen as 'helpful'. Sicko.
E.g., it has been common now in server farms to be concerned about reliability. So, we set up systems so that when system A gets too busy or fails, then system B takes over, etc. However, what we've seen, including at some of the most important farms, for decades, up to this year, is that these intuitive approaches far too easily go "splat" in the mud: They are 'unstable', have problems that propagate, and are surprisingly UNreliable.
So, we need some new math of 'reliability' for such server farms, math that can write us some guarantees. That math will start with the real problems, have definitions, theorems, and proofs, and, if successful, some solid tools for building reliable server farms.
All across computing, CS needs to give us progress, and for that they need to proceed essentially only mathematically.
It's the math. The CS is the math. Server farm reliability is just the application of the math and is not the CS. Ignoring math, CS is "A little people. A silly people."! Until CS gets serious about the math, it is writing checks its methodology can't cash.
To get serious about math, CS first has to learn LP well!
The would you believe probability? How about stochastic processes? Any stochastic processes in server farms and networks? Any uses of the axiomatic derivation of the Poisson process? Any roles for one of the strongest inequalities in math, the martingale inequality and the associated convergence theorem? Measure preserving transformations as in ergodic theory -- I'll answer that one, "Yes!". The renewal theorem and loads at server farms? How 'bout a little in probability?
Understanding now?