SQL injection is not serious problem if the _standard_ way to access the DB makes it _easy_ to do things the _safe_ way.
Examples:
DBI and placeholders, JDBC and prepared statement stuff.
These methods help make sure that when you insert $somerawdata it ends up being treated as $somerawdata by the database and not "SOME SQL STATEMENT", and also when you retrieve the data back out from the database you can be sure that you will get back the same value- $somerawdata, and not something that you need to munge with stripslashes or addslashes. AND they make it easy to do it.
The problem with PHP is for <PHP5 you are unofficially supposed to use PEAR::DB and for PHP5 you are officially supposed to use PDO, and so most people find it easier to just keep doing the same wrong thing they have been doing for years (before pear and pdo) - use magic_quotes or addslashes, or worse don't even use it and get SQL injection.
This sloppiness and crapness is all over PHP. Another example is the silly way associative arrays and indexed arrays are done - they are combined - so if you try to have numeric keys things can get messy, your ['1'] and [1] can get confused.
Too much of programming PHP is avoiding or working around the many braindead bits it has.
You claim that brains are an example of more complexity = more reliable, but you can't even spell everything correctly. That's not going to be good if you are building a spell checker whether COSA or not.
I think your problem is you don't understand the real problem with software.
And I'm not even sure you really understand your proposed solution to whatever imaginary problem you are trying to solve.
Because it is so terribly WRONG and braindead like the other popular PHPisms[1].
It assumes that all data should be filtered the same way. And guess what, not all data destinations want their data to be quoted the way "Magic Quotes" quotes them.
Whereas the correct way is to have different input filters/quoting for each input path into your program so that your program can interpret and process data correctly. And different output filters/quoting for each output path from your program to other programs or consumers of the output (browsers, databases, files, phones/pagers, etc), so that those destinations can interpret and process the data correctly.
Why should data that's going to end up in a text file be "magic quoted"?
What happens if that data ends up being read and resubmitted to the application? Does it get "magic quoted" again?
Welcome to the data corrupted world of \' and \\\' and \\\\\'.
If you say stripslashes fixes that, you deserve a smack on the head - think about the scenario when data starts coming from other sources - email etc- do you have to start "magic quoting" all those sources as well so that stripslashes works?
Seems like PHP was written by stupid/ignorant people for stupid/ignorant people.
But hey that's probably the same reason why it is so popular;).
Sure mod me flamebait, but what I'm saying is true. Explain the stupid PEAR DB vs PDO thing in PHP. PHP is a new language, it should have had the equivalent of JDBC/DBI when it started - not the stupid "different functions for every DB" crap.
[1] PHP makes doing "the wrong thing" easy, and makes doing "nearly the right thing" hard and doing the "right thing" impossible (the right thing is to not use PHP;) ).
If anyone thinks Perl is bad, PHP is Perl done terribly and with crappier performance too.
And no children without permission - no unauthorised reproduction of patented genetic material - we don't care that it was some virus that inserted "Our Patented DNA" into your germline, anymore than we do if wind spreads pollen containing "Our Patented DNA" to crops on your farm.
The reason why cheaper but less reliable hardware makes sense in most cases is:
1) Whether you use Dells or not, you still need backups. 2) Hardware gets obsoleted by software every 3 or so years (even the major Linux distros are getting on that bandwagon).
So if you have backups (like you should), if your PCs die on average every 2-3 years it doesn't really make such a big difference.
Why pay 30-50% more if you are still going to have to replace the darn thing in 3 years?
ONCE stuff starts stabilizing then maybe you'd start going for hardware that lasts longer.
" as both of the major parties would be certain to get some huge negative score"
What makes you so certain about that?
And we should let one of them win instead of someone else? That sounds really weird for a democracy. Why not be ruled by some evil but efficient and effective Dictator then?
Hey, if the voters really hate the big parties and you end up with a bunch of independents who can't agree on anything (there is no party line), that's not such a bad thing - because it makes it harder for stuff like the DMCA to pass, or the constitution to be amended etc.
Sure the country will go nowhere fast for a while, but shouldn't that be preferable to being led by people who are hated by millions of voters?
Maybe if you could vote "No" to candidates there'd be a higher turnout.
A "No" vote = -1. "Yes" = +1.
The candidate with the most positive total or lease negative total wins.
In current "popular" systems if you don't like a candidate you have to vote for some other candidate or don't vote at all - this distorts stuff significantly - you could have a situation where a candidate wins even though hated by the majority, because the voters spread their votes amongst the other candidates. After a while the voters might end up just flip flopping between two fairly hated candidates, or give up entirely.
With my proposal if people really hate someone they get to "pull them backwards", rather than trying to figure out who else to "pull forwards" and hopefully the hated one doesn't win.
The popular method probably works fine if the _majority_ actually _like_ the candidates and want to _vote_for_ them, but it doesn't work if the majority don't. And perhaps the latter is true in the USA?
Uh, without any controls, the frigging torrents and video streams are more likely to get in the way of stuff like google searches for work-related tasks. It could make the quick "shopping trip" to Amazon take a fair bit longer.
It's quite annoying when a websearch takes 20 seconds to load because of some P2P crap or movie downloading.
If I were the admin, I'd still allow video streams, but they'd be on a lower priority compared to everything else.
I doubt even email should be held back just so someone can watch a video smoothly.
Sure policies, enforcement is always down to management and not tech. But this is more like basic traffic control.
"Keeping people alive _after_ a lifetime of doing the things that make them happy is one of the noblest goals of science." (emphasis mine).
Whoa there... I think people would rather not be kept alive for too long after their lifetime of doing the happy stuff...
Seriously though: a big problem is who pays for it.
Seems like we're heading to a future where repairing people will be increasingly be limited by money (resouces) than by medical technology. Not sure when we'd ever be able to afford to pay to repair everybody.
BTW in many countries smokers pay for more than their share in tobacco taxes, duties etc - so they're not a burden to everyone else. Smoking is addictive, so one can extract quite a lot of taxes from smokers.
Even more seriously though. I think "happiness" shouldn't be the top goal by itself. Otherwise scientists could more easily and cheaply wire people up and _make_ them artificially happy and keep them going till they are beyond repair - then they'd be still happy till their last living second.
Somehow that sort of artificial happiness doesn't seem that good to me (my biased subjective opinion).
In contrast there are people who go through unhappy circumstances, persecution etc, but are filled with joy - they know they are doing the right thing and are doing something good for others.
So, a lifetime of just doing things that make yourself happy seems rather empty in comparison.
Thus a recursive: changing yourself to be happy to make others happy (and helping them be happy making others happy and similarly helping those others ) seems more interesting and fruitful.
In our current universe there will always be sad times. There is a reason for hunger and pain.
Maybe there was a species that was born permanently happy but it died out a long time ago:).
Perhaps there should be laws and regulations preventing just anyone from having kids;).
Maybe before anyone is allowed to have kids they must have provably brought up a dog of a not super-compliant breed to be well mannered, not destructive but still not totally cowed (can't have one always running away and hiding). The Regulatory body picks and assigns the dog (you don't get to choose the super easy candidates;) ).
If they don't pass, they have to keep paying maintenance for the dog and they don't get a chance to have kids till they get to try again and pass. (if they fail terribly the poor dog gets taken away from them for its own good),
If they can't bring up a dog, they can't bring up a human. After most dogs have been bred to be tolerably obedient over the generations. Not so for most humans (not saying it is good or bad, but it is something to keep in mind when training humans).
Sounds good to me too. Some crying is fine, but I've seen kids where the crying is so obviously faked ("crying about nothing" as you imply) that it is annoying that their parents still let themselves be manipulated by it. Deceit and deception should not be encouraged by parents - some kids already have enough internal desire/motivation/reasons to deceive which the parents have to counter.
All that stuff about kids fragile egos and self-esteem is bullshit (dangerous too IMO).
Most kids think the world revolves around them or think it should, they definitely need to be domesticated/trained to think otherwise- even if the only reason is it is untrue. (The small minority of "angel" kids? You'd spot them fairly quickly).
I never understood all that talk about boosting kids self-esteem.
Why praise people for just being in their current state? If you want a well trained dog you don't praise it just for being itself. You can love a person for just being in their current state (and show that love). But don't just dish out praise for anything.
You praise your kid/dog/subordinate for doing something good. And scold them or even punish them for doing something bad.
If you can't figure out what is good and bad, don't frigging be a parent.
As for not physically punishing kids, that's stupid as well. Pain affects the subconscious and conscious, so it is very effective in training. However you want to train the child to avoid doing the wrong thing, and not train the child to avoid you all the time. Pain should never be the dominant tone at all: you also want the child to _want_ to do the good stuff as well because the child enjoys doing good.
So what if the kid doesn't do anything bad, not very impressive if the kid doesn't do anything good either.
I think that's not such a great way to prevent unnecessary wars.
You think sociopathic leaders really care about "sending our soldiers to die"? They don't really. Lots of troops dying is just a cost-benefit factor to them.
My suggestion therefore is that before a Proposal for an _offensive_ war is approved, there has to be a referendum. If there aren't enough positive votes (say 66%), the people involved in the war proposal are put on _death_row_.
Then at a convenient time another referendum is taken: a "Redemption" one, if there aren't enough positive votes for a condemned person that person is executed after a suitable waiting period - so if people just stay home or do whatever they want and not bother voting, good riddance to unwanted politicians.
If in the end it turns out that a war was justified, if that person was already executed, they get the equivalent of a purple heart or whatever award dead soldiers get, and their families get some pension, and some official ceremony or something to remember them blah blah blah.
If it turns out there was deception involved in getting a proposal passed, the people involved get put on death row.
The other notable effects:
More soldiers would be more willing to fight because they know their leaders were willing to risk their own lives AND >=66% of their citizens think that the war is called for.
The enemy soldiers would feel more at ease at defending themselves even up to the point of wiping out the attacking country - after all >=66% of citizens wanted the war.
This way, it is more certain that if a country and its citizens want war they will get a _real_ war. And if citizens don't want a war they are less likely to somehow stumble into one (if you are another country why bother attacking such a country in self defense - just convince that country's citizens not to vote and you'll be fine and possibly rid of troublesome leaders).
Well to me programming has a lot more to do with the steps of "creating logic systems" (whether correct or consistent is another matter;) ), and as you said Math is more about the "formal logic systems" themselves. So whilst they are related I still don't see them as being the same.
And software engineering has to do with more formalized methods for creating and managing logic systems.
Another major difference: it is often very subjective as to whether a program is "correct" to the users and others involved. Whereas a math theorem's correctness tends to be a lot less subjective...
As for my having to rewrite some code. The problem is the code was written by someone else. And most of it is wrong in so many ways (programmer didn't seem to understand loops or SQL/databases properly or mind repeating blocks of code over and over again), but the code appears to others as "kinda working" in most cases.
You miss the point about why changing a database schema is hard. I can just as easily change it with a text file as you can with Lisp. The problem is when OTHER programs might expect the database schema to be in a certain _broken_ way, and it is worse if there is no authoritative list of all the other programs that use it. Often the database is the "interface" for the other programs.
Seems common in the lisp world to write/rewrite everything yourself (fortunately lisp is quite productive and powerful), but outside of the lisp world that doesn't happen so often - have to work with and keep other preexisting stuff.
Heh, as they fix all the stupid things, it starts to look more and more like Perl;).
Take away the popular but bad PHPisms like addslashes, magic quotes, cgi parameters automatically entering variable namespace, the combining of normal arrays with associative arrays/hashes (makes it messier to distinguish numeric keys from the indices), and you end up with something that is more Perl-ish than PHP-ish.
Which proves my point that PHP doesn't make it easy to do the _right_ thing.
It's not really standard is it, if with 5.1 the "future is supposed to be PDO?
So do I modify tons of old broken PHP4 code to use PEAR::DB and then when PHP5.1 or whatever is ready, remodify stuff to do PDO? Will PEAR::DB still work on PHP5.1? If it does, then I'd ignore PDO;). Of course the amount of 2nd round work involve depends on how easy it is to translate PEAR:DB to PDO - might only have to modify the 1st round DB lib.
The attacker could close the CDATA tag, whereas with my proposal, the attacker has to supply the correct "randomstring" in order to reenable normal behaviour ("default allow").
Given a suitable "randomstring" the odds of an attacker successfully closing the safety tag would be exceedingly low, even with future likely tags and browser features.
The current situation is: if someone adds a new tag or browser feature, it is less likely that you'd be blocking that by default, and that is _expected_ behaviour.
Whereas with my proposal, it is actually a bug in the browser if it doesn't restrict the enclosed content to only the allowed stuff (e.g. safe-html (no links or images) or even text only).
It doesn't have to be specifically the way I mentioned but there should be a way to disable "default permit". I'd actually prefer the tags to be something like: <safety lock="..."> and </safety lock="..."> , however someone said that's not proper HTML/XML - closing tags aren't supposed to have extra bits?
Years ago I proposed to the HTML and browser people that there be a "no-active" html tag, that marks enclosed content as nonactive.
Example:
<safetyon lock="randomstring" allowed="keyword1,keyword2,keyword3"/> potentially evil content from uncontrolled party - e.g. comments <safetyoff lock="randomstring"/>
keywords could be "textonly" "basic-html" "java" etc.
It seems everyone is more interested in "GO" tags. And nobody wants a "STOP" tag.
It's like having a thousand accelerator pedals and no brake pedal. The only way to stop is to make sure none of the accelerator pedals are pressed;).
Slashdot Mirror
SQL injection is not serious problem if the _standard_ way to access the DB makes it _easy_ to do things the _safe_ way.
Examples:
DBI and placeholders, JDBC and prepared statement stuff.
These methods help make sure that when you insert $somerawdata it ends up being treated as $somerawdata by the database and not "SOME SQL STATEMENT", and also when you retrieve the data back out from the database you can be sure that you will get back the same value- $somerawdata, and not something that you need to munge with stripslashes or addslashes. AND they make it easy to do it.
The problem with PHP is for <PHP5 you are unofficially supposed to use PEAR::DB and for PHP5 you are officially supposed to use PDO, and so most people find it easier to just keep doing the same wrong thing they have been doing for years (before pear and pdo) - use magic_quotes or addslashes, or worse don't even use it and get SQL injection.
This sloppiness and crapness is all over PHP. Another example is the silly way associative arrays and indexed arrays are done - they are combined - so if you try to have numeric keys things can get messy, your ['1'] and [1] can get confused.
Too much of programming PHP is avoiding or working around the many braindead bits it has.
You claim that brains are an example of more complexity = more reliable, but you can't even spell everything correctly. That's not going to be good if you are building a spell checker whether COSA or not.
I think your problem is you don't understand the real problem with software.
And I'm not even sure you really understand your proposed solution to whatever imaginary problem you are trying to solve.
Because it is so terribly WRONG and braindead like the other popular PHPisms[1].
;).
;) ).
It assumes that all data should be filtered the same way. And guess what, not all data destinations want their data to be quoted the way "Magic Quotes" quotes them.
Whereas the correct way is to have different input filters/quoting for each input path into your program so that your program can interpret and process data correctly. And different output filters/quoting for each output path from your program to other programs or consumers of the output (browsers, databases, files, phones/pagers, etc), so that those destinations can interpret and process the data correctly.
Why should data that's going to end up in a text file be "magic quoted"?
What happens if that data ends up being read and resubmitted to the application? Does it get "magic quoted" again?
Welcome to the data corrupted world of \' and \\\' and \\\\\'.
If you say stripslashes fixes that, you deserve a smack on the head - think about the scenario when data starts coming from other sources - email etc- do you have to start "magic quoting" all those sources as well so that stripslashes works?
Seems like PHP was written by stupid/ignorant people for stupid/ignorant people.
But hey that's probably the same reason why it is so popular
Sure mod me flamebait, but what I'm saying is true. Explain the stupid PEAR DB vs PDO thing in PHP. PHP is a new language, it should have had the equivalent of JDBC/DBI when it started - not the stupid "different functions for every DB" crap.
[1] PHP makes doing "the wrong thing" easy, and makes doing "nearly the right thing" hard and doing the "right thing" impossible (the right thing is to not use PHP
If anyone thinks Perl is bad, PHP is Perl done terribly and with crappier performance too.
mod_perl sucked and probably still sucks. Though fastcgi is a bit slower I prefer it - it is much less of a mess.
And no children without permission - no unauthorised reproduction of patented genetic material - we don't care that it was some virus that inserted "Our Patented DNA" into your germline, anymore than we do if wind spreads pollen containing "Our Patented DNA" to crops on your farm.
The reason why cheaper but less reliable hardware makes sense in most cases is:
1) Whether you use Dells or not, you still need backups.
2) Hardware gets obsoleted by software every 3 or so years (even the major Linux distros are getting on that bandwagon).
So if you have backups (like you should), if your PCs die on average every 2-3 years it doesn't really make such a big difference.
Why pay 30-50% more if you are still going to have to replace the darn thing in 3 years?
ONCE stuff starts stabilizing then maybe you'd start going for hardware that lasts longer.
So who's going to make sure that the humans have described their experiments _correctly_ in EXPO format?
Many of them already have difficulty describing it in whatever language they normally use.
What next? Require that witnesses/informants submit reports to the police in EXPO format?
Garbage in, garbage out.
That's one thing I've been wondering: will ants go for diet coke or similar artificial sweeteners? Would it still taste sweet to them?
Could you starve a colony that way?
Obviously secrecy isn't as important to your company.
600k for 7500 laptops isn't that bad assuming USD. 80/laptop, 16/year after that.
How much do you spend on crappy AV software for those 7500 laptops?
Uh, you better turn off swap in your host system and also make sure the "suspend vm" never suspends to plaintext.
Otherwise parts of your virtual machine could end up on the disk in plaintext- e.g. you run out of memory it gets swapped (does happen sometimes).
" as both of the major parties would be certain to get some huge negative score"
What makes you so certain about that?
And we should let one of them win instead of someone else? That sounds really weird for a democracy. Why not be ruled by some evil but efficient and effective Dictator then?
Hey, if the voters really hate the big parties and you end up with a bunch of independents who can't agree on anything (there is no party line), that's not such a bad thing - because it makes it harder for stuff like the DMCA to pass, or the constitution to be amended etc.
Sure the country will go nowhere fast for a while, but shouldn't that be preferable to being led by people who are hated by millions of voters?
Maybe if you could vote "No" to candidates there'd be a higher turnout.
A "No" vote = -1. "Yes" = +1.
The candidate with the most positive total or lease negative total wins.
In current "popular" systems if you don't like a candidate you have to vote for some other candidate or don't vote at all - this distorts stuff significantly - you could have a situation where a candidate wins even though hated by the majority, because the voters spread their votes amongst the other candidates. After a while the voters might end up just flip flopping between two fairly hated candidates, or give up entirely.
With my proposal if people really hate someone they get to "pull them backwards", rather than trying to figure out who else to "pull forwards" and hopefully the hated one doesn't win.
The popular method probably works fine if the _majority_ actually _like_ the candidates and want to _vote_for_ them, but it doesn't work if the majority don't. And perhaps the latter is true in the USA?
Uh, without any controls, the frigging torrents and video streams are more likely to get in the way of stuff like google searches for work-related tasks. It could make the quick "shopping trip" to Amazon take a fair bit longer.
It's quite annoying when a websearch takes 20 seconds to load because of some P2P crap or movie downloading.
If I were the admin, I'd still allow video streams, but they'd be on a lower priority compared to everything else.
I doubt even email should be held back just so someone can watch a video smoothly.
Sure policies, enforcement is always down to management and not tech. But this is more like basic traffic control.
"Keeping people alive _after_ a lifetime of doing the things that make them happy is one of the noblest goals of science."
:).
(emphasis mine).
Whoa there... I think people would rather not be kept alive for too long after their lifetime of doing the happy stuff...
Seriously though: a big problem is who pays for it.
Seems like we're heading to a future where repairing people will be increasingly be limited by money (resouces) than by medical technology. Not sure when we'd ever be able to afford to pay to repair everybody.
BTW in many countries smokers pay for more than their share in tobacco taxes, duties etc - so they're not a burden to everyone else. Smoking is addictive, so one can extract quite a lot of taxes from smokers.
Even more seriously though. I think "happiness" shouldn't be the top goal by itself. Otherwise scientists could more easily and cheaply wire people up and _make_ them artificially happy and keep them going till they are beyond repair - then they'd be still happy till their last living second.
Somehow that sort of artificial happiness doesn't seem that good to me (my biased subjective opinion).
In contrast there are people who go through unhappy circumstances, persecution etc, but are filled with joy - they know they are doing the right thing and are doing something good for others.
So, a lifetime of just doing things that make yourself happy seems rather empty in comparison.
Thus a recursive: changing yourself to be happy to make others happy (and helping them be happy making others happy and similarly helping those others ) seems more interesting and fruitful.
In our current universe there will always be sad times. There is a reason for hunger and pain.
Maybe there was a species that was born permanently happy but it died out a long time ago
There are plenty of other animals. If you don't like any, there's a high chance you don't really like humans that much either.
;).
Anyway what happens if you end up with a stupid barking airheaded child? There's a chance you might get one of those as a parent.
Those that just want to pass on their genes can donate their sperm/eggs
Perhaps there should be laws and regulations preventing just anyone from having kids ;).
;) ).
Maybe before anyone is allowed to have kids they must have provably brought up a dog of a not super-compliant breed to be well mannered, not destructive but still not totally cowed (can't have one always running away and hiding). The Regulatory body picks and assigns the dog (you don't get to choose the super easy candidates
If they don't pass, they have to keep paying maintenance for the dog and they don't get a chance to have kids till they get to try again and pass. (if they fail terribly the poor dog gets taken away from them for its own good),
If they can't bring up a dog, they can't bring up a human. After most dogs have been bred to be tolerably obedient over the generations. Not so for most humans (not saying it is good or bad, but it is something to keep in mind when training humans).
Sounds good to me too. Some crying is fine, but I've seen kids where the crying is so obviously faked ("crying about nothing" as you imply) that it is annoying that their parents still let themselves be manipulated by it. Deceit and deception should not be encouraged by parents - some kids already have enough internal desire/motivation/reasons to deceive which the parents have to counter.
All that stuff about kids fragile egos and self-esteem is bullshit (dangerous too IMO).
Most kids think the world revolves around them or think it should, they definitely need to be domesticated/trained to think otherwise- even if the only reason is it is untrue. (The small minority of "angel" kids? You'd spot them fairly quickly).
I never understood all that talk about boosting kids self-esteem.
Why praise people for just being in their current state? If you want a well trained dog you don't praise it just for being itself. You can love a person for just being in their current state (and show that love). But don't just dish out praise for anything.
You praise your kid/dog/subordinate for doing something good. And scold them or even punish them for doing something bad.
If you can't figure out what is good and bad, don't frigging be a parent.
As for not physically punishing kids, that's stupid as well. Pain affects the subconscious and conscious, so it is very effective in training. However you want to train the child to avoid doing the wrong thing, and not train the child to avoid you all the time. Pain should never be the dominant tone at all: you also want the child to _want_ to do the good stuff as well because the child enjoys doing good.
So what if the kid doesn't do anything bad, not very impressive if the kid doesn't do anything good either.
Don't need that much history. Just consider the now and the future:
Who is a greater danger to the USA? The President/Gov of the USA or the "enemy combatants" in Iraq?
Who has caused more damage? Who has the potential to cause more damage? Who is more likely to cause more damage?
BTW I heard the US Military's budget is the equivalent to the combined military budgets of the next top 20 military spending countries.
I guess all that spending is not doing you all that much good. Not very cost-effective is it?
How about my suggestion?
I think that's not such a great way to prevent unnecessary wars.
You think sociopathic leaders really care about "sending our soldiers to die"? They don't really. Lots of troops dying is just a cost-benefit factor to them.
My suggestion therefore is that before a Proposal for an _offensive_ war is approved, there has to be a referendum. If there aren't enough positive votes (say 66%), the people involved in the war proposal are put on _death_row_.
Then at a convenient time another referendum is taken: a "Redemption" one, if there aren't enough positive votes for a condemned person that person is executed after a suitable waiting period - so if people just stay home or do whatever they want and not bother voting, good riddance to unwanted politicians.
If in the end it turns out that a war was justified, if that person was already executed, they get the equivalent of a purple heart or whatever award dead soldiers get, and their families get some pension, and some official ceremony or something to remember them blah blah blah.
If it turns out there was deception involved in getting a proposal passed, the people involved get put on death row.
The other notable effects:
More soldiers would be more willing to fight because they know their leaders were willing to risk their own lives AND >=66% of their citizens think that the war is called for.
The enemy soldiers would feel more at ease at defending themselves even up to the point of wiping out the attacking country - after all >=66% of citizens wanted the war.
This way, it is more certain that if a country and its citizens want war they will get a _real_ war. And if citizens don't want a war they are less likely to somehow stumble into one (if you are another country why bother attacking such a country in self defense - just convince that country's citizens not to vote and you'll be fine and possibly rid of troublesome leaders).
I think this is a lot more _fair_.
Well to me programming has a lot more to do with the steps of "creating logic systems" (whether correct or consistent is another matter ;) ), and as you said Math is more about the "formal logic systems" themselves. So whilst they are related I still don't see them as being the same.
And software engineering has to do with more formalized methods for creating and managing logic systems.
Another major difference: it is often very subjective as to whether a program is "correct" to the users and others involved. Whereas a math theorem's correctness tends to be a lot less subjective...
As for my having to rewrite some code. The problem is the code was written by someone else. And most of it is wrong in so many ways (programmer didn't seem to understand loops or SQL/databases properly or mind repeating blocks of code over and over again), but the code appears to others as "kinda working" in most cases.
You miss the point about why changing a database schema is hard. I can just as easily change it with a text file as you can with Lisp. The problem is when OTHER programs might expect the database schema to be in a certain _broken_ way, and it is worse if there is no authoritative list of all the other programs that use it. Often the database is the "interface" for the other programs.
Seems common in the lisp world to write/rewrite everything yourself (fortunately lisp is quite productive and powerful), but outside of the lisp world that doesn't happen so often - have to work with and keep other preexisting stuff.
Heh, as they fix all the stupid things, it starts to look more and more like Perl ;).
Take away the popular but bad PHPisms like addslashes, magic quotes, cgi parameters automatically entering variable namespace, the combining of normal arrays with associative arrays/hashes (makes it messier to distinguish numeric keys from the indices), and you end up with something that is more Perl-ish than PHP-ish.
PHP and MySQL, what a combination... hehe.
Which proves my point that PHP doesn't make it easy to do the _right_ thing.
;). Of course the amount of 2nd round work involve depends on how easy it is to translate PEAR:DB to PDO - might only have to modify the 1st round DB lib.
It's not really standard is it, if with 5.1 the "future is supposed to be PDO?
So do I modify tons of old broken PHP4 code to use PEAR::DB and then when PHP5.1 or whatever is ready, remodify stuff to do PDO? Will PEAR::DB still work on PHP5.1? If it does, then I'd ignore PDO
The attacker could close the CDATA tag, whereas with my proposal, the attacker has to supply the correct "randomstring" in order to reenable normal behaviour ("default allow").
Given a suitable "randomstring" the odds of an attacker successfully closing the safety tag would be exceedingly low, even with future likely tags and browser features.
The current situation is: if someone adds a new tag or browser feature, it is less likely that you'd be blocking that by default, and that is _expected_ behaviour.
Whereas with my proposal, it is actually a bug in the browser if it doesn't restrict the enclosed content to only the allowed stuff (e.g. safe-html (no links or images) or even text only).
It doesn't have to be specifically the way I mentioned but there should be a way to disable "default permit".
I'd actually prefer the tags to be something like: <safety lock="..."> and </safety lock="..."> , however someone said that's not proper HTML/XML - closing tags aren't supposed to have extra bits?
Security is a low priority.
/>
;).
:).
Years ago I proposed to the HTML and browser people that there be a "no-active" html tag, that marks enclosed content as nonactive.
Example:
<safetyon lock="randomstring" allowed="keyword1,keyword2,keyword3"
potentially evil content from uncontrolled party - e.g. comments
<safetyoff lock="randomstring"/>
keywords could be "textonly" "basic-html" "java" etc.
It seems everyone is more interested in "GO" tags. And nobody wants a "STOP" tag.
It's like having a thousand accelerator pedals and no brake pedal. The only way to stop is to make sure none of the accelerator pedals are pressed
Maybe I should try again