5 ms·

>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 f

>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.

NY_Entrepreneur 15y ago
You are starting with an axiom that I'm talking nonsense and then bending everything I write in that direction instead of reading what I write. E.g., "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_." I didn't say it was "easy", and clearly my point is progress and not current software development. Sure, for my project, I'm typing in code in Visual Basic .NET. For writing code today, all things considered for my context, that is about the best option. But what I'm typing in is hardly different from what anyone might have typed in all the way back to Algol. Here's the point: People type in all that code, and then what? Can some software go over it, report properties, do some transformations with known, useful properties? Not very much. Such things won't be better for Visual Basic than they were for Algol or anything between. So, they type in the code, and then all they have is just that code. They can desk check it, test it, try it, revise it, etc., but it's all still digging the Panama Canal with a teaspoon one canal at a time. That is, there's no real automation and no significant exploitation of mathematical properties that could lead to automation. Or, return to most of the rest of engineering where we have specifications of resistors, capacitors, inductors, transistors, fans, copper wire, steel sheets, aluminum bars, etc. with ohms, farads, density, tensile strength, electrical conductivity, etc. Okay, now compare with some DLL or its source code: What engineering properties do we have. Essentially none. It's like building with iron before we knew about tensile strength. Sure, with some such research progress, eventually programmers would benefit. Obviously the intention is real progress in software productivity. We're not going to get such productivity by more of the same that got us C, C++, Java, Python, Visual Basic .NET, C#, etc. Also for another of your points, I'm not talking about anything like branch prediction or deep pipelining. That's basically what to do with with the hardware to execute an existing instruction set. Also the point is not math or not. The point is progress. Math will be necessary but not sufficient. That is, just stuffing in some math won't yield more than the old trick of putting two extra, unused transistors in a radio to claim nine transistors instead of seven. Your point that there's a lot of good CS to do without 'mathematizing' the field is not promising for research or significant progress.
- tincholio 15y ago

NY_Entrepreneur 15y ago

You are starting with an axiom that I'm talking nonsense and then bending everything I write in that direction instead of reading what I write. E.g., "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_." I didn't say it was "easy", and clearly my point is progress and not current software development. Sure, for my project, I'm typing in code in Visual Basic .NET. For writing code today, all things considered for my context, that is about the best option. But what I'm typing in is hardly different from what anyone might have typed in all the way back to Algol. Here's the point: People type in all that code, and then what? Can some software go over it, report properties, do some transformations with known, useful properties? Not very much. Such things won't be better for Visual Basic than they were for Algol or anything between. So, they type in the code, and then all they have is just that code. They can desk check it, test it, try it, revise it, etc., but it's all still digging the Panama Canal with a teaspoon one canal at a time. That is, there's no real automation and no significant exploitation of mathematical properties that could lead to automation. Or, return to most of the rest of engineering where we have specifications of resistors, capacitors, inductors, transistors, fans, copper wire, steel sheets, aluminum bars, etc. with ohms, farads, density, tensile strength, electrical conductivity, etc. Okay, now compare with some DLL or its source code: What engineering properties do we have. Essentially none. It's like building with iron before we knew about tensile strength. Sure, with some such research progress, eventually programmers would benefit. Obviously the intention is real progress in software productivity. We're not going to get such productivity by more of the same that got us C, C++, Java, Python, Visual Basic .NET, C#, etc. Also for another of your points, I'm not talking about anything like branch prediction or deep pipelining. That's basically what to do with with the hardware to execute an existing instruction set. Also the point is not math or not. The point is progress. Math will be necessary but not sufficient. That is, just stuffing in some math won't yield more than the old trick of putting two extra, unused transistors in a radio to claim nine transistors instead of seven. Your point that there's a lot of good CS to do without 'mathematizing' the field is not promising for research or significant progress.

tincholio 15y ago