Not really, as your raving all over the place and still not making a lot of sense, argument-wise.
I guess I'll just agree to disagree, I feel bad for making your write so much.
Just a few of parting shots:
>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.
If you think that there has been no progress in these areas, I'm sorry, but you really don't know what you are talking about. Could that progress have been faster, had the maths behind it been formalized? Maybe so, yet I don't see that many mathematicians working on branch prediction on deep pipelining processor architectures, and plenty of other things that lowly CS-ers have worked out. Want to see more maths in all of CS? Maybe you need to bring them to it, in the form of useful tools that can deal with fast moving targets.
>what are the mathematical properties? Can't see any? Okay: Change programming languages until can.
I regret to say that that's not as easy as it sounds. There are issues of tractability, and more importantly, there's this not-quite-cottage industry of software development, which needs good-enough languages to use _today_.
> 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.
You mean like Agda, Epigram, and countless other formal systems for program specification, derivation and correctness proving?
> Instead all we get is programming languages that compete in some absurd 'beauty contest' or that 'encourage' programming 'styles' seen as 'helpful'. Sicko.
This coming from a mathematician is strange to hear. Elegance and expressiveness are important when programming. It makes for succinctness and less bugs, and improves programmer productivity (which down here in the real world, means $$$).
>How about stochastic processes? Any stochastic processes in server farms and networks?
How about them? Plenty of very CS-oriented research based on stochastic processes. I should know, I did my doctoral research within a 45 person team on networks and network modelling, where most of the big guys were mathematicians. These people (not me, I do very applied stuff in a very bastardized field) breathe and live Markov processes and queuing systems. I don't see what you're complaining about here.
>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.
The folks over at Google would like a word or two with you on this.
> Until CS gets serious about the math, it is writing checks its methodology can't cash.
Maybe, and yet it seems to be doing not at all bad, as far as I can see. Would more and better maths be useful? Surely so. Would relegating CS to "footnotes" make any sense? We surely disagree there.
There's a whole continuum in CS, from the highly abstract and "math-y" to very applied stuff that has a very faint, if any, relation with what mathematicians normally worry about, and yet is critical for actual applications. I just find it odd that you don't see that fact.
There is a trend towards more maths in plenty of CS topics that were once just "practical stuff", so maybe the day will come when maths departments will branch out into real-world CS, and CS students will need more math, as you'd like. Given that we've been doing "maths" for 3K years, and CS for less than 100, you might need to wait a bit, though.
Anyway, thanks for the discussion, and have a nice weekend.