Perhaps the funniest Engrish example I've ever read... lol.
What's truly amazing is that most half-intelligent English speakers can still make sense of this. English is a robust context-sensitive language that can route around all kinds of damage. It ain't always pretty, but it survives an incredible amount of contortion by English (and quasi-English) speakers around the world.
I seem to recall reading that in the book "The Mother Tongue", by Bill Bryson. Quite funny, except I believe that was not machine-translated. Actually, that makes it even funnier.
forgive my Ruby newbiage, but exactly how would you call this function? In the Javascript and Python versions you can do foo(4)(4) which returns 8, but when I try that in the Ruby code above, I get
It flies in the face of my experience, too. Even with the older 7.x series, if I accidentally ran a stupid query, (for example, a join on multiple tables, forgetting the WHERE clause, resulting ridiculous multiplication of returned rows) PostgreSQL would literally run that query for 24 hours without dying, until I finally killed the query or re-started the server.
Come to think of it, I haven't had PostgreSQL ever die on me, once. Even when my server crashed and rebooted, PostgreSQL would just happily pick up where it left off and get back to work.
Meanwhile, on more than one Linux server I had the pleasure to maintain, MySQL was notorious for randomly dying.
Something tells me that the person who wrote this report simply read the MySQL mailling lists, and compiled his report from the discussions, without any real testing, much less considering that a checklist is meaningless unless you also evaluate how WELL each DBMS implements said feature.
> > > You mean the magic Darwen/Date/Pascal relational model? The one nobody has > > > managed to implement despite the 25 years it's been around?
> > Ahh yes, the old canard. Actually, several companies and individuals have > > implemented the relational model MUCH more faithfully than the typical SQL > > vendor.
> Name one, and make sure it's one that's disallowed NULLs completely. Date, > Darwen and Pascal's fear of recording states of ignorance is ill-founded in > real-world conditions. Codifying that fear isn't even well-founded in last > century's mathematical theory. Yes, it's true that multi-value logics are > just a teensy tad more complicated theoretically than 2VL. That does > not imply that they're less useful, or that the systems built around > them are more complicated than the truly wackily byzantine things D, D & P > suggest as workarounds for not having NULLs.
You're mischaracterizing the argument. I said "MUCH more faithfully". I know there's no perfect implementation, nor will there likely ever be. Name one perfect implementation of the SQL standard. But, there have definitely been *better* implementations, ones that attempt to fit the concepts of the relational model more closely. You know the ones I'm going to talk about: Duro, Rel, Alphora, etc... The fact is very few people care about these, for the same reason that very few people care to be told to eat their vegetables, or in fact to be told there is a better way to do whatever it is they are doing. That doesn't make my argument wrong.
Meanwhile, I'm not a slavish ideologue about this. I personally don't care about the NULL thing, because I think there are sensible arguments on both sides, and no easy resolution. But, supporting duplicate rows, rowIDs, positional attributes, etc... seem to me such blindingly obvious bad choices. This is without even getting to the more abstract stuff like transitive closure. Of course there are trade-offs in the real world, but why trade off things that are useful to gain things that are not?
> > The problem is not one of difficulty, but rather of popularity and > > marketing.
> Nope. See below.
> > In fact, several solo-developer projects have implemented it on the logical > > level much better than your typical SQL vendor. The problem is that those > > guys don't have a) the marketing budget and 20 years of industry buy-in, and > > b) the developer team to implement all the "enterprisey" features like > > clustering, failover, etc...
> > And by the way, there is nothing about the "true relational model" that > > makes those things harder to implement.
> That it's been 25 years and nobody has implemented it, despite > resources in industry, government, academia and open source, flatly > contradicts your assertion.
In other words, it can't be done because it hasn't been done? Fallacy. Tell me a logical *reason* why it can't be done.
BTW, I have a hard time believing that someone with your.sig would think that big government, modern academia, and big business are the standard bearers for logic and the limits of human endeavor;).
> > They are if anything LESS difficult to implement with a true relational DBMS > > than with an SQL DBMS, which has to handle all kinds of oddities like > > duplicate rows, position-dependent syntax, pointers, and many other > > nonsensical rules of SQL.
> > I know lots of you database pros out there hate to hear from guys like > > Date,Darwen and co.
> Nonsense. It's not that we don't like to hear from theoreticians. It's that > we don't want to hear from doctrinaire ideologues like D, D & P, especially > when they have only "angels dancing on the head of a pin" to show for their > side. One theoretic
You mean the magic Darwen/Date/Pascal relational model? The one nobody has managed to implement despite the 25 years it's been around?
Ahh yes, the old canard. Actually, several companies and individuals have implemented the relational model MUCH more faithfully than the typical SQL vendor. The problem is not one of difficulty, but rather of popularity and marketing.
In fact, several solo-developer projects have implemented it on the logical level much better than your typical SQL vendor. The problem is that those guys don't have a) the marketing budget and 20 years of industry buy-in, and b) the developer team to implement all the "enterprisey" features like clustering, failover, etc... And by the way, there is nothing about the "true relational model" that makes those things harder to implement. They are if anything LESS difficult to implement with a true relational DBMS than with an SQL DBMS, which has to handle all kinds of oddities like duplicate rows, position-dependent syntax, pointers, and many other nonsensical rules of SQL.
I know lots of you database pros out there hate to hear from guys like Date,Darwen and co. but the thing is they are right: the DBMS world has opted for mediocrity and over-complexity. Of course, that's the way it is with most things in life:(.
OLAP itself is the kind of thing we thought we'd never have to do because of the power of the relational model. Well, we were wrong.
How would we know? We have never yet seen a DBMS that really implements the relational model (at least, not in the normal world of business software). Show me the word 'relational' in the SQL standard, anywhere. What we have is all sorts of incredible complication to work around the fact that SQL itself is a damaged and confused (and at times contradictory) approach to the problem.
The serious theorists I have read argue that the reason we need all the performance workarounds is *precisely because* we are not really working with a relational system, and all the vendors conflate logical levels and physical storage levels to various degrees.
I mean... did this OP rush to push out a lackluster FP on PG, or what?
Practically the only informative part of this post is focusing on the perceived negative (which is a dubious one, IMHO).
Never mind that Postgres has actually turned out some nice feature advances in this release, although they don't make for good marketspeak bullet points. There have been advances in performance, table partitioning, clustering, query logic, user-defined functions, etc... pretty much every area of "enterprise" database development except for the one area the OP chooses to focus.
You (and people like you) are exactly why we are in this mess to begin with.
You look at the American government through polarized lenses.
The problem is much deeper than that. It's not a question of partisanship but of a *greatly* reduced spectrum of choices. When the choice of meal is hamburger, ground beef, or minced cow, some of us start to get just a little skeptical. Basically, the whole argument these days comes down to who wants to "do more" and thus usurp more of your freedoms in the process. No one even asks "Why do we want politicians to do anything? How exactly have they helped us?". No one dares to ask what would happen if we just started ignoring the politicians (Oh no! We have to do something, or the wrong lizard might get in). No one seems to remember that the USA was made of people who believed it was the citizen's obligation to replace government--by force if necessary--if that government abuses its position.
What the democrats propose one decade, the republicans carry out in the next. The republicans of today would be considered leftist by the democrats of a century ago. The right's "seed of democracy in the middle east", is the left's Wilsonian War Democracy of two generations previous. The partisanship is a sham, and all part of the process of herding us down the ever narrower path into the corral.
And whence this strangely reduced spectrum of possibility? It all began in the 1850s when the USA made the horrendous decision to adopt the Prussian method of (enforced) public schooling, whose expressed purpose was that of breeding out independent thought and self-direction, in favor of--essentially--groupthink and dependence on authority. This is the schooling system that has given us such wonderful concentration-breakers as the 45-minute class period, punctuated by the loud martial sounds of a bell, the drudgery of homework rather than the wonder of reading, the division of knowledge up into upteen tiny containers called "subjects", the concept of "grades" and "classes", and Grade Point Averages, essentially industrializing the whole process of guiding fresh explorative minds into the same well-worn pathways. And that classic inarticulate teenage rebellion is just a recognized byproduct that actually works in the favor of all this. Why else would we keep on doing something that obviously is not working, when the past is rife with better ways?
It has done exactly what the elite wanted; it has created generations of citizens without the mental initiative to think beyond the simple choices they are presented with.
Yes, when you think about all the capabilitise you get in such a small package, it puts most large application libraries like Java to shame.
I use PHP extensively as a Unix scripting language. It performs quite well, even running a collection of scripts for an extended time as a daemon. You might be surprised how efficient PHP is at handling very large arrays running in memory.
And yes, it is a workhorse. It may have a few oddities and rough edges, but mostly it just stays out of the way and lets you work.
Yes, really... an informative and helpful FP getting modded down. Oh wait... this is Slashdot. It was modded down because the canonical form of a first post is in fact an off-topic rant, or some stupid pun on the story title.
Re:More Cooking with SQL
on
SQL Cookbook
·
· Score: 1
Arrggh... why do you have to write this in the morning? You're making me hungry. I need to start having a real breakfast.
CREATE TRIGGER AFTER UPDATE TO Mental_Picture IF NEW.image = 'Eggs & Bacon' AND NEW.sound = 'Sizzle' EXECUTE PROCEDURE Salivate(NOW());
And it never occured to him to systematically unplug each device to see if it was the one causing the problem and then spend $99 on a new router? Something seems mighty fishy to me.
Either this is a very weak attempt at a troll, or an incredible demonstration of ignorance.
So true. Also, programming (as it is understood by most people) is just the bricklayer level of working with logical systems. It is not the same thing as system architecture, database design, application framework design, protocol development or a host of other interesting things one can do in and around computing. In most fields, one is expected to mature and spend less and less time on the nuts and bolts, and more time telling others what to do with the nuts and bolts.
As developers get older, they have two choices: grow, or rust. Growing doesn't mean "keeping up with the times" a la AJAX or XQuery but of realizing which areas of this business are timeless, and which are a real demonstration of one's intellectual capability. If you are still banging out database entry forms at 40, and trying to learn how to work with yet another poorly conceived, overly complex, inconsistently abstracted application library handed to you by your IT leader, then you might want to think about moving on, or picking up a book or two and learning how to be an architect instead of a journeyman.
But really, I did just turn 40, and my skills are better than ever. But, it takes constant tending to keep one's mind from falling in a rut. The simple fact is most people don't want to learn anything new after they turn 30 (or 25, for that matter).
I hear all the crying about being passed up for younger developers, but honestly I have never experienced it. Maybe that's because I have stayed away from big national companies, and I have consistently moonlighted on interesting projects, expanding my knowledge all the time. My biggest problem these days is turning away requests.
Yes, there is that great gray mass of Fortune 500 companies with their standardized hiring patterns, etc... but really, small-to-medium sized businesses still account for just as significant a part of the economy, at least in the USA. And if you actually work on your personality a little, there's no reason for employers to pass you up after 40. The key is that you have to work smarter, not harder, and getting employed. Don't submit your resume through the usual channels; that's a losing game even for younger programmers. If you have genuine ability--and are personable, then people who know you will refer you to others, and you will never be out of work.
Also, as you age, you learn to play to your strengths and interests. If you find it mind-numbingly boring to develop your nth object-relational mapping for a database web application, using 8 layers of abstraction just to generate a simple HTML form, then DO SOMETHING ELSE. I did, and have never been happier. There are plenty of other computer-related problems to solve.
Well, it hasn't happened to me, and I turned 40 last month. Why, just yesterday I was..., I was... Umm... doing one of those pointer thingies, and... database... uh...
Now all we need is a method to freeze-dry and reconstitute a human being.
Somewhere, Paul Linebarger is smiling in his grave. For all that his sci-fi seemed so surreal and not too heavy on the hard science, it might just prove a little more prophetic than we thought.
Scanners live in vain
Re:Backgrounds of the PHP developers.
on
PHP 5.1.0 Released
·
· Score: 1
Maybe you can't declare your own superglobals, but you can easily redefine (basically "repurpose") the existing ones. Here is a stupid example:
<?php phpinfo(); $_GET = "Not what I put on the URL line"; function getit() {
echo "<br>{$_GET}</br>"; } getit(); ?>
Now run this in your browser and throw some vars in the URL and you will see that they show up in phpinfo() output, but $_GET is redefined afterward and available inside a function. Since $_GET or the other superglobals can be of any type, including multidimensional arrays or objects, you can easily exploit this to have truly global data structures. And in so doing, you can possibly even increase your security against URL request hacking.
Re:Never Program- RFC822, workarounds
on
PHP 5.1.0 Released
·
· Score: 1
Indeed. The parent poster sounds like someone who would complain that C won't automatically prevent buffer overflows. Every language designer must make a choice about what level of abstraction that language will attempt to cover. PHP is basically just a scriptified C. Nothing wrong with that, but it is not a hand-holding language. You are still responsible for validating user input at every level. I suppose in that sense PHP is not the equivalent of Java+[giant servlet framework]. It is more the language for someone who wants to design a framework *.
For example, to deal with the mail problem, try using a decent mail handler class like phpMailer
* Unfortunately though, most PHP frameworks are, er... slightly... horrible.
Re:Backgrounds of the PHP developers.
on
PHP 5.1.0 Released
·
· Score: 1
Agreed.
Heh, of all the things to complain about with PHP, why would someone pick *that* issue?
For those who really understand relational database design, there is nothing that object inheritance can represent that you can't handle relationally.
In fact, the PostgreSQL team has been musing for years on whether to drop object inheritance completely, because it just muddies the waters of relational design, and causes implementation details to affect logical design.
But interestingly, table inheritance has become a solution to a lower-level implementation problem: "horizontal" table partitioning. Using inheritance together with tablespaces (available since 8.0), you can break a large table into multiple subtables, each on a different physical storage device, then make a table that inherits from them all to present unified querying to the whole range of data. This is a *big* advantage for very large databases.
You hear a lot of complaints regarding MySQL integrity because MySQL still is only a bit player in that game. Even with all the strict options set, you still have certain problems such as invalid date values. But more importantly, you don't have two of the most useful data integrity tools known to SQL: a) the CHECK constraint, and b) domains. Not to mention, MySQL also doesn't have custom datatypes. For many serious applications, such as GIS special datatypes--along with special operators--are of paramount importance.
Don't get me wrong... progress is still progress, and MySQL has made some serious progress, but facts are still facts.
Slashdot Mirror
Perhaps the funniest Engrish example I've ever read... lol.
What's truly amazing is that most half-intelligent English speakers can still make sense of this. English is a robust context-sensitive language that can route around all kinds of damage. It ain't always pretty, but it survives an incredible amount of contortion by English (and quasi-English) speakers around the world.
I seem to recall reading that in the book "The Mother Tongue", by Bill Bryson. Quite funny, except I believe that was not machine-translated. Actually, that makes it even funnier.
It flies in the face of my experience, too. Even with the older 7.x series, if I accidentally ran a stupid query, (for example, a join on multiple tables, forgetting the WHERE clause, resulting ridiculous multiplication of returned rows) PostgreSQL would literally run that query for 24 hours without dying, until I finally killed the query or re-started the server.
Come to think of it, I haven't had PostgreSQL ever die on me, once. Even when my server crashed and rebooted, PostgreSQL would just happily pick up where it left off and get back to work.
Meanwhile, on more than one Linux server I had the pleasure to maintain, MySQL was notorious for randomly dying.
Something tells me that the person who wrote this report simply read the MySQL mailling lists, and compiled his report from the discussions, without any real testing, much less considering that a checklist is meaningless unless you also evaluate how WELL each DBMS implements said feature.
> > > You mean the magic Darwen/Date/Pascal relational model? The one nobody has
.sig would think that big government, modern academia, and big business are the standard bearers for logic and the limits of human endeavor ;).
> > > managed to implement despite the 25 years it's been around?
> > Ahh yes, the old canard. Actually, several companies and individuals have
> > implemented the relational model MUCH more faithfully than the typical SQL
> > vendor.
> Name one, and make sure it's one that's disallowed NULLs completely. Date,
> Darwen and Pascal's fear of recording states of ignorance is ill-founded in
> real-world conditions. Codifying that fear isn't even well-founded in last
> century's mathematical theory. Yes, it's true that multi-value logics are
> just a teensy tad more complicated theoretically than 2VL. That does
> not imply that they're less useful, or that the systems built around
> them are more complicated than the truly wackily byzantine things D, D & P
> suggest as workarounds for not having NULLs.
You're mischaracterizing the argument. I said "MUCH more faithfully". I know there's no perfect implementation, nor will there likely ever be. Name one perfect implementation of the SQL standard. But, there have definitely been *better* implementations, ones that attempt to fit the concepts of the relational model more closely. You know the ones I'm going to talk about: Duro, Rel, Alphora, etc... The fact is very few people care about these, for the same reason that very few people care to be told to eat their vegetables, or in fact to be told there is a better way to do whatever it is they are doing. That doesn't make my argument wrong.
Meanwhile, I'm not a slavish ideologue about this. I personally don't care about the NULL thing, because I think there are sensible arguments on both sides, and no easy resolution. But, supporting duplicate rows, rowIDs, positional attributes, etc... seem to me such blindingly obvious bad choices. This is without even getting to the more abstract stuff like transitive closure. Of course there are trade-offs in the real world, but why trade off things that are useful to gain things that are not?
> > The problem is not one of difficulty, but rather of popularity and
> > marketing.
> Nope. See below.
> > In fact, several solo-developer projects have implemented it on the logical
> > level much better than your typical SQL vendor. The problem is that those
> > guys don't have a) the marketing budget and 20 years of industry buy-in, and
> > b) the developer team to implement all the "enterprisey" features like
> > clustering, failover, etc...
> > And by the way, there is nothing about the "true relational model" that
> > makes those things harder to implement.
> That it's been 25 years and nobody has implemented it, despite
> resources in industry, government, academia and open source, flatly
> contradicts your assertion.
In other words, it can't be done because it hasn't been done? Fallacy. Tell me a logical *reason* why it can't be done.
BTW, I have a hard time believing that someone with your
> > They are if anything LESS difficult to implement with a true relational DBMS
> > than with an SQL DBMS, which has to handle all kinds of oddities like
> > duplicate rows, position-dependent syntax, pointers, and many other
> > nonsensical rules of SQL.
> > I know lots of you database pros out there hate to hear from guys like
> > Date,Darwen and co.
> Nonsense. It's not that we don't like to hear from theoreticians. It's that
> we don't want to hear from doctrinaire ideologues like D, D & P, especially
> when they have only "angels dancing on the head of a pin" to show for their
> side. One theoretic
You mean the magic Darwen/Date/Pascal relational model? The one nobody has managed to implement despite the 25 years it's been around?
:(.
Ahh yes, the old canard. Actually, several companies and individuals have implemented the relational model MUCH more faithfully than the typical SQL vendor. The problem is not one of difficulty, but rather of popularity and marketing.
In fact, several solo-developer projects have implemented it on the logical level much better than your typical SQL vendor. The problem is that those guys don't have a) the marketing budget and 20 years of industry buy-in, and b) the developer team to implement all the "enterprisey" features like clustering, failover, etc... And by the way, there is nothing about the "true relational model" that makes those things harder to implement. They are if anything LESS difficult to implement with a true relational DBMS than with an SQL DBMS, which has to handle all kinds of oddities like duplicate rows, position-dependent syntax, pointers, and many other nonsensical rules of SQL.
I know lots of you database pros out there hate to hear from guys like Date,Darwen and co. but the thing is they are right: the DBMS world has opted for mediocrity and over-complexity. Of course, that's the way it is with most things in life
Why is this modded 0? A nicely relevant post.
OLAP itself is the kind of thing we thought we'd never have to do because of the power of the relational model. Well, we were wrong.
How would we know? We have never yet seen a DBMS that really implements the relational model (at least, not in the normal world of business software). Show me the word 'relational' in the SQL standard, anywhere. What we have is all sorts of incredible complication to work around the fact that SQL itself is a damaged and confused (and at times contradictory) approach to the problem.
The serious theorists I have read argue that the reason we need all the performance workarounds is *precisely because* we are not really working with a relational system, and all the vendors conflate logical levels and physical storage levels to various degrees.
I mean... did this OP rush to push out a lackluster FP on PG, or what?
Practically the only informative part of this post is focusing on the perceived negative (which is a dubious one, IMHO).
Never mind that Postgres has actually turned out some nice feature advances in this release, although they don't make for good marketspeak bullet points. There have been advances in performance, table partitioning, clustering, query logic, user-defined functions, etc... pretty much every area of "enterprise" database development except for the one area the OP chooses to focus.
You (and people like you) are exactly why we are in this mess to begin with.
You look at the American government through polarized lenses.
The problem is much deeper than that. It's not a question of partisanship but of a *greatly* reduced spectrum of choices. When the choice of meal is hamburger, ground beef, or minced cow, some of us start to get just a little skeptical. Basically, the whole argument these days comes down to who wants to "do more" and thus usurp more of your freedoms in the process. No one even asks "Why do we want politicians to do anything? How exactly have they helped us?". No one dares to ask what would happen if we just started ignoring the politicians (Oh no! We have to do something, or the wrong lizard might get in). No one seems to remember that the USA was made of people who believed it was the citizen's obligation to replace government--by force if necessary--if that government abuses its position.
What the democrats propose one decade, the republicans carry out in the next. The republicans of today would be considered leftist by the democrats of a century ago. The right's "seed of democracy in the middle east", is the left's Wilsonian War Democracy of two generations previous. The partisanship is a sham, and all part of the process of herding us down the ever narrower path into the corral.
And whence this strangely reduced spectrum of possibility? It all began in the 1850s when the USA made the horrendous decision to adopt the Prussian method of (enforced) public schooling, whose expressed purpose was that of breeding out independent thought and self-direction, in favor of--essentially--groupthink and dependence on authority. This is the schooling system that has given us such wonderful concentration-breakers as the 45-minute class period, punctuated by the loud martial sounds of a bell, the drudgery of homework rather than the wonder of reading, the division of knowledge up into upteen tiny containers called "subjects", the concept of "grades" and "classes", and Grade Point Averages, essentially industrializing the whole process of guiding fresh explorative minds into the same well-worn pathways. And that classic inarticulate teenage rebellion is just a recognized byproduct that actually works in the favor of all this. Why else would we keep on doing something that obviously is not working, when the past is rife with better ways?
It has done exactly what the elite wanted; it has created generations of citizens without the mental initiative to think beyond the simple choices they are presented with.
sigh...
(my child is being home-schooled, as I was)
Next: a joint project with Scalar Composites to develop the laminated mouse brain computer.
Yes, when you think about all the capabilitise you get in such a small package, it puts most large application libraries like Java to shame.
I use PHP extensively as a Unix scripting language. It performs quite well, even running a collection of scripts for an extended time as a daemon. You might be surprised how efficient PHP is at handling very large arrays running in memory.
And yes, it is a workhorse. It may have a few oddities and rough edges, but mostly it just stays out of the way and lets you work.
Yes, really... an informative and helpful FP getting modded down. Oh wait... this is Slashdot. It was modded down because the canonical form of a first post is in fact an off-topic rant, or some stupid pun on the story title.
Arrggh... why do you have to write this in the morning? You're making me hungry. I need to start having a real breakfast.
CREATE TRIGGER AFTER UPDATE TO Mental_Picture IF NEW.image = 'Eggs & Bacon' AND NEW.sound = 'Sizzle' EXECUTE PROCEDURE Salivate(NOW());
And it never occured to him to systematically unplug each device to see if it was the one causing the problem and then spend $99 on a new router? Something seems mighty fishy to me.
Either this is a very weak attempt at a troll, or an incredible demonstration of ignorance.
Oh yes, we should take Steve Quayle seriously. Heh.
Programming is a skill, not a career.
So true. Also, programming (as it is understood by most people) is just the bricklayer level of working with logical systems. It is not the same thing as system architecture, database design, application framework design, protocol development or a host of other interesting things one can do in and around computing. In most fields, one is expected to mature and spend less and less time on the nuts and bolts, and more time telling others what to do with the nuts and bolts.
As developers get older, they have two choices: grow, or rust. Growing doesn't mean "keeping up with the times" a la AJAX or XQuery but of realizing which areas of this business are timeless, and which are a real demonstration of one's intellectual capability. If you are still banging out database entry forms at 40, and trying to learn how to work with yet another poorly conceived, overly complex, inconsistently abstracted application library handed to you by your IT leader, then you might want to think about moving on, or picking up a book or two and learning how to be an architect instead of a journeyman.
But really, I did just turn 40, and my skills are better than ever. But, it takes constant tending to keep one's mind from falling in a rut. The simple fact is most people don't want to learn anything new after they turn 30 (or 25, for that matter).
I hear all the crying about being passed up for younger developers, but honestly I have never experienced it. Maybe that's because I have stayed away from big national companies, and I have consistently moonlighted on interesting projects, expanding my knowledge all the time. My biggest problem these days is turning away requests.
Yes, there is that great gray mass of Fortune 500 companies with their standardized hiring patterns, etc... but really, small-to-medium sized businesses still account for just as significant a part of the economy, at least in the USA. And if you actually work on your personality a little, there's no reason for employers to pass you up after 40. The key is that you have to work smarter, not harder, and getting employed. Don't submit your resume through the usual channels; that's a losing game even for younger programmers. If you have genuine ability--and are personable, then people who know you will refer you to others, and you will never be out of work.
Also, as you age, you learn to play to your strengths and interests. If you find it mind-numbingly boring to develop your nth object-relational mapping for a database web application, using 8 layers of abstraction just to generate a simple HTML form, then DO SOMETHING ELSE. I did, and have never been happier. There are plenty of other computer-related problems to solve.
Well, it hasn't happened to me, and I turned 40 last month. Why, just yesterday I was..., I was... Umm... doing one of those pointer thingies, and... database... uh...
help me
Now all we need is a method to freeze-dry and reconstitute a human being.
Somewhere, Paul Linebarger is smiling in his grave. For all that his sci-fi seemed so surreal and not too heavy on the hard science, it might just prove a little more prophetic than we thought.
Scanners live in vain
Indeed. The parent poster sounds like someone who would complain that C won't automatically prevent buffer overflows. Every language designer must make a choice about what level of abstraction that language will attempt to cover. PHP is basically just a scriptified C. Nothing wrong with that, but it is not a hand-holding language. You are still responsible for validating user input at every level. I suppose in that sense PHP is not the equivalent of Java+[giant servlet framework]. It is more the language for someone who wants to design a framework *.
For example, to deal with the mail problem, try using a decent mail handler class like phpMailer
* Unfortunately though, most PHP frameworks are, er... slightly... horrible.
Agreed.
Heh, of all the things to complain about with PHP, why would someone pick *that* issue?
For those who really understand relational database design, there is nothing that object inheritance can represent that you can't handle relationally.
In fact, the PostgreSQL team has been musing for years on whether to drop object inheritance completely, because it just muddies the waters of relational design, and causes implementation details to affect logical design.
But interestingly, table inheritance has become a solution to a lower-level implementation problem: "horizontal" table partitioning. Using inheritance together with tablespaces (available since 8.0), you can break a large table into multiple subtables, each on a different physical storage device, then make a table that inherits from them all to present unified querying to the whole range of data. This is a *big* advantage for very large databases.
You hear a lot of complaints regarding MySQL integrity because MySQL still is only a bit player in that game. Even with all the strict options set, you still have certain problems such as invalid date values. But more importantly, you don't have two of the most useful data integrity tools known to SQL: a) the CHECK constraint, and b) domains. Not to mention, MySQL also doesn't have custom datatypes. For many serious applications, such as GIS special datatypes--along with special operators--are of paramount importance.
Don't get me wrong... progress is still progress, and MySQL has made some serious progress, but facts are still facts.