Math isn't important to software engineering, but it is of great importance to computer science. Math is important to software engineering, it's just that you can get by without it. However, if you want assurances of correctness then type theory and proof theory are actually rather important; if you want to do concurrency well then process algebras are a good way to do it right, and with assurances that you are getting it right. You can get by quite happily without these things. You can, however, do an even better job with them.
There seems to be a great deal of confusion about mathematics, and I think it is easier to point out what mathematics is not than try and explain what it is. The important point, as you suggest, is that math is about structured reasoning; math is not just the endless array of facts and tidbits that they throw at you in high school math. It troubles me that so many people have been taught math so badly that they seem to not really even know what the subject really is.
Most of them place the ideal width of text for maximum comprehension at 30-60 characters. Notice how this is done with newspapers. Can you imagine how difficult it would be to read a newspaper that spanned articles across the entire page? Sure, but code is not block text like newspapers; it almost always uses indentation from the left to delimit blocks, and it is usually the combination of indentation and actual printable characters that bumps you up against the 80 char limit. So 60 characters of block text is fine, the question is how many levels of indentation should we reasonably expect, and what is a good tab width?
There will not be a "year of the Linux desktop". There will only be the year when people realize that most everyone else is running Linux, too. Exactly! Both the people expecting a "year of the the Linux desktop" and the people who mock that saying Linux won't and can't succeed on the desktop are deluding themselves. Consider that Linux is now quite successful in the server space; was there ever a "year of Linux on the server"? No, it simply became more prevalent and slowly but surely snowballed. As more people used it on the server it gained support for a wider variety of servers, and slowly but surely invaded the server space. Linux will be just the same on the desktop. There is no point when Linux is "desktop ready", since there will always be something that is lacking for some users. Instead Linux will slowly but surely become more viable as a desktop for a larger and larger userbase. As the userbase expands the application availability and user-friendliness will in turn steadily improve. There is no magic tipping point.
If you want to see that Linux will eventually gain significant desktop market share then just compare Redhat 5.2 to Windows98, and Ubuntu 7.04 to Windows Vista; the desktop gap has been slowly but steadily closing for years. More and more people are finding Linux a viable alternative desktop. It is still not viable for everyone, but little by little it will get there.
Philosophy of numbers is, indeed, an interesting problem, something I've discussed at some length. Still, one shouldn't reject the fact that numbers in the purely abstract are important and useful -- the process of abstraction is fundamental to mathematics, and the question you need to ask yourself is "how much detail can I afford to forget for the problem at hand". The more detail you can safely ignore the simpler and more general your work. Being able to remove consideration of units, or indeed any connection to the concrete physical world is important to mathematics, particularly with regard to developing the degree of generality that ultimately makes the subject as powerful and broad reaching as it is. For many problems the complete abstraction to raw number is too much, you've lost detail and information that is important, but then often the full abstraction is vitally important.
Automatic checks only go so far, and if it's optional then it's even worse -- failure through ommission. Relying on the things you list alone will result in abject failure, not only in the system itself but the philosophy of the developers -- "I did xyz, I'm safe, there will be no errors." There's only so much you can do within the base language itself before you start catering to the stupid and putting the system in a nice, safe, less-useful box. Are you then implying that we should remove the ability for checks because lazy and poor programmers will abuse them? You seem to be suggesting that if we provide any checking then developers will "use it as a crutch" and not write good code. At that rate why bother with type checking, since that's just an extra crutch that makes developers lazy and expect that things will work. While we're at it why not remove syntax checking altogether; surely giving developers hints about syntax errors just makes them lazy instead of carefully inspecting everything they write. Let's just have the compiler take a best run at compiling the code, and if there is any syntax it can't parse it can just fail silently and let the developer work out where it is. Just because some people are stupid enough to think that auotmated checking makes their code error free doesn't mean it isn't good to provide automated checking for the rest of us for whom it is useful. There will always be idiots, and you won't magically make them better programmers by failing to catch obvious mistakes.
Really? No kidding? It's called a requirement. So we are adding functionality to give poor developers yet another crutch to lean on, catering to the stupid? No, it would be adding a mechanism that allows requirements to be documented properly in the code itself, rather than on paper in a binder buried behind the filing cabinet in a document that is now hopelessly out of date and doesn't reflect the code at all anymore.
Perhaps you are a perfect programmer who never makes mistakes. Some of us, despite our best efforts, do make mistakes occasionally; perhaps we simply weren't thinking about how this code would interact with someone elses code at the time; perhaps we just made a typo; perhaps we hadn't quite had our coffee yet; who knows, but mistakes happen to everyone (except, apparently, yourself). In the case that mistakes creep in, it is nice to be able to catch and fix them as early as possible, rather than having a complex and expensive bug hunt somewhere down the line. Spending a moment to actually document requirements and intentions in a form that can be checked (be it statically, or automatically at runtime if you leave checks on) efficiently and regularly is a good thing. Most of us do that already in the form of static types which are checked at compile time. Adding some expressivity to that (via a more powerful type system, contract annotations on methods and objects, an automated unit testing system, or just extra static checks on units) isn't a bad thing, especially if it is optional (as it often is).
I can have some sympathy for the complaint that adding bits and pieces in this rather piecemeal (and in the case of this particular implementation, somewhat clumsy and verbose) fashion is poor. Ideally adding means to decently document and express requirements and intentions should be something added to the language as a whole, with an overriding vision of how it should work. For that see Eiffel, Spec#, Fortress, or languages with more expressive type systems like the ML family and Haskell. Still, with something as simple and encapsulable as dimension and unit checking, why not just throw it in as a convenient optional extra? If you don't like it, don't import the library that implements it.
Now if only they could lift the better functional programming support, and support for tests, properties and contracts... The math notation would be nice too, but I suspect that'll be a hard sell to all the non-mathy types out there.
This looks rather similar to the units and dimensions handling and checking available in Fortress, Sun's effort to build a new numerical/scientific computing language. In general it seems like a sensible idea -- having the option of adding extra annotation that allows for more exacting static checking and greater assurance is generally always a good thing. The only downside is that, at least in the java implementation, it is a little cumbersome and clumsy (though maybe that's just par for the course for new java versions). Now if only java could get statically checkable optional contracts as in Spec# we might actually be getting somewhere. At the very least it would be nice if they had runtime checkable contracts, properties and tests as in Fortress. Or perhaps I should just wait for Fortress to finally mature; it seems that will happen faster than java getting the features I'm after.
That's just completely incoherent - the law of conservation of energy is that the total energy in a closed system is constant OVER TIME. How can it possibly leave out time? Worse yet, the law of conservation of energy actually spills out as a consequence of Noether's theorem, and the time symmetry of the laws of physics -- that is, the fact that the laws of physics should be the same today as they will be tomorrow. CoE is, in a sense, a consequence of time.
Since microsoft is going for ECMA and ISO standardization of thier file format, personally I think it should be approved; once the ECMA and ISO approval is done. Given some of what has achieved ECMA and ISO standardization, and indeed, the quality of the documentation of the "standard" that OOXML purports to be, you're basically just asking for rubber stamps, not openness. Then again, this is government, so perhaps rubber stamps are actually more important than the qualities the rubber stamps are supposed to guarantee.
This does raise an interesting question though, because MS is successfully slipping through the door here. It is a case of following the letter of, but not the spirit of, the law. They have provided a "standard" that is just good enough, just open enough, just documented enough, to meet the ISO and ECMA requirements (and really, it is pretty borderline on that, and could still go either way). At the same time it has a whole host of what are essentially closed unimplementable features riddled through it, guaranteeing lock in which MS so desperately needs (do they really? Is MS Office so mediocre that it can't actually fight toe to toe? I suspect it would do fine; it may lose some market share, but would probably cope well). The question is: how do we close the loophole? Exactly what needs to be asked for in a standard to ensure it is actually an open standard?
For the most part this hasn't been a problem; people seeking standards mostly wanted them to be universally implementable. The idea of someone trying to get an ISO standard that was useless to all but the submitter; well, that was rather ridiculous -- it would seem to be defeating the point. Now, however, it is very much the case. So what needs to be asked for to actually guarantee openness? This is not a trivial question.
You are comparing a population of 30 million, most of whom vote, to a population on 300 million, most of whom don't vote. From the figures you quote, Canadian per capita election spending it higher. It a little hairier than that. He was comparing a presidential election with a Canadian general election; the former has only a handful of candidates spending, while the latter covers election spending of every candidate in every riding. It isn't really easily comparable. Perhaps you could compare spending on a Canadian general election with the total spending of all candidates in a congressional election? Those figures may be harder to find though.
Now just one more thing, guys: make the entire system run on Linux or other F/OSS operating system. If I got to add just one more requirement, it would be that the voting software was formally specified, such that the code can be machine verified against the specification, and properties of the specification can be formally proved. Sure that requires a little more work, but really, if there ever was a place where you wanted the extra assurance of security and correctness you'd think it would be in your voting software. Indeed, it not like this sort of thing hasn't been considered, and even implemented (with documentation of the formal specs), before. I would think a decent level of formal verification of open source voting software should be a minimum standard.
By what standards do you measure truth? What is the criteria you would use? I tend to use physical reality, and an ideas conformance with it, as a yardstick. Of course that doesn't mean I can discern "Truth", but I can discern things that are "Wrong"; for example, if I pick up the book next to me, hold it some height above the floor, and let it go, I'm willing to stipulate that the claim "it will fly up to the ceiling" is "Wrong". It doesn't accord with my experiences of physical reality. I will happily call the idea that things always fly up toward the sky when you drop them "absurd" because it is quite at odds with my experience. Of course even this "Wrong" and "Absurd" are not absolute. Under certain conditions things can fall "up", and perhaps tomorrow the laws of physics will reverse themselves and mass will result in objects being repelled from one another; who knows. In that sense the notion of "Wrong" is relative -- that doesn't mean no comparisons are made, it simply means there aren't any absolutes. I feel the claim that "things always fly up toward the sky when you drop them" is "Wrong" relative to the claim s of General Relativity (which is itself "Wrong" since it is incompatible with Quantum Field Theory), but I feel it is less wrong than the claim that "I do not exist" (which seems rather more unlikely to me, though the provisos to make it clear what I mean would take a long time to explain; you get the idea).
Our ability to know "Truth" even if it existed is dubious. Even if we accept some things as sufficiently relatively "Wrong" to stop giving them any thought (which, let's be honest, most of us do), "Truth" still forms a small subset of the things we can label as "Not Wrong". We can try to whittle down "Not Wrong" (That's what Science aims for, within the narrow field of physical reality, and staying away from metaphysics) , but there's no reason to assume we'll know "Truth". Worse, it is fairly clear that, having had different experiences each of us will have different scales of "Wrongness" for different things, and the set of things we can deem as "Not Wrong" will vary from person to person. Still, there can be a common set of things that most people will agree to stipulate as "Wrong" and we can work with that as a start, and attempt to expand that common set through a combination of education and investigation. I'm sorry that the world is not black and white, that things don't always fall into mutually exclusive categories of "Wrong" or "Right", but that is the nature of things. There is still enough common ground that, should we actually agree to co-operate, we can move forward together.
Science and religion are not the same thing, they shouldn't be made to compete in the same arena. Right, but then it has to compete with philosophy and metaphysics, and religion doesn't fare well on that front either. Religion tends to be philosophy that comes pre-hobbled with otherwise unfounded dogma and assumptions. It's always going to lose out to philosophies that are more open and free in their inquiries into the nature of things. Indeed, just looking at the narrow category of moral philosophy shows this to be the case: religion simply has its commandments, while other philosophies have far more compelling reasoning, from Kant's moral imperative, to various game theoretic evolutionary psychology approaches.
Hating theology because it's not science is like hating apples because you can't make orange juice out of them. Sure, but disliking religion because it is just bad philosophy is something else again.
The reason these people feel threatened is because if you take away this sort of gobbledygook, there's not much left in the religions that they've made the center of their lives. Well yes, that's exactly the problem. Once you take away the rock solid explanations of "how things are" and "why things happen" then you end up with a religion that is awfully close to being philosophy. Once you're at that point you've simply traded in arguing with science for arguing with philosophy. The dilemma there being that philosophy has been developing for a long time, and there are quite few philosophical outlooks that are rather more compelling and rather more reasoned than most religions. The only reason to stick with the major religions is a desire to cling to the dogma, but that throws you back into the science vs. religion arena. Religion is getting increasingly squeezed out.
Meanwhile, you're got people like Unitarian Universalists, Quakers, some of the more contemplative Catholics and Jews, many Western Buddhists, a large percentage of Neopagans, a bunch of Sufis, and others using religious tools of myth, ritual, and contemplation to understand their subjective internal worlds. And it is a very short step from there to simply using religion and religious myths as a diagnostic tool for understanding our own minds, purely in the sense of understanding how our minds and ideas work by considering what religious ideas and myths happened to develop and to appeal to us historically. You cease believing in religion, and start simply studying history of religion as way to better inform your philosophy. Indeed, I would argue many of those rejecting religious dogma and simply exploring subjective inner worlds with religion as a road in are simply doing philosophy; there is no religion left unless they choose to let their minds be hobbled by dogma rather than freely exploring the possibilities. The fact that such philosophy gets called religion is really just a cop out to try and bolster religions diminishing numbers. Fewer and fewer people actually believe, many people are left with a belief that they should believe due to cultural inertia, and mislabeling philosophy, but even that is slowly shifting.
I am not, of course, suggesting that religion will disappear: there are far too many people who seem to have a need to believe in such things -- just witness the creation museum and the vast amounts of money raised to build it. Rather, I am suggesting that religions universality will fade, and its dominant grip over culture will diminish; it already has: compare art today with art of several centuries ago when almost all art was religiously motivated. It will just happen very slowly.
Even for those of us with enough education to figure out if the study is mostly OK or not... it is difficult to find the raw data for the study. Even then, for those that run such studies the field is mature enough that subtleties in just questions and what they base things one can give them basically the outcome they want... The ideal that I guess I'm pitching for (I was never intending to seriously advocate it, but it seems to be coming out that way) is that, with a slightly more educated populace that is actually willing and able to deal with nuance and analysis of statistics, we can see more analysis presented in the media. The point being that, in this (ideal and not really practical) world it wouldn't be up to each and every individual to do the hard statistical work, but rather up to statistically aware journalists who sensibly question their sources. In such an environment failing to provide your raw data would be seen as a serious faux pas. Of course this whole scheme relies on journalists actually bothering to question and analyse the material they get handed instead of just blindly reporting it -- which isn't the case now for any sort of news, let alone material that requires any sort of expertise like statistics. Still, at least in theory it would be possible to have the analysis done by the media, and the populace just needs to be capable of understanding a presentation of that analysis.
Statistics these days are becoming increasingly worthless, often just used to justify a political agenda on both sides. And that is very depressing, because it leads to people, such as yourself, simply distrusting all statistics on spec. What's wrong with that? Well once you remove any form of reasoned quantitative analysis from consideration, what is there left to inform decisions with? Gut feeling? Who looks best on camera? Who manages to sound more convincing?
I would suggest that the problem is not with hard facts and statistics, but rather with a populace that is poorly educated in statistics and a media that is unwilling to actually analyze the statistics (and present that analysis) for fear of offending or boring an apathetic and relatively innumerate populace.
The suggestion that TDD is somehow not Agile seems a little bizarre to me. TDD doesn't suggest you sit out and write every unit test for the entire software system first, it simply suggests you write tests as you get the requirements, and then code to the tests. All I am suggesting is writing tests and contracts as soon as you can, and coding to those. I'm not in any wasy suggesting you fix them in stone as soon as you write them. By all means change the contracts and tests as the spec and requirements get refined. Those changes will, in turn, necessitate changes in code.
Because contracts, and unit tests, as a specification, can't be changed as code is being developed? I'm not suggesting big design up front, I'm suggesting you make sure you are hammering out your spec at least at the same time as you're hammering out your code, rather than retroactively trying to build some test framework after the fact. The sooner bugs are found the cheaper and easier they are to fix.
This may work in an abstract, theoretical discussion - but in practical terms it is not even nearly as feasible as walking into a next house for rent, probably just next door. And having to look for a house in a different neighbourhood (because a rental company has bought up all the property in a particular area) is not nearly as feasible as picking a different can off the shelf of a local supermarket to get a different brand of beans. All things are not equal, and life is not always fair. Various governments got in first and got the land. It's up to you to negotiate with them on whatever terms they'll offer. Whih brings us to the next point.
You and the landlord are equals, and you have as much right to change the contract as he has. This may work in an abstract theoretical discussion -- but in practical terms a landlord will be in a relative position of power in any such negotiation. It is often much easier for him go without a tenant than it is for you to go without somewhere to live. You are just as free to try and renegotiate terms with the government. It's just as theoretically possible. It's just that they are in an even stronger barganing position than a landlord because, as you point out, moving countries is more difficult than moving neighbourhoods.
Of course you do have another form of recourse with regard to government -- you do have a say in who makes up the government and what policies it pursues.
I'm not claiming government is perfect, nor that the world is fair. I am simply trying to point out that the difference between government and a landlord is, for the most part, one of degree: a government "owns" larger blocks of land, and is thus in a stronger negotiating position. On the upside they do, at least, still provide you with some means to renegotiate. A government isn't inherently evil anymore than a landlord is.
Are there any decent compile-time contract checkers for C, C++, or Java? There is for Java in the form of ESC/Java2 which checks contracts and frame conditions in the form of JML annotations. It's not perfect (and at the moment only works for Java 1.4, apparently 1.5 is forthcoming), but it does a surprisingly good jo of weeding out subtle errors.
but that can interfere with the performance of real-time software such as... a brake control program. If you're working with safety critical realtime software I would suggest you look at SPARK/Ada which provides very strong static checking of contracts for Ada.
You have the ability to choose precisely to whom you pay rent. You can avoid really bad landlords, as well as landlords who would use, or you find out are using, your rent moneys in ways abhorrent to you. You have no such choice with the government. Come now, if you find a landlord that you don't like, you can't go to another landlord and get him to rent you the first landlord's property at a deal more to your liking. If you don't like the landlord's terms then you need to rent property that isn't owned by that landlord. Similarly, if you don't like the government, feel free to get property in a location not controlled by that government (last time I checked there wasn't a single global government that controlled all property in the world). You have choice.
Additionally, when you pay rent, you receive in return a service you desire and are actively attempting to obtain (a place to stay.) When you pay property taxes, you receive what the government decides to give you; you have little (or no) control over your end. Right, because you have complete control over the contract the landlord offers you -- if you don't like what he offers you can just change it, and he'll have to accept your changes. No wait, the other way around: if you want to rent property that the landlord owns, you accept the terms he's offering, or look elsewhere. So when paying property tax you get just the same as you get when paying your landlord: a place to stay in a location you desire to stay. If you don't like the terms of the deal offered, you are free to try different property under a different government. Or are you paying property tax but are somehow barred from living and working in the country in which you pay that tax?
For instance, it is one thing for a taxpayer to receive the "service" of schooling if there are children in the house; it is entirely another when there aren't. It is one thing to pay a tax for television transponders if you watch broadcast television. It is entirely another if you don't. So you're looking at renting an apartment in a particular building; the building has a pool and is all set up for cable (it wasn't free to put all the cabling into the building and to maintain it); apparently you can just opt out of paying the cost of those things and still live in that building regardless of whether the landlord is willing to offer you such a contract or not? Somehow I don't think so. The contract for the building includes paying for the amenities. If you don't like the amenities, find a different building. Likewise, property tax includes the amenities the government is offering. If you don't like the amenities, find a different country.
Stop pretending that you are forced into the deal, when in reality you are simply unwilling to exercise your choice.
Slashdot Mirror
There seems to be a great deal of confusion about mathematics, and I think it is easier to point out what mathematics is not than try and explain what it is. The important point, as you suggest, is that math is about structured reasoning; math is not just the endless array of facts and tidbits that they throw at you in high school math. It troubles me that so many people have been taught math so badly that they seem to not really even know what the subject really is.
If you want to see that Linux will eventually gain significant desktop market share then just compare Redhat 5.2 to Windows98, and Ubuntu 7.04 to Windows Vista; the desktop gap has been slowly but steadily closing for years. More and more people are finding Linux a viable alternative desktop. It is still not viable for everyone, but little by little it will get there.
Philosophy of numbers is, indeed, an interesting problem, something I've discussed at some length. Still, one shouldn't reject the fact that numbers in the purely abstract are important and useful -- the process of abstraction is fundamental to mathematics, and the question you need to ask yourself is "how much detail can I afford to forget for the problem at hand". The more detail you can safely ignore the simpler and more general your work. Being able to remove consideration of units, or indeed any connection to the concrete physical world is important to mathematics, particularly with regard to developing the degree of generality that ultimately makes the subject as powerful and broad reaching as it is. For many problems the complete abstraction to raw number is too much, you've lost detail and information that is important, but then often the full abstraction is vitally important.
Relying on the things you list alone will result in abject failure, not only in the system itself but the philosophy of the developers -- "I did xyz, I'm safe, there will be no errors." There's only so much you can do within the base language itself before you start catering to the stupid and putting the system in a nice, safe, less-useful box. Are you then implying that we should remove the ability for checks because lazy and poor programmers will abuse them? You seem to be suggesting that if we provide any checking then developers will "use it as a crutch" and not write good code. At that rate why bother with type checking, since that's just an extra crutch that makes developers lazy and expect that things will work. While we're at it why not remove syntax checking altogether; surely giving developers hints about syntax errors just makes them lazy instead of carefully inspecting everything they write. Let's just have the compiler take a best run at compiling the code, and if there is any syntax it can't parse it can just fail silently and let the developer work out where it is. Just because some people are stupid enough to think that auotmated checking makes their code error free doesn't mean it isn't good to provide automated checking for the rest of us for whom it is useful. There will always be idiots, and you won't magically make them better programmers by failing to catch obvious mistakes.
Perhaps you are a perfect programmer who never makes mistakes. Some of us, despite our best efforts, do make mistakes occasionally; perhaps we simply weren't thinking about how this code would interact with someone elses code at the time; perhaps we just made a typo; perhaps we hadn't quite had our coffee yet; who knows, but mistakes happen to everyone (except, apparently, yourself). In the case that mistakes creep in, it is nice to be able to catch and fix them as early as possible, rather than having a complex and expensive bug hunt somewhere down the line. Spending a moment to actually document requirements and intentions in a form that can be checked (be it statically, or automatically at runtime if you leave checks on) efficiently and regularly is a good thing. Most of us do that already in the form of static types which are checked at compile time. Adding some expressivity to that (via a more powerful type system, contract annotations on methods and objects, an automated unit testing system, or just extra static checks on units) isn't a bad thing, especially if it is optional (as it often is).
I can have some sympathy for the complaint that adding bits and pieces in this rather piecemeal (and in the case of this particular implementation, somewhat clumsy and verbose) fashion is poor. Ideally adding means to decently document and express requirements and intentions should be something added to the language as a whole, with an overriding vision of how it should work. For that see Eiffel, Spec#, Fortress, or languages with more expressive type systems like the ML family and Haskell. Still, with something as simple and encapsulable as dimension and unit checking, why not just throw it in as a convenient optional extra? If you don't like it, don't import the library that implements it.
Now if only they could lift the better functional programming support, and support for tests, properties and contracts... The math notation would be nice too, but I suspect that'll be a hard sell to all the non-mathy types out there.
This looks rather similar to the units and dimensions handling and checking available in Fortress, Sun's effort to build a new numerical/scientific computing language. In general it seems like a sensible idea -- having the option of adding extra annotation that allows for more exacting static checking and greater assurance is generally always a good thing. The only downside is that, at least in the java implementation, it is a little cumbersome and clumsy (though maybe that's just par for the course for new java versions). Now if only java could get statically checkable optional contracts as in Spec# we might actually be getting somewhere. At the very least it would be nice if they had runtime checkable contracts, properties and tests as in Fortress. Or perhaps I should just wait for Fortress to finally mature; it seems that will happen faster than java getting the features I'm after.
This does raise an interesting question though, because MS is successfully slipping through the door here. It is a case of following the letter of, but not the spirit of, the law. They have provided a "standard" that is just good enough, just open enough, just documented enough, to meet the ISO and ECMA requirements (and really, it is pretty borderline on that, and could still go either way). At the same time it has a whole host of what are essentially closed unimplementable features riddled through it, guaranteeing lock in which MS so desperately needs (do they really? Is MS Office so mediocre that it can't actually fight toe to toe? I suspect it would do fine; it may lose some market share, but would probably cope well). The question is: how do we close the loophole? Exactly what needs to be asked for in a standard to ensure it is actually an open standard?
For the most part this hasn't been a problem; people seeking standards mostly wanted them to be universally implementable. The idea of someone trying to get an ISO standard that was useless to all but the submitter; well, that was rather ridiculous -- it would seem to be defeating the point. Now, however, it is very much the case. So what needs to be asked for to actually guarantee openness? This is not a trivial question.
Science tries to explain how things happen. Philosophy tries to explain why things happen. Religion treads on everyone's toes.
Our ability to know "Truth" even if it existed is dubious. Even if we accept some things as sufficiently relatively "Wrong" to stop giving them any thought (which, let's be honest, most of us do), "Truth" still forms a small subset of the things we can label as "Not Wrong". We can try to whittle down "Not Wrong" (That's what Science aims for, within the narrow field of physical reality, and staying away from metaphysics) , but there's no reason to assume we'll know "Truth". Worse, it is fairly clear that, having had different experiences each of us will have different scales of "Wrongness" for different things, and the set of things we can deem as "Not Wrong" will vary from person to person. Still, there can be a common set of things that most people will agree to stipulate as "Wrong" and we can work with that as a start, and attempt to expand that common set through a combination of education and investigation. I'm sorry that the world is not black and white, that things don't always fall into mutually exclusive categories of "Wrong" or "Right", but that is the nature of things. There is still enough common ground that, should we actually agree to co-operate, we can move forward together.
I am not, of course, suggesting that religion will disappear: there are far too many people who seem to have a need to believe in such things -- just witness the creation museum and the vast amounts of money raised to build it. Rather, I am suggesting that religions universality will fade, and its dominant grip over culture will diminish; it already has: compare art today with art of several centuries ago when almost all art was religiously motivated. It will just happen very slowly.
I would suggest that the problem is not with hard facts and statistics, but rather with a populace that is poorly educated in statistics and a media that is unwilling to actually analyze the statistics (and present that analysis) for fear of offending or boring an apathetic and relatively innumerate populace.
The suggestion that TDD is somehow not Agile seems a little bizarre to me. TDD doesn't suggest you sit out and write every unit test for the entire software system first, it simply suggests you write tests as you get the requirements, and then code to the tests. All I am suggesting is writing tests and contracts as soon as you can, and coding to those. I'm not in any wasy suggesting you fix them in stone as soon as you write them. By all means change the contracts and tests as the spec and requirements get refined. Those changes will, in turn, necessitate changes in code.
Because contracts, and unit tests, as a specification, can't be changed as code is being developed? I'm not suggesting big design up front, I'm suggesting you make sure you are hammering out your spec at least at the same time as you're hammering out your code, rather than retroactively trying to build some test framework after the fact. The sooner bugs are found the cheaper and easier they are to fix.
Hw do you write unit tests? You know those are a specification right?
Of course you do have another form of recourse with regard to government -- you do have a say in who makes up the government and what policies it pursues.
I'm not claiming government is perfect, nor that the world is fair. I am simply trying to point out that the difference between government and a landlord is, for the most part, one of degree: a government "owns" larger blocks of land, and is thus in a stronger negotiating position. On the upside they do, at least, still provide you with some means to renegotiate. A government isn't inherently evil anymore than a landlord is.
Stop pretending that you are forced into the deal, when in reality you are simply unwilling to exercise your choice.