Are you saying anyone who ever took part in a boxing-match can be sued for assault in the UK
Under the Spanner decision, which ruled that British subjects do not have the right to consent to an activity which may cause actual bodily harm, the answer is "yes".
While Spanner was about private sadomasochistic activity between consenting adults, the exact same arguments apply to a boxing match between consenting adults.
Here's a hint -- quoting Biblical scripture to a thinking non-Christian is a futile effort.
In order for someone to accept what the Bible says, they have to ALREADY been instilled with the belief that the Bible is somehow authoritative. This cannot be done to anyone with functional critical thinking skills -- they will immediately spot the glaring logical fallacies and reject your arguments.
There are two ways to get around this. The first is to indoctrinate them in childhood, before they've developed the capacity for rational thought. The other is to find a mentally defective adult who is either incapable of recognizing a logically flawed argument or one who is so emotionally distraught that they'll latch on to the first thing they find that offers some relief, regardless of whether or not it makes any sense.
The fact that you cannot see or acknowledge the logical flaws on which your religion is based demonstrates that you either are incapable of rational thought or that you're unable to overcome the brainwashing you were subjected to as a child.
Bush, who got a lot of his support from the working class...
Not entirely correct. He got a lot of his support from the rabid fundie nutbar class, who just happen to be predominatly poorly-educated, blue collar, working-class folks.
I would say that excellent people would be needed to effectively use Lisp as an advantage
I think that Graham's underlying concept is that the people who are capable of grokking Lisp are excellent programmers. Lisp is so far out of the mainstream that only the true hacker elite are going to bother learning it.
In re-reading my post, I don't think I really said in this last bit what I intended (ironic, in a discussion about language). The language is important, but no language will handle design for you, despite any claims of the vendor.
I agree entirely. However, while no language will handle design for you, the language can make good design easier (or harder). Object-oriented languages tend to encourage better design patterns than procedural ones. Languages that prevent entire classes of bugs simplify the design. Languages with rich function/class libraries and solid application frameworks make good design easier. And so forth.
the cost of learning something new is never small
True. But the cost of *not* learning something new can be high too. Sometimes the cost of learning something new is lower than the cost maintaining the status quo. If learning a new language/tool can increase your produtivity/effectiveness, than you have to look at the total cost.
Let's say you're in a typical Visual Basic shop. You estimate that a project is going to take the team 12 month to complete in VB. Now, let's say that it would take 3 months for the team to learn a more efficient language well enough to complete the project. Because the new language is so much more efficient, you'll be able to finish the project in 8 months instead of 12. So by learning a new language, not only do you have the project complete a month early, but you'll be able to do future projects that much more efficiently.
I am currently CTO for a website with 100 mio pageviews/month, doing about 10 queries per page at 1 million members.
That's nice. I administer the world's largest public database of genomic information.
If you were paying attention, you'll notice that I said *most*, not *all*. There are always exceptions to every rule and outliers on every trend. Your system is NOT a typical business application and is representitive of neither the bulk of software being developed nor of the type of work most programmers do on a daily basis. Neither is the system I currently administer. What's appropriate for special boundry cases is not necessarily appropriate for the median case.
Without knowing specifics, I'll tentatively agree that *YOUR* application probably benefits from good requirements and a very formal development methodology. That kind of method works fine if you have a well-defined task, a seven or eight-figure budget, and a staff of 50+ people. It's totally inappropriate for most start-ups as well as for most in-house business applications in established companies. What works for you does not necessarily work for everyone.
If you're writing a compiler or device driver, your requirements are pretty clear and the language/hardware specifications aren't going to change rapidly. When you're supporting scientific research or developing a new buisiness concept, your requirements can (and often do) change daily.
If you're writing an embedded system, be it the flight controls for an airliner or the controller for a microwave oven, your requirements are well defined (as they are dictated by the hardware) and will definately benefit from a formal development methodology. If you're automating an existing business process in a large (or even medium-sized) company, you'll be hard-pressed to find two people in the organization who even agree what the requirements are. When half (or more) of the project is *identifying* the actual requirements, an incremental rapid prototyping approach often lets you get to a workable solution faster. The prototype itself becomes a tool for gathering the requirements and building consensus.
I'd advise you to remember that business is rough, and you are always in danger of being outclassed by a smaller, more agile startup. Consider for a moment that it might not be necessary to have hundreds of servers and write hundreds of thousands of lines of code per year to do the same job, if you used a more efficient technology and development approach.
Then, in the end, the programming language matters, but not for technical reasons.
I have to disagree with you. It's almost entirely technical (although we might have different definitions of what "technical reasons" are).
Price, is one thing
My experience has been that software licencing costs generally are only a very small percentage of the total cost of a development effort. Hardware cost is significant, and is hugely impacted by technical efficiency. YMMV, but my experience has been that the biggest expense in the vast majority of development projects is human resources. Programmer time is expensive; using more efficent/powerful languages means you need fewer man/months to deliver the same results. More maintainable code means lower support costs. More elegant technology is easier to administer and has less downtime, resulting in lower operational expenses. Etc.
Continuity of the language, another
Overrated, IMHO. Even if you've saddled yourself with some propriatary monstrosity, your current set of development tools will keep working exactly the same way they do now in perpetuity. Bits don't rot. Visual Studio 6 may be unsupported now and won't get any further updates, but there's nothing that's going to prevent you from using it IN IT'S CURRENT STATE for the next 20 years. If it's not good enough *now*,
As far as scaleing CF runs the number 5 site on the internet MYSPACE.COM
How much development effort went into make it handle that load? How much hardware is needed to support the load compared to other sites with similar volume that use different technology?
Hotmail originally ran on (IIRC) FreeBSD & Apache. When Microsoft accquired them they started switching over to an Windows/IIS architecture in an eat-your-own-dog-food move. It took a long time to complete the transition (if they ever have) as they found that it took something like 3x as much hardware to handle the same load using Win[NT|2K].
Programming languages:
- don't make scalable applications.
- don't draft designs or requirements.
- don't make code that is easily readable and maintainable.
- don't create bugs or do poor optimization or create application bottle necks.
These things are done by programmers.
True, but language choice make can make a huge impact in software quality and programmer productivity / effectiveness.
While I'm a fan of having good requirements, realistically it's often impossible to know the requirements up front for most applications. Very often, the only way you'll know all the requirements up front is if the application has already been written (EG reverse engineering or refactoring). Detailed requrements are FANTASTIC for imbedded systems and similar well-defined tasks (EG Compilers, operating systems, device drivers), but most applications are not in this category. Business applications (and the business processes they automate) are rarely that well defined, and they tend to evolve rapidly, especially in a small/startup company.
For this reason, I've come to the conclusion that a rapid prototyping approach with short (daily to weekly) release cycles and lots of user feedback is usually the right approach for most business apps. Scripting languages and a web architecture make this development methodology a lot more feasible. Compiled languages work better for the same kind of well-defined tasks that benefit from exhaustive requirements.
Scalability is also hugely impacted by language choice. Some languages don't handle threading well (or at all). Some have huge run-time overhead. Etc.
Readability and maintainability is also a function of language choice. You can write obfuscated code in any langugage, but in some languages (cough *perl* cough) it takes a deliberate effort to write *UN*obfuscated, maintainable code while others (SQL) make obfuscation fairly difficult.
Some languages make it easier to introduce bugs than others. For instance, in C/C++ it takes a lot of effort to prevent memory leaks and buffer overruns; languages which have native garbage collection and bounds-checking completely eliminate those kinds of bugs.
I agree with many other people posting. The language itself is not important. Good design and good people are what leads to good code. The language is only a tool.
Paul Graham would disagree with you.
Languages are tools, true. But not all tools are equally powerful. Some languages are better designed than others, and allow you to do things easily that are difficult (if not impossible) in other languages:
I'll begin with a shockingly controversial statement: programming languages vary in power.
Few would dispute, at least, that high level languages are more powerful than machine language. Most programmers today would agree that you do not, ordinarily, want to program in machine language. Instead, you should program in a high-level language, and have a compiler translate it into machine language for you. This idea is even built into the hardware now: since the 1980s, instruction sets have been designed for compilers rather than human programmers.
Everyone knows it's a mistake to write your whole program by hand in machine language. What's less often understood is that there is a more general principle here: that if you have a choice of several languages, it is, all other things being equal, a mistake to program in anything but the most powerful one.
He goes on to say tha the most powerful language around is Lisp:
Many languages have something called a macro. But Lisp macros are unique. And believe it or not, what they do is related to the parentheses. The designers of Lisp didn't put all those parentheses in the language just to be different. To the Blub programmer, Lisp code looks weird. But those parentheses are there for a reason. They are the outward evidence of a fundamental difference between Lisp and other languages.
Lisp code is made out of Lisp data objects. And not in the trivial sense that the source files contain characters, and strings are one of the data types supported by the language. Lisp code, after it's read by the parser, is made of data structures that you can traverse.
If you understand how compilers work, what's really going on is not so much that Lisp has a strange syntax as that Lisp has no syntax. You write programs in the parse trees that get generated within the compiler when other languages are parsed. But these parse trees are fully accessible to your programs. You can write programs that manipulate them. In Lisp, these programs are called macros. They are programs that write programs.
Programs that write programs? When would you ever want to do that? Not very often, if you think in Cobol. All the time, if you think in Lisp. It would be convenient here if I could give an example of a powerful macro, and say there! how about that? But if I did, it would just look like gibberish to someone who didn't know Lisp; there isn't room here to explain everything you'd need to know to understand what it meant. In Ansi Common Lisp I tried to move things along as fast as I could, and even so I didn't get to macros until page 160.
But I think I can give a kind of argument that might be convincing. The source code of the Viaweb editor was probably about 20-25% macros. Macros are harder to write than ordinary Lisp functions, and it's considered to be bad style to use them when they're not necessary. So every macro in that code is there because it has to be. What that means is that at least 20-25% of the code in this program is doing things that you can't easily do in any other language. However skeptical the Blub programmer might be about my claims for the mysterious powers of Lisp, this ought to make him curious. We weren't writing this code for our own amusement. We were a tiny startup, programming as hard as we could in order to put technical barriers between us and our competitors.
A suspicious person might begin to wonder if there wa
Saying "don't login as root" is horseshit. It stems from the days when people sniffed the first packets of sessions so logging in as yourself and su-ing decreased the chance an attacker would see the root pw
That may have been the reason you did it in the past, but it's not the reason you do it now. The reason for not logging in directly as root (or under any other shared accout, for that matter) is ACCOUNTABILITY. If you log in as root directly, all that gets logged is the host you came from. If you force them to log in as themselves, and then su to root, you have a record of who did it. This is important when you have a machine where a dozen admins all know the password to a shared account.
I concur completely. Disney represents the epitomy of corporate greed and hipocricy, as well as the mediocrity of pop culture. If it were up to me, they would get none of my money; unfortunately my wife and kids have different ideas.
That said, I won't be visiting any of their parks in the forseeable future. The only finger of mine they'll be seeing is the middle one.
I disagee. It is a deliberate torpedo, because the CPU manufacturer is irrelevant as to whether or not a feature is supported -- only the feature flag matters. If you deliberately check for an irrelevant factor that automatically cripples performance on competing CPUs, you're torpedoing them.
Checking for the FDIV bug would be a valid reason for generating different code for AMD and Intel cpus, because only (some) intel processors have that "feature". Automatically assuming *all* intel cpus have the FDIV bug would not be valid.
Checking for the ht (hyperthread) flag would be a valid distinction between AMD and Intel, because only Intel has that feature, IF the presence or absence of hyperthreading is relevant to the code path selected. Using the absense of ht to force non-ht processors down an unoptimized code path that is not affected by hyperthreading is not valid.
Intel not supporting 3dnow in their compiler would be valid because none of their processors have it. Using the presense of the 3dnow flag to do (or not do) something would be invalid, because it's completely irrelvant to any of their processors.
From what I've read so far, it does look like they're intentionally torpedoing AMD chips.
They do this by having the generated code look at the manufacturer field, rather than the feature flag, to determine whether or not to use a feature like SSE. An AMD chip will correctly report that it supports SSE, but code from the intel compiler won't honor the flag if it's a non-intel chip.
EG, their own published standard calls for something like this:
If the code requires feature X, the only thing the code should check is the relevant feature flag. The manufacturer is irrelevant, only the reported capabilities matter.
If it's a design flaw in PHP then it's a design flaw in many other languages, by your logic
Yep. Just because everyone else is doing it, doesn't make it right.
For both POST and GET, user input from a web form is, by definition, passed to your program as a URL-encoded string. In order to use that string in your program, it has to be decoded, parsed out into name-value pairs, and then be assigned to the appropriate user variables and/or objects. There's ample opportunity to validate the input in this process. For a language that is specifically designed to handle web forms, this validation should be as automatic and transparent as is possible, especially when you consider that you MUST anticipate that a malicious user can submit any arbitrary set of values via the POST or GET.
In a strongly-typed language, it's impossible to assign an invalid value to a variable -- an illegal assignment will either throw an error or be subjected to a well-defined conversion rule. EG: if I define a variable as an 80-char string, then if I attempt to assign 200 chars to that variable the language should react in a well-defined manner, by either throwing an error or silently truncating the input. While variant data types / typeless variables are useful (and sometimes indispensable), it places the burden for type-checking on the programmer. In a language targeted at novices / non-programmers, this is dangerous -- this class of user can't be relied on to do manual type checking.
However, even in a loosely-typed language, there's no excuse for an object's constructor to not sanitize, validate, and type-check the input it is given, particuarly if it's performing some security-critical or commonly-exploited operation.
there are a lot more careless coders out there coding in PHP.
That's exactly the issue. This isn't a PHP vulnerability. It's a poorly written script that doesn't check input properly
I'd say while it isn't exactly a PHP vulnerability it is an inherent PHP design flaw, which renders PHP dangerous (if not useless) for it's intended user community.
To make an analogy, let's look at C. The C language was invented for systems programming, and it excels in that role -- C has been the language of choice for low level hacking for 20+ years. There's a damn good reason that OS kernels and device drivers are written in C -- it gives an expert programmer near-total control of the hardware.
However, this very power is C's downfall when it's used for general application programming. In the hands of anyone other than an expert, C is dangerous because it places too much demand on the programmer to do things "the right way", rather than preventing those errors from ever happening in the first place. It's trivially easy to introduce a buffer overflow or a memory leak into a C program, because the language intentionally does not do bounds checking or garbage collection. Languages which are intended for developing applications include these features -- they intentionally introduce run-time overhead so that the programmer can concentrate his attention on the application's logic rather than working around the language's shortcomings.
Having to manually write code to check each and every user input in an application is a horribly inefficent use of programmer time, and is prone to errors of omission. The development process is FAR more efficent if the language does this kind of housekeeping for the programmer automatically and transparently. This principle is doubly true for a scripting language like PHP, which is intended to be used by people who don't have a solid software engineering background.
Forcing someone to do something against their will was not what Jesus was about.
I think you need to educate your co-religionists on that interpretation.
There a largenumber of people who call themselves "christians" who have repeatedly demonstrated a willingness to use the might of the Government to force everyone else to live according to the dictates of their religion.
Part of the problem is that practically no one can agree on a definition of what a "christian" really is.
From my observations, a typical member of the religious right would define a Christian as being "someone who belives that the Bible is the literal, inerrant Word of God, and has accepted Jesus Christ as their personal savior." There are millions of people who would be "Christians" under this definition -- but there are many, many "Christians" who don't meet this definition.
From my (admittedly dim) recollections of Sunday School, the Roman Catholic church teaches a more inclusive definition: everyone who has been baptized is a Christian. This definition covers a lot of people who don't meet the more stringent fundimentalist protestant definiton above.
Personally, I believe the rational definition of Christian is "someone who lives their life in accordance with the actual moral philosophy taught by Jesus of Nasareth himself" (as opposed to those, for example, who follow the contridictory teachings of Paul of Tarsus). There are very, very few people on the planet who qualify as Christians under this more stringent definition. You don't see this kind of Christian very often, because they are usually out meekly serving others, instead of making themselves rich and famous by preaching hatred and intolerance on the television while scamming money from their congregations.
How is it determined which of the justices is the "swing vote"?
By keeping track of who votes together. Justices Rhenquist, Scalia, and Thomas generally all vote the neo-con party line together, Souter usually joins them. Breyer, Ginsburg, and Stevens usually vote the traditional liberal party line as a bloc. Kennedy and O'Connor can go either way on any issues, although O'Connor tends to lean a bit to the right and Kennedy a bit to the left.
With O'Connor retiring and Rhenquist on his way out (one way or the other), it looks like we're going to have a SC with 4 hard-right justices (Scalia, Thomas, and 2 new ones), one medium-right (Souter), one moderate (Kennedy) and three left (Breyer, Ginsburg, and Stevens).
This new structure pretty much wraps up the Supreme Court for the neo-cons 5-4 on any partisan issue. Say goodbye to all forms of sexual freedom (including legalized abortion), seperation of church and state, and the right to privacy.
She's the main swing vote on the court. She leans more towards the conservitive side, although she's got a fairly good record of voting in favor of individual liberties.
Given that we have a GOP-controlled House, Senate, and Presidency which kowtows to the fundie nutbars, it's almost certian we're going to get a hardcore far right judge as a replacement. When that happens, kiss the Bill of Rights goodbye.
All I want to do is receive mail and send it to 3 users on my machine, and have them be able to send mail via TB to the server without it become a spam relay. Why is this so damn hard.
The default postfix config that comes with Fedora Core is probably all you need. FC installs sendmail by default, so you need to install postfix and switchmail (and probably dovecot, if you want pop3/imap capability:
Assuming you already have your MX record set up and port 25 open to the world, you should then only have to change 3 lines in/etc/postfix/main.cf to be able to send & recieve email from any machine on your LAN to anywhere in the world:
The only gotcha is that if you are on a cable modem / dsl, some ISPs (AOL) might not accept your mail based on your IP. In that case you need to make one more change to main.cf:
relayhost = smtp.myisp.net
This forces all outbound mail to go through your ISP's official mail server.
Then all you have to do is (re)start postfix:
service postfix restart
It's that easy.
You can do more tweaking to improve security and set up spam & virus filtering, but those are complicated topics and are therefore complicated to configure. Switching to use maildir delivery (vs the default mbox format) is trivial to do, and is left as an exersize for the reader.
Let's see... a developer wants to build a hotel on the land now occupied by Justice Souter's home, to be financed with investments from pro-Liberty individuals.
Slashdot Mirror
While Spanner was about private sadomasochistic activity between consenting adults, the exact same arguments apply to a boxing match between consenting adults.
In order for someone to accept what the Bible says, they have to ALREADY been instilled with the belief that the Bible is somehow authoritative. This cannot be done to anyone with functional critical thinking skills -- they will immediately spot the glaring logical fallacies and reject your arguments.
There are two ways to get around this. The first is to indoctrinate them in childhood, before they've developed the capacity for rational thought. The other is to find a mentally defective adult who is either incapable of recognizing a logically flawed argument or one who is so emotionally distraught that they'll latch on to the first thing they find that offers some relief, regardless of whether or not it makes any sense.
The fact that you cannot see or acknowledge the logical flaws on which your religion is based demonstrates that you either are incapable of rational thought or that you're unable to overcome the brainwashing you were subjected to as a child.
Let's say you're in a typical Visual Basic shop. You estimate that a project is going to take the team 12 month to complete in VB. Now, let's say that it would take 3 months for the team to learn a more efficient language well enough to complete the project. Because the new language is so much more efficient, you'll be able to finish the project in 8 months instead of 12. So by learning a new language, not only do you have the project complete a month early, but you'll be able to do future projects that much more efficiently.
That's nice. I administer the world's largest public database of genomic information.
If you were paying attention, you'll notice that I said *most*, not *all*. There are always exceptions to every rule and outliers on every trend. Your system is NOT a typical business application and is representitive of neither the bulk of software being developed nor of the type of work most programmers do on a daily basis. Neither is the system I currently administer. What's appropriate for special boundry cases is not necessarily appropriate for the median case.
Without knowing specifics, I'll tentatively agree that *YOUR* application probably benefits from good requirements and a very formal development methodology. That kind of method works fine if you have a well-defined task, a seven or eight-figure budget, and a staff of 50+ people. It's totally inappropriate for most start-ups as well as for most in-house business applications in established companies. What works for you does not necessarily work for everyone.
If you're writing a compiler or device driver, your requirements are pretty clear and the language/hardware specifications aren't going to change rapidly. When you're supporting scientific research or developing a new buisiness concept, your requirements can (and often do) change daily.
If you're writing an embedded system, be it the flight controls for an airliner or the controller for a microwave oven, your requirements are well defined (as they are dictated by the hardware) and will definately benefit from a formal development methodology. If you're automating an existing business process in a large (or even medium-sized) company, you'll be hard-pressed to find two people in the organization who even agree what the requirements are. When half (or more) of the project is *identifying* the actual requirements, an incremental rapid prototyping approach often lets you get to a workable solution faster. The prototype itself becomes a tool for gathering the requirements and building consensus.
I'd advise you to remember that business is rough, and you are always in danger of being outclassed by a smaller, more agile startup. Consider for a moment that it might not be necessary to have hundreds of servers and write hundreds of thousands of lines of code per year to do the same job, if you used a more efficient technology and development approach.
I have to disagree with you. It's almost entirely technical (although we might have different definitions of what "technical reasons" are).
My experience has been that software licencing costs generally are only a very small percentage of the total cost of a development effort. Hardware cost is significant, and is hugely impacted by technical efficiency. YMMV, but my experience has been that the biggest expense in the vast majority of development projects is human resources. Programmer time is expensive; using more efficent/powerful languages means you need fewer man/months to deliver the same results. More maintainable code means lower support costs. More elegant technology is easier to administer and has less downtime, resulting in lower operational expenses. Etc.
Overrated, IMHO. Even if you've saddled yourself with some propriatary monstrosity, your current set of development tools will keep working exactly the same way they do now in perpetuity. Bits don't rot. Visual Studio 6 may be unsupported now and won't get any further updates, but there's nothing that's going to prevent you from using it IN IT'S CURRENT STATE for the next 20 years. If it's not good enough *now*,
Hotmail originally ran on (IIRC) FreeBSD & Apache. When Microsoft accquired them they started switching over to an Windows/IIS architecture in an eat-your-own-dog-food move. It took a long time to complete the transition (if they ever have) as they found that it took something like 3x as much hardware to handle the same load using Win[NT|2K].
While I'm a fan of having good requirements, realistically it's often impossible to know the requirements up front for most applications. Very often, the only way you'll know all the requirements up front is if the application has already been written (EG reverse engineering or refactoring). Detailed requrements are FANTASTIC for imbedded systems and similar well-defined tasks (EG Compilers, operating systems, device drivers), but most applications are not in this category. Business applications (and the business processes they automate) are rarely that well defined, and they tend to evolve rapidly, especially in a small/startup company.
For this reason, I've come to the conclusion that a rapid prototyping approach with short (daily to weekly) release cycles and lots of user feedback is usually the right approach for most business apps. Scripting languages and a web architecture make this development methodology a lot more feasible. Compiled languages work better for the same kind of well-defined tasks that benefit from exhaustive requirements.
Scalability is also hugely impacted by language choice. Some languages don't handle threading well (or at all). Some have huge run-time overhead. Etc.
Readability and maintainability is also a function of language choice. You can write obfuscated code in any langugage, but in some languages (cough *perl* cough) it takes a deliberate effort to write *UN*obfuscated, maintainable code while others (SQL) make obfuscation fairly difficult.
Some languages make it easier to introduce bugs than others. For instance, in C/C++ it takes a lot of effort to prevent memory leaks and buffer overruns; languages which have native garbage collection and bounds-checking completely eliminate those kinds of bugs.
Mono, while it has made great strides, is not ready for production use. (IMHO)
Paul Graham would disagree with you. Languages are tools, true. But not all tools are equally powerful. Some languages are better designed than others, and allow you to do things easily that are difficult (if not impossible) in other languages:
He goes on to say tha the most powerful language around is Lisp:
It's "mundane detail", not "Monday detail". If you're going to quote Office Space, at least get it right.
That said, I won't be visiting any of their parks in the forseeable future. The only finger of mine they'll be seeing is the middle one.
It sounds like you need to develop a better method of selecting girlfriends.
Checking for the FDIV bug would be a valid reason for generating different code for AMD and Intel cpus, because only (some) intel processors have that "feature". Automatically assuming *all* intel cpus have the FDIV bug would not be valid.
Checking for the ht (hyperthread) flag would be a valid distinction between AMD and Intel, because only Intel has that feature, IF the presence or absence of hyperthreading is relevant to the code path selected. Using the absense of ht to force non-ht processors down an unoptimized code path that is not affected by hyperthreading is not valid.
Intel not supporting 3dnow in their compiler would be valid because none of their processors have it. Using the presense of the 3dnow flag to do (or not do) something would be invalid, because it's completely irrelvant to any of their processors.
For both POST and GET, user input from a web form is, by definition, passed to your program as a URL-encoded string. In order to use that string in your program, it has to be decoded, parsed out into name-value pairs, and then be assigned to the appropriate user variables and/or objects. There's ample opportunity to validate the input in this process. For a language that is specifically designed to handle web forms, this validation should be as automatic and transparent as is possible, especially when you consider that you MUST anticipate that a malicious user can submit any arbitrary set of values via the POST or GET.
In a strongly-typed language, it's impossible to assign an invalid value to a variable -- an illegal assignment will either throw an error or be subjected to a well-defined conversion rule. EG: if I define a variable as an 80-char string, then if I attempt to assign 200 chars to that variable the language should react in a well-defined manner, by either throwing an error or silently truncating the input. While variant data types / typeless variables are useful (and sometimes indispensable), it places the burden for type-checking on the programmer. In a language targeted at novices / non-programmers, this is dangerous -- this class of user can't be relied on to do manual type checking.
However, even in a loosely-typed language, there's no excuse for an object's constructor to not sanitize, validate, and type-check the input it is given, particuarly if it's performing some security-critical or commonly-exploited operation.
To make an analogy, let's look at C. The C language was invented for systems programming, and it excels in that role -- C has been the language of choice for low level hacking for 20+ years. There's a damn good reason that OS kernels and device drivers are written in C -- it gives an expert programmer near-total control of the hardware.
However, this very power is C's downfall when it's used for general application programming. In the hands of anyone other than an expert, C is dangerous because it places too much demand on the programmer to do things "the right way", rather than preventing those errors from ever happening in the first place. It's trivially easy to introduce a buffer overflow or a memory leak into a C program, because the language intentionally does not do bounds checking or garbage collection. Languages which are intended for developing applications include these features -- they intentionally introduce run-time overhead so that the programmer can concentrate his attention on the application's logic rather than working around the language's shortcomings.
Having to manually write code to check each and every user input in an application is a horribly inefficent use of programmer time, and is prone to errors of omission. The development process is FAR more efficent if the language does this kind of housekeeping for the programmer automatically and transparently. This principle is doubly true for a scripting language like PHP, which is intended to be used by people who don't have a solid software engineering background.
There a large number of people who call themselves "christians" who have repeatedly demonstrated a willingness to use the might of the Government to force everyone else to live according to the dictates of their religion.
Part of the problem is that practically no one can agree on a definition of what a "christian" really is.
From my observations, a typical member of the religious right would define a Christian as being "someone who belives that the Bible is the literal, inerrant Word of God, and has accepted Jesus Christ as their personal savior." There are millions of people who would be "Christians" under this definition -- but there are many, many "Christians" who don't meet this definition.
From my (admittedly dim) recollections of Sunday School, the Roman Catholic church teaches a more inclusive definition: everyone who has been baptized is a Christian. This definition covers a lot of people who don't meet the more stringent fundimentalist protestant definiton above.
Personally, I believe the rational definition of Christian is "someone who lives their life in accordance with the actual moral philosophy taught by Jesus of Nasareth himself" (as opposed to those, for example, who follow the contridictory teachings of Paul of Tarsus). There are very, very few people on the planet who qualify as Christians under this more stringent definition. You don't see this kind of Christian very often, because they are usually out meekly serving others, instead of making themselves rich and famous by preaching hatred and intolerance on the television while scamming money from their congregations.
With O'Connor retiring and Rhenquist on his way out (one way or the other), it looks like we're going to have a SC with 4 hard-right justices (Scalia, Thomas, and 2 new ones), one medium-right (Souter), one moderate (Kennedy) and three left (Breyer, Ginsburg, and Stevens).
This new structure pretty much wraps up the Supreme Court for the neo-cons 5-4 on any partisan issue. Say goodbye to all forms of sexual freedom (including legalized abortion), seperation of church and state, and the right to privacy.
Given that we have a GOP-controlled House, Senate, and Presidency which kowtows to the fundie nutbars, it's almost certian we're going to get a hardcore far right judge as a replacement. When that happens, kiss the Bill of Rights goodbye.
Why do the folks who insist on keeping "God" in "one nation under God" want to get rid of "liberty and justice for all"?
Better? Trust me, we're on the same side.
Then all you have to do is (re)start postfix:
It's that easy.You can do more tweaking to improve security and set up spam & virus filtering, but those are complicated topics and are therefore complicated to configure. Switching to use maildir delivery (vs the default mbox format) is trivial to do, and is left as an exersize for the reader.
Only one question: where do I send my check?