5 ms·

Part II 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! Clearl

Part II 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?

tincholio 15y ago
>Understanding now? 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.

tincholio 15y ago

>Understanding now? 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.