When MySQL thought February 31 was a date, Postgres thought data was something you chewed up and swallowed, and if you were lucky, it might come out the other end as a pile of shit, after rebooting because it locked up the whole machine.
writing an validate_date() function before submitting a query was alot easier than starting over from scratch with a fully ACID compliant database that was most reliable when it wouldn't accept any connections because it had exhausted all system resources, because once you got your data in, you couldn't count on it coming out right.
That's why Postgres doesn't have the uptake, because it has a bad reputation. And while they may have beaten most of the bugs into submission, too many people remember getting burned and don't want to wait for the next subtle catastropic glitch.
Something that starts simple and works right from the start, adding features slowly is better than something complex that aims for "correctness" but works wrong until the bugs are fixed.
Re:Web hosts should be offering more choice
on
PHP 6 and What to Expect
·
· Score: 2, Interesting
actually, there is a very good reason to not use python for HTML template scripting, and anyone who's used JSP knows why, despite what the python users say about "using a proper text editor"
[PHP's design is fucked up. Some functions have underscores, others don't; some have numbers, others don't]
This is the sum of your critique of the language!?! You don't like the name of some of the functions that are included with it?!?
For $5 I'll sell you a patched PHP, just give me your list of preferred functions, and you can have (apparently) the perfectly designed language.
I say Perl's design is fucked up. The different sigils are on different parts of the keyboard. @ isn't next to % and by god, $ comes after @ on the keyboard. If only @ meant scalar, # meant array, and $ meant hash, then it'd be the perfect language design. Only Perl 6 (if it ever gets written) really does fuck up sigils because @foo[$i] doesn't mean anything.
Yes. About the only use for Unicode is keeping track of your Elvish and Klingon dipthongs in the same character set. 2 byte words is enough for China and Japan has their own system that works. Meanwhile, everyone uses ascii except when representing pictograph characters.
I want to split my time between Montana and Fiji, but since I need to work, and I know IT, I'm living in Seattle. It's a choice really.
If you are a recent college graduate with a degree computer science and you live 45 miles out of Little Rock and are unwilling to move, either write some chicken farm management software and sell it yourself, or expect long drives to infrequent job interviews. Of course, If you live in Cupertino and aren't any good, you probably won't recruiters from Google breathing down your neck.
Maybe it's just me, but the IT job market seems hotter now than it was in 2000.
Lets say you've got some software (say a J2EE Server or database) that costs $10,000 or more per instance and you need 40 instances. Or one big fat honking virtual instance. All the sudden you save money. Except that many big iron apps get around this by charging per CPU, exactly because people were throwing big iron at the problem before. Then small machines started getting faster than big Iron, say a dual Xeon outperforming a 16 way SPARC, and then the licensing model fell apart, and some companies relaxed their per CPU rules.
But creating hydrogen fuel through electrolysis and then burning the hydrogen and converting it to energy is much *less* efficient than using the energy that would have been used to perform elecrolysis directly.
Two points.
1) If you find a more efficient way to generate usable hydrogen fuel.
2) If you use energy from a non-portable power source (such as coal or nuclear generators) to process the hydrogen.
But even with these, you still have the issue that gasoline is more portable and stable than hydrogen fuel.
One more point.
If you could convert the hydrogen to fuel cells effeciently.
But you would then again lose energy in the inefficent transferance.
I think maybe that "bureaucracy forging ahead" might have had something to do with the manager fearing for his life under a brutal dictatorship that demanded results. Whether he was incompedent or not was irrelevant, since the structure of the government meant he got his position through nepotism, and would have been replaced, compedent or not if he'd disobeyed.
It was malicious flaw inherent in the system, a not a mistake.
If the Germans had gone west into Britain, the Russians would damn sure have attacked them. Unless you forgot, Stalin signed that non-agression pact too, not just Ribbentrop. That means that Russia had something to get out of it, and they didn't need the paperwork to take half of Poland. They got that very nicely on their own, militarily. Stalin wanted to build up his forces and wait for Germany to be entangled with the west before he struck, so Hitler *had* to beat him to the punch. If you thought Stalingrad was ugly, you wouldn't believe what the battle of Britain would have been. At the very least, Stalingrad plus D-Day, plus the Battle of Britain, plus an unlikely capability of supressing the popular insurgency, an all out American attack (we'd've retreated to the 48 in the Pacific and concentrated on eliminating Germany.
Funny how all the top-secret technological advances by the Americans, Germans, Russians, Japanese, and Lichtensteinians all saw the light of day eventually, but somehow British technology was so secret that all traces of it have disappeared. Maybe it's because the British were so much smarter than the rest of us that that's why they were able to keep it secret. Or maybe it's just a silly myth designed to stroke the ego of a declining empire.
that's a guaranteed way to get cracked. It wouldn't take more than a cursory glance (or at best a bit of statistical analysis) to tell the difference between the gibberish and the cyphered text. A really bad crypto would improve itself with a moderate amount of gibberish (say 50-75%) so that if partially broken, it would resist guessing. But unless your crypto is being broken by hand already, or if it is entirely uncrackabl, interleaving gibberish with cyphertext is a sure way to weaken your encryption.
The only thing blogging tools have brought to the masses is FTP. That's right. A blogging tool is either a textarea or a word processor with either a HTTP POST or a FTP PUT command.
If you couldn't wrap your sentences in
and space your paragraphse with
, then you probably couldn't handle punctuation or capitalization either.
OO People are going to hate this, but the trick to resusability is to create procedural code. Treat data as God intended it to be used -- as input and output.
If your code relies on specific objects & data structures, it will be less re-usable. Objects are domain specific. A 'car' object in a racing game is different from a 'car' in a mechanic's billing application, even if they both have a car type of 'Ferarri'. That's where alot of cruft in OOP comes in, tying data to closely to behavior.
Object Oriented programming isn't meant to increase reusability, it is for reducing complexity.
That's idiotic. Civilizations can't "collapse" at the bottom of their power. Stocks go down when they reach their highest selling point. Mountain climber have to turn back at the summit. Stairs only go down from the top floor.
If we just kill off all the hypocrites demanding that the rest of us change our corpulent waste of resources(so that they can learn from our example, I'm sure), then those answers would be 'quite a while longer' and 'plenty long'.
The best way to conserve oil is to reduce the population. The next best way is to drill for more. Every new well saves hundreds of idiots from the slaughter.
No we should drill for more oil to exceed our current shallow lifestyles, thereby allowing us to attain more meaning in our lives thanks to the additional energy obtained.
Postgres just isn't in the same category as MySQL. It isn't stable.
Flames aside, Postgres developers are just as susceptable to big paychecks as anyone else. The difference is that they don't have a valuable trademark or a reputation worth buying. And that they're not even on Oracle's radar as a competitor. Maybe next year they will be. And maybe they can all retire to islands when they get bought out. Or maybe they'll all take rewarding jobs at Oracle integrating Postgres with Peoplesoft & Siebel. Or maybe they'll choose to keep working on it.
But MySQL and they're current customers aren't threatened. In fact, they're guaranteed safety. The question is whether the BDB and InnoDB developers are still motivated enough to keep developing newer and better code when they could surfing privateislandsonline.com with intent.
Slashdot Mirror
"garbage in-garbage out" is a pretty good rule of thumb. If you enter a bogus date into your database, expect a bogus date to come out.
When MySQL thought February 31 was a date, Postgres thought data was something you chewed up and swallowed, and if you were lucky, it might come out the other end as a pile of shit, after rebooting because it locked up the whole machine.
writing an validate_date() function before submitting a query was alot easier than starting over from scratch with a fully ACID compliant database that was most reliable when it wouldn't accept any connections because it had exhausted all system resources, because once you got your data in, you couldn't count on it coming out right.
That's why Postgres doesn't have the uptake, because it has a bad reputation. And while they may have beaten most of the bugs into submission, too many people remember getting burned and don't want to wait for the next subtle catastropic glitch.
Something that starts simple and works right from the start, adding features slowly is better than something complex that aims for "correctness" but works wrong until the bugs are fixed.
actually, there is a very good reason to not use python for HTML template scripting, and anyone who's used JSP knows why, despite what the python users say about "using a proper text editor"
[PHP's design is fucked up. Some functions have underscores, others don't; some have numbers, others don't]
This is the sum of your critique of the language!?! You don't like the name of some of the functions that are included with it?!?
For $5 I'll sell you a patched PHP, just give me your list of preferred functions, and you can have (apparently) the perfectly designed language.
I say Perl's design is fucked up. The different sigils are on different parts of the keyboard. @ isn't next to % and by god, $ comes after @ on the keyboard. If only @ meant scalar, # meant array, and $ meant hash, then it'd be the perfect language design. Only Perl 6 (if it ever gets written) really does fuck up sigils because @foo[$i] doesn't mean anything.
Yes. About the only use for Unicode is keeping track of your Elvish and Klingon dipthongs in the same character set. 2 byte words is enough for China and Japan has their own system that works. Meanwhile, everyone uses ascii except when representing pictograph characters.
I want to split my time between Montana and Fiji, but since I need to work, and I know IT, I'm living in Seattle. It's a choice really.
If you are a recent college graduate with a degree computer science and you live 45 miles out of Little Rock and are unwilling to move, either write some chicken farm management software and sell it yourself, or expect long drives to infrequent job interviews. Of course, If you live in Cupertino and aren't any good, you probably won't recruiters from Google breathing down your neck.
Maybe it's just me, but the IT job market seems hotter now than it was in 2000.
Lets say you've got some software (say a J2EE Server or database) that costs $10,000 or more per instance and you need 40 instances. Or one big fat honking virtual instance. All the sudden you save money. Except that many big iron apps get around this by charging per CPU, exactly because people were throwing big iron at the problem before. Then small machines started getting faster than big Iron, say a dual Xeon outperforming a 16 way SPARC, and then the licensing model fell apart, and some companies relaxed their per CPU rules.
But creating hydrogen fuel through electrolysis and then burning the hydrogen and converting it to energy is much *less* efficient than using the energy that would have been used to perform elecrolysis directly. Two points. 1) If you find a more efficient way to generate usable hydrogen fuel. 2) If you use energy from a non-portable power source (such as coal or nuclear generators) to process the hydrogen. But even with these, you still have the issue that gasoline is more portable and stable than hydrogen fuel. One more point. If you could convert the hydrogen to fuel cells effeciently. But you would then again lose energy in the inefficent transferance.
That's because there is 10,000 times as much energy produced by coal burning than by nuclear reactors.
I think maybe that "bureaucracy forging ahead" might have had something to do with the manager fearing for his life under a brutal dictatorship that demanded results. Whether he was incompedent or not was irrelevant, since the structure of the government meant he got his position through nepotism, and would have been replaced, compedent or not if he'd disobeyed.
It was malicious flaw inherent in the system, a not a mistake.
Well, um, learning is kindof a way to support education.
If the Germans had gone west into Britain, the Russians would damn sure have attacked them. Unless you forgot, Stalin signed that non-agression pact too, not just Ribbentrop. That means that Russia had something to get out of it, and they didn't need the paperwork to take half of Poland. They got that very nicely on their own, militarily. Stalin wanted to build up his forces and wait for Germany to be entangled with the west before he struck, so Hitler *had* to beat him to the punch. If you thought Stalingrad was ugly, you wouldn't believe what the battle of Britain would have been. At the very least, Stalingrad plus D-Day, plus the Battle of Britain, plus an unlikely capability of supressing the popular insurgency, an all out American attack (we'd've retreated to the 48 in the Pacific and concentrated on eliminating Germany.
But capturing Enigma machines and code books is what really helped them along.
Funny how all the top-secret technological advances by the Americans, Germans, Russians, Japanese, and Lichtensteinians all saw the light of day eventually, but somehow British technology was so secret that all traces of it have disappeared. Maybe it's because the British were so much smarter than the rest of us that that's why they were able to keep it secret. Or maybe it's just a silly myth designed to stroke the ego of a declining empire.
that's a guaranteed way to get cracked. It wouldn't take more than a cursory glance (or at best a bit of statistical analysis) to tell the difference between the gibberish and the cyphered text. A really bad crypto would improve itself with a moderate amount of gibberish (say 50-75%) so that if partially broken, it would resist guessing. But unless your crypto is being broken by hand already, or if it is entirely uncrackabl, interleaving gibberish with cyphertext is a sure way to weaken your encryption.
If you couldn't wrap your sentences in
and space your paragraphse with
, then you probably couldn't handle punctuation or capitalization either.
Oh.
why not: Customer::add("name=Bob", "phone=555-1234") or even: $bob = ORM::Create("customer"); $bob->name("Bob"); $bob->phone("555-1234"); DB::connect("user:pass@dbname/example.com"); DB::insert(ORM::to_sql(& $bob));
OO People are going to hate this, but the trick to resusability is to create procedural code. Treat data as God intended it to be used -- as input and output.
If your code relies on specific objects & data structures, it will be less re-usable. Objects are domain specific. A 'car' object in a racing game is different from a 'car' in a mechanic's billing application, even if they both have a car type of 'Ferarri'. That's where alot of cruft in OOP comes in, tying data to closely to behavior.
Object Oriented programming isn't meant to increase reusability, it is for reducing complexity.
Malthus didn't know anything about agriculture. If you plant a seed you get anywhere from 1 to 1000 plants on return. With people you get 1/2 to 10.
There's a hundred years of oil in the US. There's thousands of years of coal at current energy production needs.
That's idiotic. Civilizations can't "collapse" at the bottom of their power. Stocks go down when they reach their highest selling point. Mountain climber have to turn back at the summit. Stairs only go down from the top floor.
If we just kill off all the hypocrites demanding that the rest of us change our corpulent waste of resources(so that they can learn from our example, I'm sure), then those answers would be 'quite a while longer' and 'plenty long'. The best way to conserve oil is to reduce the population. The next best way is to drill for more. Every new well saves hundreds of idiots from the slaughter.
No we should drill for more oil to exceed our current shallow lifestyles, thereby allowing us to attain more meaning in our lives thanks to the additional energy obtained.
Yes repeal the tax cuts! There are too many recruiters calling me.
Postgres just isn't in the same category as MySQL. It isn't stable.
Flames aside, Postgres developers are just as susceptable to big paychecks as anyone else. The difference is that they don't have a valuable trademark or a reputation worth buying. And that they're not even on Oracle's radar as a competitor. Maybe next year they will be. And maybe they can all retire to islands when they get bought out. Or maybe they'll all take rewarding jobs at Oracle integrating Postgres with Peoplesoft & Siebel. Or maybe they'll choose to keep working on it.
But MySQL and they're current customers aren't threatened. In fact, they're guaranteed safety. The question is whether the BDB and InnoDB developers are still motivated enough to keep developing newer and better code when they could surfing privateislandsonline.com with intent.