OTOH, if you aren't in an ivory tower and have to program for a living, then PHP is like C, a language the "perfessors" hate,but it keeps working just fine for the 99.5% of us.
Would that be the 99.5% of all C apps that have weekly buffer overflow exploit notices?
Or would that be the 99.5% of PHP apps that have constant SQL and variable injection attacks. *cough* PHP XML_RPC support *cough*
In the beginning, you had files and web servers. Then people starting writing extensions to the web servers and the dynamic web was born.
But the problems with patching your web server for even the slightest dynamism were immediately obvious even in the early days of "a patchy server". So CGI (Common Gateway Interface) was born and Perl rose up as the dominant web language. Process creation overhead became an issue as the web took off so techniques for mitigating this were put in like mod_perl, servlets, etc., but overall the process stayed the same.
People started learning, slowly, that the internet wasn't a nice place. Maliciously altering query string variables to affect server processing or inject SQL code started to become commonplace. Libraries that urldecoded query strings and database libraries that used prepared statements to prevent (basically eliminate) SQL injection attacks made the rounds.
While an improvement over what came before and most definitely useful, embedding markup was an absolute pain. All sorts of hacks rose up to programmatically write markup. But then a lot of people noticed at the same time that a lot of their dynamic pages were mostly static markup with only a token amount of logic. Thus the age of ASP, PHP, JSP, ColdFusion, et al. was born, and it was cool runnings for a while. If you needed a lot of logic, you wrote code with a markup generation library. If you only needed a little logic, you wrote a markup file with code markers for logic.
Things started going south when people with no programming experience started learning from those ASP, PHP, and JSP examples. They gleefully added huge tracts of code in these files, giving new life to a much maligned design pattern known as "Big Ball of Mud". Soon everyone starting getting stuck in the ever-growing balls of mud. Simplify! Encapsulate! Componentize!
We'll just add new markup. We'll call them "tag libraries" and put all the code snippets into these markup fragments. Brilliant! Now the people who don't know how to program can just write markup and coders can write stuff further up the chain.
Further adding insult to injury, PHP completely ignored the security lessons of the preceding years and allowed arbitrary variables to be set from the browser URL and completely ignored not only database abstraction facilities in the language in which it was originally written, Perl and it's DBI, but the entire concept of a prepared database statement.
JSP and its ilk were born just before this point, tag libraries and embedded Java in all their splendor, enforcing markup well-formedness and driving popular usage.
People still wrote logic in their markup though. And even the tag libraries became more and more monstrous. A tag library for databases. A tag library for data formatting. A tag library to make more tags. A tag library to perform backend workflow. A tag library to do the laundry and wash the dishes.
Meanwhile, academic gadflies coined the acronym MVC (Model-View-Controller) and starting going on about something called SoC (Separation of Concerns). Everything started going gonzo at that point.
HTML was no longer supposed to have styling info; that is now CSS's job. Our data repositories may change -- and may or may not be relational databases anymore. Hard-coding database connection strings, table names and column names is frowned upon.
URIs were also full of.asp,.php,.pl, and other extensions that didn't describe the content returned, but how the content was generated. Switching or upgrading technologies often meant creating large numbers of redirections -- commonly with the king of web voodoo, mod_rewrite -- at best, breaking links on your and other sites at worst (and more likely).
Enter the sitemap. Have the framework handle the URI space. Now your site can become technology-agnostic. As an added benefit, those framework authors also added processing pipelines where a given U
Sounds conspicuously similar to "I was coding in Prolog when I discovered BASIC."
For very simple pages, pages that amount to slightly more code than a server-side include, PHP is a perfect fit. This is obvious because PHP was originally made to be a page-embedded version of Perl -- originally written in Perl. Back in the days of CGI scripts, mostly in Perl, when you only had a little bit of code and a lot of markup, PHP (and ASP, ColdFusion, etc.) were a breath of fresh air.
However...
Embedding logic in your presentation layer is a bad idea. It ties your code to how your presenting it. Want to change how your site looks? Gotta change code. Want to change from HTML tables to CSS? Looks like it'll be a fundamental rewrite.
This is the problem that PHP -- and most mod_perl-based frameworks for that matter, like Slashdot -- have. It's a write-once language that you simply pile more and more code on until it breaks. Then you start over again.
I would have made the switch earlier, but I had the same preconceived notions that you have -- that it was a language for amatures. Before ASP, I did straight C CGIs as well as dabbling in perl and AppleScript (I'm not sure which was less up to the task at the time...I still can't stand Perl for anything more than shell scripting and never understood how it took off for the web...but some people are very capable programmers even with a crappy language).
We do not have the same preconceptions. We are coming from completely different points of view.
You: PHP is just as valid a programming environment -- if not more so -- as ASP, JSP, ColdFusion, and all the others for writing logic in web pages.
Me: Writing logic in your presentation layer (your web pages) is a bad idea no matter what language you use.
See the difference?
But since the time I moved over to PHP, my programming has gotted a LOT better. I stopped reinventing the wheel each and everytime I had a problem.
Of course you have. Usually the more you do something, the better you get at it. But I'm not suggesting that you drop PHP for something like JSP. I'm suggesting that they both suck as web development models. PHP is simply the newest kid on the block to support this crappy development model.
Everything is class oriented now instead of using pseudoclasses under ASP (dictionary objects and other hacks...and yeah, I know asp.net can deal with these, but I switched at a time that this wasn't an option nor was the lock in).
But ASP had CreateObject to instantiate any scriptable COM object registered with the system. ASP was meant to be a logic linking framework, not the logic itself. In other words, the code that did the heavy lifting was not supposed to be the Visual Basic Script; it was supposed to be your COM objects -- written in a more powerful language.
People are writing the "heavy lifting" code in PHP. This design pattern is known as "Big Ball of Mud." You may be getting better at giving it form, but it's still a ball of mud.
For once, I have the same ability to program that I did back in the C(++) days of compiled CGI apps without having to do 10x the programming (the speed was nice once, especially if the server allowed for caching the app).
So in other words, you are doing today what you did ten years ago, only faster -- neither cleaner nor more secure.
Incidentally, speeds for process invocation and forking on many platforms has increased dramatically. Those old CGI scripts in C and C++ would run faster even on the same hardware, eg. running the same code on Linux 2.0.x versus 2.6.x.
And I'm still only using PHP4...5? I haven't seen anything in 5 thats got be thinking of switching yet. All the problems you complain about are things that ANY language has...a
Isn't that like asking what type of sauce you want on your spaghetti (code)?
I have yet to see a PHP app -- especially one that also used MySQL -- that used a design pattern other than "Big Ball of Mud" most often.
Do be fair, PHP 5 looks pretty good -- or at least is a vast improvement. Unfortunately I can't say the same thing about the people who've coded in PHP up to this point. Even when PHP shows some growth, most PHP coders ignore it.
"Database abstraction? Why would anyone need that?"
"Namespaces? Why would anyone need that?"
"Design patterns? What are those?"
"Security? If it's a problem, we'll fix it later."
PHP: We'll be there for you if your development environment doesn't have enough side effects.
PHP: Because we know the money's in the maintenance contracts.
PHP: Because you obviously don't know any better.
PHP: We take security as seriously as Microsoft ten years ago.
PHP: Doing it fast is always better than doing it right.
PHP: Proving that if any idiot can write an e-commerce package, any idiot will.
PHP: Yet another great reason to make regular backups.
PHP: Fast, cheap, and robust. Two out of three ain't bad, right?
Likely it's because when the other end does a reverse DNS record lookup, and your hostname and the PTR record don't match up. Usually this ends up resulting in receiving fine but problems sending.
Try setting up your ISP's SMTP server as your outgoing mail relay. In other words, when you send mail to your SMTP server, instead of looking up the remote host, doing an MX record lookup, etc., just send to your ISP's SMTP server. They should be configured to accept anything from your IP (you are their customer after all), and it only requires one extra hop for your email on the way out the door.
Instead of:
Email client -> Your SMTP -> MX record lookup -> Destination
it becomes
Email client -> Your SMTP -> ISP SMTP -> MX record lookup -> Destination
After doing this, from your point of view, nothing will have changed, and you can learn to sysadmin on a small scale to your heart's content.
A lot easier than getting an ISP to change the PTR record to your hostname.
The exposure of this older bug in new software is perhaps a good jumping off point for an argument about constructing new browser technologies from scratch, rather than simply developing existing (by the laws of probability, flawed) software to incorporate extended functionality; which is by far the industry norm as it stands. Is this a viable alternative?
Anyone that knows the history of the Mozilla project has to see the idiocy in this statement.
Or are they supposed to scrap it all and rewrite from scratch every few years? I sure hope not. Anyone else out remember M13, M14, M15, etc.? *shudder*
...for all of the "Open Source doesn't innovate" folks out there.
Why are solutions that enhance security, reliability, and performance not considered innovation?
What closed source OS implemented O(1) algorithms in just about every major subsystem including the scheduler before Linux (and I think FreeBSD)?
Why is it that when Microsoft makes security nightmares like ActiveX, it's called innovation? Why is it that when Open Source comes up with web server software that is built from the ground up to never fall over, it's just "copying" or "uninteresting?"
Why can't OpenSSH and pf's security enhancements over the years be considered innovative?
-----
Not to mention things like XUL in Mozilla/Firefox. Here's an instance where a group of developers collectively decided, "Since we're rendering GUIs anyway, why not have the browser render the enclosing widgets as well?" Most people moaned that it was a bad idea -- just check the Slashdot archives from five years ago. Now look at Microsoft's XAML and Apple Tiger's desktop widgets. Who's following who?
How about PostgreSQL? In what other database can end users write a little bit of code (and I stress "little") and create entirely new datatypes?
Check out Apache Cocoon and its document processing pipelines. While you're at it, check out its Flow engine with which continuations have revolutionized server-side web development.
-----
Another post stated that Open Source only implemented what academia invented. While only partially true, I don't see the problem. All good software has a design step from Oracle database engines to Microsoft word processors. Are people actually saying that referencing the most innovative and inventive designs is somehow a bad idea? Some projects in universities for all intents and purposes mathematically prove that a particular solution is the most efficient. It's not cheating or unworthy. It's just common sense to use these designs.
Drug resistant strains could also be produced from a population of bacteria which had the capability of resistance latent within it. Those strains that are killed off more quickly have less of a chance to continue their line, and those that survive by virtue of already having greater latent resistance, end up appearing as a "new strain" of drug resistant bacteria.
Almost right. This seems to be one of the hardest concepts for some people to grasp. You are absolutely, positively, 100% correct that the resistance was already in the population of bacteria (and bees) before the limiting factor was introduced. That's the good news.
The bad news is that a month ago, that resistance may not have existed.
Random mutation does not happen with a purpose. No strain of bacteria "tries" to be immune to antibiotics. No bees "try" to be immune to the effects or Varroa mites. That's not how it works and is generally the hardest thing for most people to get. You are trying to substitute the will of God for the collective will of bacteria and the model fails.
It actually goes something like this:
* Copy errors during reproduction/replication give rise to what we call mutation.
* That random mutation is not sought out. It's remarkably similar to the game of Telephone where the message that comes out is not the message that went in. All participants in the game can try to reproduce the input exactly, but inevitably, variation occurs. The DNA of bacteria tries to copy exactly, but inevitably, variation occurs. (Random mutation occurs precisely because we live in an imperfect world.)
* Those copy errors can occur for just about any reason: too much sunlight, too little sunlight, exposure to certain chemicals, isolation from certain chemicals, etc.
* Those variations can have a good effect (aid survival), a bad effect (kill the organism or hinder survival), or no effect at all. On the other hand, a mutation that has no effect at all at first -- or even a slightly bad effect at first -- may somewhere down the line provide benefits or drawbacks like drug resistance for example.
So in summary, yes, the trait was already there. However, the trait was not always there. Big difference! We only know the trait was there some time before exposure to the antibiotics.
For more info on this, check out the early genetic study of fruit flies. Random mutation is clearly documented in these early experiments and repeated ad nauseum by others.
Regarding radioactive decay, while the decay rate remains constant, the unknown is the original ratio of isotopes (e.g., C-14 to C-12) that are used for measurement. What is assumed is that the ratio has remained the same throughout history, but this is clearly an assumption we cannot prove one way or the other. There are multiple possibilities as to how the original ratio could have been different.
Once again, absolutely right. This is why scientists use more than one radiometric dating method at a time. While it is, for example, possible for two different dating methods to be wrong, it is highly unlikely that both will be wrong at precisely the same rate. If you use three or four different isotopic decay models for dating, the possibility that all of them are wrong in exactly the same amount becomes infinitesimal. Add in that others will repeat the results in their own labs and get the same results lends itself to the conclusion that the dates are indeed valid.
Remember, this is not just about C14 decay. This is about the myriad different isotopes used....and the fact that they come up with the same answer given the relative half-lifes.
Exactly. Millions of dead things, buried in rock layers, laid down by water, all over the earth. Maybe there really was a worldwide flood.
Yes, technically he's correct. Natural selection is indeed an eliminator. However he fails to acknowledge random mutation. Random mutation adds diversity so you end up with more variations than you start with. Random mutation can be observed easily in drug-resistant bacteria. The ubiquitous undergraduate biology example of fruit fly genetics also comes to mind.
Regarding radiometric dating:
If you shake the hourglass, twirl it, or put it in a rapidly accelerating vehicle, the time it takes the sand to fall will change. But the radioactive atoms used in dating techniques have been subjected to heat, cold, pressure, vacuum, acceleration, and strong chemical reactions to the extent that would be experienced by rocks or magma in the mantle, crust, or surface of the Earth or other planets without any significant change in their decay rate.
and
The uncertainties on the half-lives given in the table are all very small. All of the half-lives are known to better than about two percent except for rhenium (5%), lutetium (3%), and beryllium (3%). There is no evidence of any of the half-lives changing over time. In fact, as discussed below, they have been observed to not change at all over hundreds of thousands of years.
The latter is the kicker. All radioactive decay follows the exact same decay curve with only a change in period (length of time). The proposition that this curve alters substantially after say a hundred thousand years is the equivalent to the proposition that the same physics that has sent probes to other planets and unleashed the destructive force of a split atom is fundamentally wrong. Not "I missed a question or two and got a B+" wrong. I mean it would be "I got a D because it was multiple choice and I got lucky" wrong.
Regarding life on Earth:
Just how "recent" are you talking? If you mean "less than 10,000 years," you are sadly mistaken. We've found structures made by humanoids that are at least 500,000 years old.
There are aquatic fossils found on top of Mount Everest. Unless you also discount plate tectonics wholesale and/or expect that Mount Everest was the product of a few millenia of uplifting, why would aquatic creatures be found there?
The only reason to believe that life has not existed on the planet for over a billion years is because it conflicts with the Bible. It is not because the evidence is lacking.
Life from non-life is what's known as abiogenesis. Creationists and ID proponents often bring up the early Miller experiments as proof that abiogenesis cannot happen.
I highly recommend reading up on the recent work of Dr. Sidney Fox. The short version is that not only can life be created from non-living chemicals, it can consistently be done and result in near ideal conditions for the development of RNA (and later, DNA).
Well... very compelling if you haven't taken any college-level science classes. His statements about natural selection are curious. His assertions about radiometric dating are hilarious.
To see how messed up amazingdiscoveries.org actually is, read the comments about dating, and then read Dr. Roger Weins's Radiometric Dating: A Christian Perspective. The "revelations" on amazingdiscoveries.org made me laugh out loud.
If traits are not inherited, evolution cannot occur
2. Mutation
If no trait of children can differ from both parents, evolution cannot occur
3. Random mutation
If changes cannot occur without clear design or intention, evolution cannot occur
4. Speciation
If two isolated groups cannot become distinct from one another (no more interbreeding even if brought back together geographically), evolution cannot occur
-----
*ALL* of the above have been tested, observed, documented, reproduced, etc. If by "proof" you mean that we haven't yet built time machines, then yes, evolution is not proved. By all other measurements, even though scientists haggle about the details, evolution is an accepted fact.
For fun, run a Google search on Lysenkoism. It's evolution in action; repeated, published, and proved.
Evolution by natural selection of individuals differentiated by random mutation happens. It has been observed. Every time you buy produce at the grocery store, you have your evidence.
Google "Lysenkoism" for more information.
We may not know every minute detail, but you would be hard-pressed to convince me that evolution through the process of natural selection is merely plausible.
That said, people are mischaracterizing Intelligent Design. Many ID adherents accept evolution but only on the micro-level (changes within a species). Most of the arguments fall along the "irreducible complexity" line of thought.
That said...
ID is still bullshit. To anyone who likes ID, I hate to break it to you, but the eye is not irreducibly complex. A bacteria's flaggellum is not irreducibly complex.
In other news, infants are occasionally born with tails (vestigial traits).
And of course the best way to identify a dogmatic idiot: If the individual brings up the Big Bang or abiogenesis, they don't understand what evolution is. The best part is when the bring up the old Miller experiments of life from non-living chemicals (abiogenesis). Yes, that experiment was fatally flawed. However, they consistently fail to mention Dr. Sidney Fox and his much more recent experiments.
What you're describing is not a data format. You are describing a prepended index. Very different animals.
Nevermind that binary formats are soooooooo easy to algorithmically validate for correctness. Oh, look! A valid pointer! I sure hope it points to something useful... Oops! Unexpected NULL value. Better fix that... Okay! Now it works!
user: could you add this feature?
Hmmm... Gotta add it to the data structure... Okay, I've got to make sure the client and server protocols match by version. Damn. Gotta rework that validation code because my offsets have changed. (Etc. etc. etc.)
Pop quiz: what is the binary representation of the string "my pretty little lamb"? How does it differ from the "text" representation of the same? How do you mark hierarchy? Do those markers use up less space than the one-byte '<' character? How do you allow for optional values as well as allow for modification and future expandability with a binary format? How much more efficient is binary parsing with validity checks for structure and data correctness when compared with text (XML) parsing?
And finally, for fifty points, how expensive is your time as a developer as compared to hardware processing time as a dollar value?
If your time writing, parsing, validating and debugging a binary format is cheaper over the course of a year than the same amount of money used to purchase server hardware, then you have made the right choice with a binary format.
Oh! And don't forget to comment your code and document your binary format. Those really suck for future code maintainers to reverse engineer.
Researchers at the University of Toronto have invented an infrared-sensitive material that's five times more efficient at turning the sun's power into electrical energy than current methods.
Assuming you don't count the cells that produce more than 6% effeciency (of which there are a few) nor lab samples from Berkeley and a couple other places that are pushing the 50% mark -- albeit with short lifespans.
It also contains a huge untapped resource -- despite the surge in popularity of solar cells in the 1990s, we still miss half of the sun's power, Sargent said.
Although we are doing better with efficiency than we were doing in the 80s and early 90s.
"In fact, there's enough power from the sun hitting the Earth every day to supply all the world's needs for energy 10,000 times over,'' Sargent said in a phone interview Sunday from Boston. He is currently a visiting professor of nanotechnology at the Massachusetts Institute of Technology.
Yes! Ummm... As long as you are willing to completely cover the Earth's surface with solar cell, this is true. If you take the sunlight for electricity generation, you lose it for other purposes: plant growth, heat, vitamin-D production, natural light, etc. I hate statements like these. They imply that the only reason we can't move to a completely solar economy is lack of investment, when there are larger issues at work.
The points about clothing and paint were very cool though.
The film can convert up to 30 per cent of the sun's power into usable, electrical energy. Today's best plastic solar cells capture only about six per cent.
I'd like to see the source of stats like this. Is this because the newer ones can capture such a wide band as infrared so that the percentages are being adjusted?
Sargent said the advance would not only wipe away that inefficiency, but also resolve the hassle of recharging our countless gadgets and pave the way to a true wireless world.
Not truly wireless; you'll still need a cable from your photovoltaic clothing to your cell phone/PDA.
"We now have our cellphones and our BlackBerries and we're walking around without the need to plug in, in order to get our data,'' he said.
These things don't have sufficient surface area to be recharged by having their outer skins be photovoltaic. In addition, many people carry them in their pockets or purses rather than on an external belt clip. Therefore you need an external power source (such as your clothing). This means the phone needs to be plugged into your clothing somehow. Not THAT big a deal, but one worth mentioning.
The film has the ability to be sprayed or woven into shirts so that our cuffs or collars could recharge our IPods, Sargent said.
How well does it handle being washed in standard washing machines? Dry cleaning everything would be a major pain in the ass. (Assuming that the chemicals used in dry cleaning don't degrade the photovoltaics since the cleaning agents were not made with "quantum dots" in mind.)
I don't mean to be a naysayer, but the article is extremely vague and doesn't give a link to more information (if it's even available). I'd rather be skeptical now and see how it can be used rather than proudly (and prematurely) announce that this solves all our problems and cooks dinner to boot.
It is ironic that Linux is going to the monolithic kernel model from the safer microkernel-based model. Modularity and 30 years of OS research be damned.
Just because people have found that a hammer is the most generalized tool does not make the world full of nails.
Slashdot Mirror
Fair enough. :)
Or would that be the 99.5% of PHP apps that have constant SQL and variable injection attacks. *cough* PHP XML_RPC support *cough*
In the beginning, you had files and web servers. Then people starting writing extensions to the web servers and the dynamic web was born.
.asp, .php, .pl, and other extensions that didn't describe the content returned, but how the content was generated. Switching or upgrading technologies often meant creating large numbers of redirections -- commonly with the king of web voodoo, mod_rewrite -- at best, breaking links on your and other sites at worst (and more likely).
But the problems with patching your web server for even the slightest dynamism were immediately obvious even in the early days of "a patchy server". So CGI (Common Gateway Interface) was born and Perl rose up as the dominant web language. Process creation overhead became an issue as the web took off so techniques for mitigating this were put in like mod_perl, servlets, etc., but overall the process stayed the same.
People started learning, slowly, that the internet wasn't a nice place. Maliciously altering query string variables to affect server processing or inject SQL code started to become commonplace. Libraries that urldecoded query strings and database libraries that used prepared statements to prevent (basically eliminate) SQL injection attacks made the rounds.
While an improvement over what came before and most definitely useful, embedding markup was an absolute pain. All sorts of hacks rose up to programmatically write markup. But then a lot of people noticed at the same time that a lot of their dynamic pages were mostly static markup with only a token amount of logic. Thus the age of ASP, PHP, JSP, ColdFusion, et al. was born, and it was cool runnings for a while. If you needed a lot of logic, you wrote code with a markup generation library. If you only needed a little logic, you wrote a markup file with code markers for logic.
Things started going south when people with no programming experience started learning from those ASP, PHP, and JSP examples. They gleefully added huge tracts of code in these files, giving new life to a much maligned design pattern known as "Big Ball of Mud". Soon everyone starting getting stuck in the ever-growing balls of mud. Simplify! Encapsulate! Componentize!
We'll just add new markup. We'll call them "tag libraries" and put all the code snippets into these markup fragments. Brilliant! Now the people who don't know how to program can just write markup and coders can write stuff further up the chain.
Further adding insult to injury, PHP completely ignored the security lessons of the preceding years and allowed arbitrary variables to be set from the browser URL and completely ignored not only database abstraction facilities in the language in which it was originally written, Perl and it's DBI, but the entire concept of a prepared database statement.
JSP and its ilk were born just before this point, tag libraries and embedded Java in all their splendor, enforcing markup well-formedness and driving popular usage.
People still wrote logic in their markup though. And even the tag libraries became more and more monstrous. A tag library for databases. A tag library for data formatting. A tag library to make more tags. A tag library to perform backend workflow. A tag library to do the laundry and wash the dishes.
Meanwhile, academic gadflies coined the acronym MVC (Model-View-Controller) and starting going on about something called SoC (Separation of Concerns). Everything started going gonzo at that point.
HTML was no longer supposed to have styling info; that is now CSS's job. Our data repositories may change -- and may or may not be relational databases anymore. Hard-coding database connection strings, table names and column names is frowned upon.
URIs were also full of
Enter the sitemap. Have the framework handle the URI space. Now your site can become technology-agnostic. As an added benefit, those framework authors also added processing pipelines where a given U
Sounds conspicuously similar to "I was coding in Prolog when I discovered BASIC."
For very simple pages, pages that amount to slightly more code than a server-side include, PHP is a perfect fit. This is obvious because PHP was originally made to be a page-embedded version of Perl -- originally written in Perl. Back in the days of CGI scripts, mostly in Perl, when you only had a little bit of code and a lot of markup, PHP (and ASP, ColdFusion, etc.) were a breath of fresh air.
However...
Embedding logic in your presentation layer is a bad idea. It ties your code to how your presenting it. Want to change how your site looks? Gotta change code. Want to change from HTML tables to CSS? Looks like it'll be a fundamental rewrite.
This is the problem that PHP -- and most mod_perl-based frameworks for that matter, like Slashdot -- have. It's a write-once language that you simply pile more and more code on until it breaks. Then you start over again.
We do not have the same preconceptions. We are coming from completely different points of view.
You: PHP is just as valid a programming environment -- if not more so -- as ASP, JSP, ColdFusion, and all the others for writing logic in web pages.
Me: Writing logic in your presentation layer (your web pages) is a bad idea no matter what language you use.
See the difference?
Of course you have. Usually the more you do something, the better you get at it. But I'm not suggesting that you drop PHP for something like JSP. I'm suggesting that they both suck as web development models. PHP is simply the newest kid on the block to support this crappy development model.
But ASP had CreateObject to instantiate any scriptable COM object registered with the system. ASP was meant to be a logic linking framework, not the logic itself. In other words, the code that did the heavy lifting was not supposed to be the Visual Basic Script; it was supposed to be your COM objects -- written in a more powerful language.
People are writing the "heavy lifting" code in PHP. This design pattern is known as "Big Ball of Mud." You may be getting better at giving it form, but it's still a ball of mud.
So in other words, you are doing today what you did ten years ago, only faster -- neither cleaner nor more secure.
Incidentally, speeds for process invocation and forking on many platforms has increased dramatically. Those old CGI scripts in C and C++ would run faster even on the same hardware, eg. running the same code on Linux 2.0.x versus 2.6.x.
Isn't that like asking what type of sauce you want on your spaghetti (code)?
I have yet to see a PHP app -- especially one that also used MySQL -- that used a design pattern other than "Big Ball of Mud" most often.
Do be fair, PHP 5 looks pretty good -- or at least is a vast improvement. Unfortunately I can't say the same thing about the people who've coded in PHP up to this point. Even when PHP shows some growth, most PHP coders ignore it.
"Database abstraction? Why would anyone need that?"
"Namespaces? Why would anyone need that?"
"Design patterns? What are those?"
"Security? If it's a problem, we'll fix it later."
PHP: We'll be there for you if your development environment doesn't have enough side effects.
PHP: Because we know the money's in the maintenance contracts.
PHP: Because you obviously don't know any better.
PHP: We take security as seriously as Microsoft ten years ago.
PHP: Doing it fast is always better than doing it right.
PHP: Proving that if any idiot can write an e-commerce package, any idiot will.
PHP: Yet another great reason to make regular backups.
PHP: Fast, cheap, and robust. Two out of three ain't bad, right?
-----
I'm liking this meme. Anyone got any more?
Likely it's because when the other end does a reverse DNS record lookup, and your hostname and the PTR record don't match up. Usually this ends up resulting in receiving fine but problems sending.
Try setting up your ISP's SMTP server as your outgoing mail relay. In other words, when you send mail to your SMTP server, instead of looking up the remote host, doing an MX record lookup, etc., just send to your ISP's SMTP server. They should be configured to accept anything from your IP (you are their customer after all), and it only requires one extra hop for your email on the way out the door.
Instead of:
Email client -> Your SMTP -> MX record lookup -> Destination
it becomes
Email client -> Your SMTP -> ISP SMTP -> MX record lookup -> Destination
After doing this, from your point of view, nothing will have changed, and you can learn to sysadmin on a small scale to your heart's content.
A lot easier than getting an ISP to change the PTR record to your hostname.
XML is only text like this:
Oh wait! No! That's not XML; that's the existing config file format. I guess XML wouldn't be that big of a change.
Kinda makes you think.
Hmmmm... Nevermind. This is Slashdot. Most people don't actually think.
Or are they supposed to scrap it all and rewrite from scratch every few years? I sure hope not. Anyone else out remember M13, M14, M15, etc.? *shudder*
Because most of the 'based on C' teams are still stuck in the debugger.
...for all of the "Open Source doesn't innovate" folks out there.
Why are solutions that enhance security, reliability, and performance not considered innovation?
What closed source OS implemented O(1) algorithms in just about every major subsystem including the scheduler before Linux (and I think FreeBSD)?
Why is it that when Microsoft makes security nightmares like ActiveX, it's called innovation? Why is it that when Open Source comes up with web server software that is built from the ground up to never fall over, it's just "copying" or "uninteresting?"
Why can't OpenSSH and pf's security enhancements over the years be considered innovative?
-----
Not to mention things like XUL in Mozilla/Firefox. Here's an instance where a group of developers collectively decided, "Since we're rendering GUIs anyway, why not have the browser render the enclosing widgets as well?" Most people moaned that it was a bad idea -- just check the Slashdot archives from five years ago. Now look at Microsoft's XAML and Apple Tiger's desktop widgets. Who's following who?
How about PostgreSQL? In what other database can end users write a little bit of code (and I stress "little") and create entirely new datatypes?
Check out Apache Cocoon and its document processing pipelines. While you're at it, check out its Flow engine with which continuations have revolutionized server-side web development.
-----
Another post stated that Open Source only implemented what academia invented. While only partially true, I don't see the problem. All good software has a design step from Oracle database engines to Microsoft word processors. Are people actually saying that referencing the most innovative and inventive designs is somehow a bad idea? Some projects in universities for all intents and purposes mathematically prove that a particular solution is the most efficient. It's not cheating or unworthy. It's just common sense to use these designs.
A direct rebuttal to your trueorigins.org link.
Almost right. This seems to be one of the hardest concepts for some people to grasp. You are absolutely, positively, 100% correct that the resistance was already in the population of bacteria (and bees) before the limiting factor was introduced. That's the good news.
The bad news is that a month ago, that resistance may not have existed.
Random mutation does not happen with a purpose. No strain of bacteria "tries" to be immune to antibiotics. No bees "try" to be immune to the effects or Varroa mites. That's not how it works and is generally the hardest thing for most people to get. You are trying to substitute the will of God for the collective will of bacteria and the model fails.
It actually goes something like this:
* Copy errors during reproduction/replication give rise to what we call mutation.
* That random mutation is not sought out. It's remarkably similar to the game of Telephone where the message that comes out is not the message that went in. All participants in the game can try to reproduce the input exactly, but inevitably, variation occurs. The DNA of bacteria tries to copy exactly, but inevitably, variation occurs. (Random mutation occurs precisely because we live in an imperfect world.)
* Those copy errors can occur for just about any reason: too much sunlight, too little sunlight, exposure to certain chemicals, isolation from certain chemicals, etc.
* Those variations can have a good effect (aid survival), a bad effect (kill the organism or hinder survival), or no effect at all. On the other hand, a mutation that has no effect at all at first -- or even a slightly bad effect at first -- may somewhere down the line provide benefits or drawbacks like drug resistance for example.
So in summary, yes, the trait was already there. However, the trait was not always there. Big difference! We only know the trait was there some time before exposure to the antibiotics.
For more info on this, check out the early genetic study of fruit flies. Random mutation is clearly documented in these early experiments and repeated ad nauseum by others.
Once again, absolutely right. This is why scientists use more than one radiometric dating method at a time. While it is, for example, possible for two different dating methods to be wrong, it is highly unlikely that both will be wrong at precisely the same rate. If you use three or four different isotopic decay models for dating, the possibility that all of them are wrong in exactly the same amount becomes infinitesimal. Add in that others will repeat the results in their own labs and get the same results lends itself to the conclusion that the dates are indeed valid.
Remember, this is not just about C14 decay. This is about the myriad different isotopes used.
Aaaargh! I have been trolled.
Yes, technically he's correct. Natural selection is indeed an eliminator. However he fails to acknowledge random mutation. Random mutation adds diversity so you end up with more variations than you start with. Random mutation can be observed easily in drug-resistant bacteria. The ubiquitous undergraduate biology example of fruit fly genetics also comes to mind.
Regarding radiometric dating:
and
The latter is the kicker. All radioactive decay follows the exact same decay curve with only a change in period (length of time). The proposition that this curve alters substantially after say a hundred thousand years is the equivalent to the proposition that the same physics that has sent probes to other planets and unleashed the destructive force of a split atom is fundamentally wrong. Not "I missed a question or two and got a B+" wrong. I mean it would be "I got a D because it was multiple choice and I got lucky" wrong.
Regarding life on Earth:
Just how "recent" are you talking? If you mean "less than 10,000 years," you are sadly mistaken. We've found structures made by humanoids that are at least 500,000 years old.
There are aquatic fossils found on top of Mount Everest. Unless you also discount plate tectonics wholesale and/or expect that Mount Everest was the product of a few millenia of uplifting, why would aquatic creatures be found there?
The only reason to believe that life has not existed on the planet for over a billion years is because it conflicts with the Bible. It is not because the evidence is lacking.
Life from non-life is what's known as abiogenesis. Creationists and ID proponents often bring up the early Miller experiments as proof that abiogenesis cannot happen.
I highly recommend reading up on the recent work of Dr. Sidney Fox. The short version is that not only can life be created from non-living chemicals, it can consistently be done and result in near ideal conditions for the development of RNA (and later, DNA).
Google Fox and abiogenesis for more info.
Very compelling.
Well... very compelling if you haven't taken any college-level science classes. His statements about natural selection are curious. His assertions about radiometric dating are hilarious.
To see how messed up amazingdiscoveries.org actually is, read the comments about dating, and then read Dr. Roger Weins's Radiometric Dating: A Christian Perspective. The "revelations" on amazingdiscoveries.org made me laugh out loud.
How to prove or falsify the theory of evolution:
1. Genetics
If traits are not inherited, evolution cannot occur
2. Mutation
If no trait of children can differ from both parents, evolution cannot occur
3. Random mutation
If changes cannot occur without clear design or intention, evolution cannot occur
4. Speciation
If two isolated groups cannot become distinct from one another (no more interbreeding even if brought back together geographically), evolution cannot occur
-----
*ALL* of the above have been tested, observed, documented, reproduced, etc. If by "proof" you mean that we haven't yet built time machines, then yes, evolution is not proved. By all other measurements, even though scientists haggle about the details, evolution is an accepted fact.
For fun, run a Google search on Lysenkoism. It's evolution in action; repeated, published, and proved.
Evolution by natural selection of individuals differentiated by random mutation happens. It has been observed. Every time you buy produce at the grocery store, you have your evidence.
Google "Lysenkoism" for more information.
We may not know every minute detail, but you would be hard-pressed to convince me that evolution through the process of natural selection is merely plausible.
That said, people are mischaracterizing Intelligent Design. Many ID adherents accept evolution but only on the micro-level (changes within a species). Most of the arguments fall along the "irreducible complexity" line of thought.
That said...
ID is still bullshit. To anyone who likes ID, I hate to break it to you, but the eye is not irreducibly complex. A bacteria's flaggellum is not irreducibly complex.
In other news, infants are occasionally born with tails (vestigial traits).
And of course the best way to identify a dogmatic idiot: If the individual brings up the Big Bang or abiogenesis, they don't understand what evolution is. The best part is when the bring up the old Miller experiments of life from non-living chemicals (abiogenesis). Yes, that experiment was fatally flawed. However, they consistently fail to mention Dr. Sidney Fox and his much more recent experiments.
Umm... actually... yes.
Do a Google search for the term "Lysenkoism". You will see a real-world, tested, recent example of evolutionary biology in action.
As an added bonus, you will see what happens when a group dismisses the evidence for the sake of dogma.
I first heard it among the women of Caltech. And for the record, that was before 1996. ;-)
The odds are good, but the goods are odd.
What you're describing is not a data format. You are describing a prepended index. Very different animals.
:)
Nevermind that binary formats are soooooooo easy to algorithmically validate for correctness. Oh, look! A valid pointer! I sure hope it points to something useful... Oops! Unexpected NULL value. Better fix that... Okay! Now it works!
user: could you add this feature?
Hmmm... Gotta add it to the data structure... Okay, I've got to make sure the client and server protocols match by version. Damn. Gotta rework that validation code because my offsets have changed. (Etc. etc. etc.)
Pop quiz: what is the binary representation of the string "my pretty little lamb"? How does it differ from the "text" representation of the same? How do you mark hierarchy? Do those markers use up less space than the one-byte '<' character? How do you allow for optional values as well as allow for modification and future expandability with a binary format? How much more efficient is binary parsing with validity checks for structure and data correctness when compared with text (XML) parsing?
And finally, for fifty points, how expensive is your time as a developer as compared to hardware processing time as a dollar value?
If your time writing, parsing, validating and debugging a binary format is cheaper over the course of a year than the same amount of money used to purchase server hardware, then you have made the right choice with a binary format.
Oh! And don't forget to comment your code and document your binary format. Those really suck for future code maintainers to reverse engineer.
Have a nice day!
Absolutely right! Time to dump HTTP, FTP, SMTP, SNMP, NTP, NNTP, POP3, IMAP4, etc. Text-based stuff sucks! Why haven't we learned that yet?
Now, those binary MS Word 6.0 documents and Exchange Server extensions are another story. Elegance at its finest!
Although we are doing better with efficiency than we were doing in the 80s and early 90s.
Yes! Ummm... As long as you are willing to completely cover the Earth's surface with solar cell, this is true. If you take the sunlight for electricity generation, you lose it for other purposes: plant growth, heat, vitamin-D production, natural light, etc. I hate statements like these. They imply that the only reason we can't move to a completely solar economy is lack of investment, when there are larger issues at work.
The points about clothing and paint were very cool though.
I'd like to see the source of stats like this. Is this because the newer ones can capture such a wide band as infrared so that the percentages are being adjusted?
Not truly wireless; you'll still need a cable from your photovoltaic clothing to your cell phone/PDA.
These things don't have sufficient surface area to be recharged by having their outer skins be photovoltaic. In addition, many people carry them in their pockets or purses rather than on an external belt clip. Therefore you need an external power source (such as your clothing). This means the phone needs to be plugged into your clothing somehow. Not THAT big a deal, but one worth mentioning.
How well does it handle being washed in standard washing machines? Dry cleaning everything would be a major pain in the ass. (Assuming that the chemicals used in dry cleaning don't degrade the photovoltaics since the cleaning agents were not made with "quantum dots" in mind.)
I don't mean to be a naysayer, but the article is extremely vague and doesn't give a link to more information (if it's even available). I'd rather be skeptical now and see how it can be used rather than proudly (and prematurely) announce that this solves all our problems and cooks dinner to boot.
It is ironic that Linux is going to the monolithic kernel model from the safer microkernel-based model. Modularity and 30 years of OS research be damned.
Just because people have found that a hammer is the most generalized tool does not make the world full of nails.
Getting there with v5. Been there for years in most other RDBMSs. Why wait for tomorrow when you could have had it yesterday?