Today's modern executive with the golden parachute takes, the short term approach, today's stock market takes the short term approach, the whole capitalist^H^H^H^Hcorporate/fascist system is in reality driven by the short term approach
You really don't think that what we have now is capitalism, do you? The rest of your rant is understandable in its vitriol and spittle, but it should be directed to the large corporations and their protectionist lackeys in government, not toward genuine capitalism, which is only alive in small business these days, and being continually squeezed by more and more bureaucracy. Really, the amount of paperwork someone has to go through to operate--for example--a small organic farm, is quite daunting, and is only going to get worse.
Any rational view of capitalism realizes that there is a limit to 'screw everything' profit, and the more people you screw, the sooner your profitable days will be over.
Only collectively. Individually, the only "rational" view is the fast-profits model.
The reason is, if you take the long-term approach, and everyone else doesn't, you've given up short-term profits, and everyone else has ruined the long-term profits model.
But if we take a collectivist view on the topic, and put into place regulations which forbid, or at the very least, sufficiently discourage, the unsustainable short-term profit seeking, then the rational individual capitalists can make solid decisions which both benefit them in the short-term, while benefiting everyone in the long-term, which ensures that the capitalist will have the opportunity to continue to make a profit, instead of having the carpet pulled out from under him.
I understand the *impulse* that makes people want to support the regulatory/interventionist view of the market. I just think this approach almost always has exactly the opposite effect to the desired.
Why do businesses take the short-term view? Sure there is short-sighted greed, but history shows us plenty of businesses who have taken the long view and watched their competitors crash and burn. (Charles Schwab were ridiculed by their competitors for not taking advantage of the subprime real estate market, but now they are one of the few financial firms in good shape)
But consider the possibility that the whims of government are one big *cause* of short-term strategy. You really can't know from one administration to the next what the economic policy is going to be. Inflate? Deflate? Better get our profits now before who knows what happens. And of course the bigger the business, the more implicit the assumption that government will bail out any bad choices. So what we have is a situation that punishes thoughtful preparation, rewards the political old-boy network, and makes things ever harder for small businesses to even get their foot in the door.
I have been in large and small business and the fact is that 95% of the small businesses in the USA can be terminated on a whim simply by some bureaucrat sniffing around. Meanwhile, these small businesses are forced to work at a much higher level of efficiency to large ones simply to stay afloat.
The reason I stress the importance of small business is that big business is not really capitalism--at least not in most of the modern world. It is more akin to corporatism or fascism, where risks are pushed to the public but profits are kept private.
That's a somewhat reasonable view when looked at in the short term. And yes, many capitalists only look in the short term, but that is to their detriment.
Any rational view of capitalism realizes that there is a limit to 'screw everything' profit, and the more people you screw, the sooner your profitable days will be over. Simple math: if you take advantage of a customer base, then that population has less money to buy your products the next year. Any genius who really wants to maximize profits learns fast that happy people are more likely to spend money than miserable people.
And any genius who has made all the money he wants and now craves public approval has all the incentive in the world to be a do-gooder. Unfortunately, they are too easily duped by activists of this or that stripe:(.
That is actually not a bad tactic at all, but first you just want to ask a few questions about why the bill is so high. You would be amazed at how often these things are negotiable. Just about every time I have raised questions with a hospital about some ridiculous cost (like $15 for a Tylenol or whatever) the hospital has revised the bill considerably.
It's not really fine. Well, sort of. The health care system has major problems because no one can really afford it without insurance. In fact, if you try and purchase medical care, the hospital will charge you more than they would charge an insurance company.
Not in my experience *at all*. I have been cruising without insurance for the better part of the past 10 years (and yes, with a family). What I have found is that doctors and hospitals are so frustrated with the insurance scamdustry that they will bend over backwards to work a straight deal. Also, they will gladly work out long-term payment plans, sometimes even interest-free.
I paid the hospital $4000, and our doctor $1400 at the birth of our last child. Yes, that was painful, but considering that insurance for a self-employed father of 3 will be at least $1200-1500/mo it was the better choice.
Do I want to be without insurance? No, but from here on out, the only insurance I will ever purchase is for 'catastrophic' events. That was the original idea of insurance, not as an agent to 'pay' for all ongoing costs.
Insurance and high finance are the two greatest scams going in America right now, and they can get away with it precisely because they have our political ruling class in their pockets. Time to starve the beast.
SQL is the perfect example of how a temporary hack becomes a standard that exists well beyond the original intention of the developers.
Read Hugh Darwen's "The Askew Wall" and "The Importance of Column Names" for a couple teeth-grinding examples of how needlessly screwed up this language is.
In fact, the language itself forces a suboptimal implementation of relational databases at the lower level. For one simple example, allowing for duplicate rows of necessity means storing more data than is needed, and not allowing for certain back-end optimizations. Another insanity is the need to preserve column ordering, and even allow for duplicate column names in query output.
Unfortunately, rather than fix SQL at the core, we get tons of additional features jammed into the SQL standard, many of which are contradictory to the relational model, and which often force 'implementation showing through in the interface'.
Honestly, the more rabid and on-the-offense a community gets, the more a am suspicious of the product.
Why be suspicious? It's pretty easy to get actual knowledge of what the product does without regard to fanbois or flamers. I don't make any choices for or against a product based on that. Also, if you browse the PostgreSQL mail lists, I think you'll see very little rabid-ness. You *will* see an intense dedication to quality, especially if you read the core developers' lists. Quite interesting discussions, there.
Anyway, isn't it just a little disingenuous to come to a PostgreSQL thread, and then accuse PostgreSQL supporters of being rabid? When something cool and new and shiny comes out in your favorite [whatever], don't you tend to get a little exuberant? Let them have their fun, and save the that stuff for a MySQL-vs-PostgreSQL thread.
Not one of these features is remotely compelling enough to switch an existing, working app from MySQL.
Maybe not the new features, but all the good features that PostgreSQL already had were plenty reason for me to switch my MySQL apps. I suppose it depends on your definition of 'working'. I found that modeling and enforcing constraints in application code instead of in the database was becoming prohibitive for any application of decent complexity. Of course, I know that there are two camps on that issue, and the OOP/Framework crowd (Ruby on Rails, DJango, etc...) tend to take the philosophy that the database is just a collection of table stores and all the intelligence belongs in the app.
I say "philosophy" rather than "opinion" because the difference deserves more respect. My meta-philosophy is that there are apps which work well that way, but there are many scenarios where database-oriented constraints provide much better long-term quality assurance.
No, you're missing the point. You are mistaking the concept for the implementation. Relational database management systems are a concept (well, a combination of concepts), and they can be implemented any way you want at the physical level. Most of the perceived problems with 'relational databases' are really problems with how SQL systems are implemented. It doesn't matter what storage mechanisms you have. As long as the *front end* (or API, or querying interface) allows you to express your instructions and receive results via declarative set logic rather than hierarchical navigation, then you have a relational database management system.
Re:Why is JavaScript is so popular? Lamda Function
on
ECMAScript 4.0 Is Dead
·
· Score: 2, Insightful
In my case, I really didn't START to like Javascript until I began to read up on it's functional capabilities.
I think there is more to Javascript's popularity than what you say. It is actually a fairly nice little language, and hopefully when a few annoyances are cleaned up in version 2.0 it will be used outside the browser more and more. In fact, anyone who has done some serious Mozilla application programming with XUL realizes that there is no reason Javascript must be restrained to a web browser context to be useful.
Yes, what suckage. Who on earth wants a simple, dynamic, low-cruft language with first-class functions, closures, lambdas and a prototype object system that still manages to look like the C language family? Evil, evil, evil...
Note: I don't consider myself enough of a language expert to judge your first assertion, but your second assertion makes me strongly suspect the first. That you would claim Brendan Eich has no business being associated with language design doesn't exactly help your case.
The only problem is that JavaScript/ECMAScript from a language point of view isn't really good. A strongly statically typed script language would have been better since it would have allowed the developers to catch a lot of bugs that now occasionally blows up in the face of the users.
That would be the worst possible thing to happen to Javascript. I know, I know... let's not get into a religious war over static/dynamic typing. There are valid points for each in different contexts, but a language in Javascript's problem domain is probably one of the worst contexts for static typing.
Keeping the language small, clean and simple should be the priorities. If you want Java in the browser, well... that's already available.
Umm... So because I know how to use object-oriented languages, I don't understand relational logic? I'm rather surprised to hear that.
Nowhere in my comments did I say that I "dislike relational logic". I do, however, think that building large applications in sql is a terrible idea.
A little touchy, are we? Notice I never said anything negative about OOP (although I share some of Tablizer's doubts). Nor did I even imply you were one of "most programmers".
About your analogy, well, that's just fucked. I don't think that using a declarative language to build applications is "not programming". I think that it is not productive (as does the rest of world).
The analogy is very apt, when you think about the power of abstraction. What TCP/IP did was to create a declarative abstraction that was layered over the old world of networking (the old idea of networking was that a connection == a phone call), and this abstraction made it possible to no longer worry about the intimate details of just how your connection established a path through the telco machinery. Take a look at Van Jacobsen's excellent talk for more background on this, including the social aspects I mentioned.
In the same way, relational logic made it possible to make logical assertions over your data without worrying about just how the underlying programming handled the details. Yes, it uses programming, and uses it brilliantly. Separation of concerns. Write a data management framework once, formalize it and generalize it (ergo the DBMS), rather than write it for every application.
I know I know, the balls I must have to suggest that you use your query language for queries. I've apparently drunk the "not writing everything in an incomplete language" kool-aid.
You made the assumption that because I defended object-oriented programming (controversial, I admit), I don't understand how to design a db schema. That's insane (and illogical).
I wasn't assuming anything about you at all. I was responding to Tablizer. But anyway, of course you can't completely develop an application with SQL, nor was that the intent (and SQL is a fairly poor implementation of the relational model anyway). But you CAN manage the data completely within a relational system, and leave the programming to handle all the other aspects. This provides a benefit of separating concerns, so you can manage your data without poking the innards of your application, and vice-versa.
And yes, it is "most programmers", not all. Most programmers have never been taught what the relational model really is, or what it is good for. Most of them don't even know what a "relation" is. It's one of the most disinformation-heavy subjects on the internet. Unless you have read at least one of C.J. Date's books, as well as perhaps Hugh Darwen, David MgGoveran, maybe Fabian Pascal, etc... you don't really know the relational model. In fact, learning SQL itself is somewhat counterproductive to understanding the relational model. It takes a little work to unlearn the bad concepts.
SQL is a high-level language which can be very powerful, reducing the need to hand-code collection-oriented idioms over and over. Perhaps relational-heads think differently than OOP-heads.
I think the separation goes more like "most programmers" vs. "Relational-heads". Most programmers seem to regard such a thing as "not really programming", just like the Big Telcom engineers blustered about TCP/IP as being "not really networking" back in the 60s and 70s. I am convinced that most programmers dislike relational logic because it involves a changed mindset, and because it actually removes the need for some of the things they like to have their hands on.
I can't tell you the number of times I have come across some elaborate construct in an application that could be reduced to a simple combination of a couple tables and a some constraints or rules to govern what goes in them. But that's not really programming...
Agreed. If I have to do OO, Ruby is about the nicest way of doing it. And Javascript (1.7, 1.8), perhaps. Unfortunately, Ruby still has some serious performance problems to address, and while there have been a few attempts at mod_js for serverside Javascript, at present there is nothing definitive.
Well, with PHP 5.3 (alpha), they are starting to do some things that interest me again. They finally added closures and lambda functions, which are two major ways to get some of the advantages of OO without all the boilerplate. (In fact, some would go so far as to say OO was a poor workaround to lack of Functional capabilities in some languages)
Namespaces are back, also, so you don't have to spend so much time worrying about name collision in functions.
Mod parent up please. Parent of parent needs to read just a little about Misesian vs. Keynesian economics. Libertarians assert that one of the primary purposes of government is to enforce contractual obligations, and by no means to encourage malfeasance or bail out bad decisions by businesses at taxpayer expense. The subprime scandal, (combined with inflation) is a perfect example of government using business and economics as a tool of social change, and of how that inevitably blows up in society's face. Of course, it is also a prime example of big business being complicit in raping the public. Modern big business is closer to being a wing of government than a member of the free market, anyway.
Read my post again. I never said the other person logged into the BSD box. I said that there was text all over the screen. This was not an XDM session waiting to receive a password, as in a standard Fedora install or some such. A bare console, with 'login:' prompt will show all kinds of text if you just start typing. Basically it looked something like this:
login: So I was telling him that blah blah blah blah.... Password: Login incorrect login: and if he ever wants to blah blah blah... Password: Login incorrect login: mycutepasswordtowhatever Password: Login incorrect login: TO ALL SALES LEADERS, remember.... Password: Login incorrect
Etc... and much more of this, so we had to hit scroll lock and review several pages worth of screen. And of course the other user's graphical interface had nothing to do with this, since all we were getting was keystrokes directly from the keyboard.
And yes, I did see this with my own eyes, and I've been working with Linux and Unix systems for nigh on 10 years now. The other person in the story had been doing serious Unix systems stuff for close to 20 years, so yes, this is credible.
In our development dept., one guy used a wireless Logitech keyboard to set up his test FreeBSD box, then left the box on for the next couple days without checking (he did log out, though). Next time we looked at it, the screen was covered with login passwords, chat discussions, company memos, etc... We fairly freaked for a minute, then after a bit of quick reconnaissance, discovered that the company's sales director was also using the same keyboard in an office 3 rooms over. So somehow not only did these two keyboards happen to have the same encryption key, but the signal went through 3 walls and 30 ft of space to reach our console. We stopped using wireless anything after that.
Slashdot Mirror
Today's modern executive with the golden parachute takes, the short term approach, today's stock market takes the short term approach, the whole capitalist^H^H^H^Hcorporate/fascist system is in reality driven by the short term approach
You really don't think that what we have now is capitalism, do you? The rest of your rant is understandable in its vitriol and spittle, but it should be directed to the large corporations and their protectionist lackeys in government, not toward genuine capitalism, which is only alive in small business these days, and being continually squeezed by more and more bureaucracy. Really, the amount of paperwork someone has to go through to operate--for example--a small organic farm, is quite daunting, and is only going to get worse.
Any rational view of capitalism realizes that there is a limit to 'screw everything' profit, and the more people you screw, the sooner your profitable days will be over.
Only collectively. Individually, the only "rational" view is the fast-profits model.
The reason is, if you take the long-term approach, and everyone else doesn't, you've given up short-term profits, and everyone else has ruined the long-term profits model.
But if we take a collectivist view on the topic, and put into place regulations which forbid, or at the very least, sufficiently discourage, the unsustainable short-term profit seeking, then the rational individual capitalists can make solid decisions which both benefit them in the short-term, while benefiting everyone in the long-term, which ensures that the capitalist will have the opportunity to continue to make a profit, instead of having the carpet pulled out from under him.
I understand the *impulse* that makes people want to support the regulatory/interventionist view of the market. I just think this approach almost always has exactly the opposite effect to the desired.
Why do businesses take the short-term view? Sure there is short-sighted greed, but history shows us plenty of businesses who have taken the long view and watched their competitors crash and burn. (Charles Schwab were ridiculed by their competitors for not taking advantage of the subprime real estate market, but now they are one of the few financial firms in good shape)
But consider the possibility that the whims of government are one big *cause* of short-term strategy. You really can't know from one administration to the next what the economic policy is going to be. Inflate? Deflate? Better get our profits now before who knows what happens. And of course the bigger the business, the more implicit the assumption that government will bail out any bad choices. So what we have is a situation that punishes thoughtful preparation, rewards the political old-boy network, and makes things ever harder for small businesses to even get their foot in the door.
I have been in large and small business and the fact is that 95% of the small businesses in the USA can be terminated on a whim simply by some bureaucrat sniffing around. Meanwhile, these small businesses are forced to work at a much higher level of efficiency to large ones simply to stay afloat.
The reason I stress the importance of small business is that big business is not really capitalism--at least not in most of the modern world. It is more akin to corporatism or fascism, where risks are pushed to the public but profits are kept private.
Thank you. Finally someone making some sense out of this.
That's a somewhat reasonable view when looked at in the short term. And yes, many capitalists only look in the short term, but that is to their detriment.
Any rational view of capitalism realizes that there is a limit to 'screw everything' profit, and the more people you screw, the sooner your profitable days will be over. Simple math: if you take advantage of a customer base, then that population has less money to buy your products the next year. Any genius who really wants to maximize profits learns fast that happy people are more likely to spend money than miserable people.
And any genius who has made all the money he wants and now craves public approval has all the incentive in the world to be a do-gooder. Unfortunately, they are too easily duped by activists of this or that stripe :(.
That is actually not a bad tactic at all, but first you just want to ask a few questions about why the bill is so high. You would be amazed at how often these things are negotiable. Just about every time I have raised questions with a hospital about some ridiculous cost (like $15 for a Tylenol or whatever) the hospital has revised the bill considerably.
It's not really fine. Well, sort of. The health care system has major problems because no one can really afford it without insurance. In fact, if you try and purchase medical care, the hospital will charge you more than they would charge an insurance company.
Not in my experience *at all*. I have been cruising without insurance for the better part of the past 10 years (and yes, with a family). What I have found is that doctors and hospitals are so frustrated with the insurance scamdustry that they will bend over backwards to work a straight deal. Also, they will gladly work out long-term payment plans, sometimes even interest-free.
I paid the hospital $4000, and our doctor $1400 at the birth of our last child. Yes, that was painful, but considering that insurance for a self-employed father of 3 will be at least $1200-1500/mo it was the better choice.
Do I want to be without insurance? No, but from here on out, the only insurance I will ever purchase is for 'catastrophic' events. That was the original idea of insurance, not as an agent to 'pay' for all ongoing costs.
Insurance and high finance are the two greatest scams going in America right now, and they can get away with it precisely because they have our political ruling class in their pockets. Time to starve the beast.
I wish more developers understood this.
SQL is the perfect example of how a temporary hack becomes a standard that exists well beyond the original intention of the developers.
Read Hugh Darwen's "The Askew Wall" and "The Importance of Column Names" for a couple teeth-grinding examples of how needlessly screwed up this language is.
In fact, the language itself forces a suboptimal implementation of relational databases at the lower level. For one simple example, allowing for duplicate rows of necessity means storing more data than is needed, and not allowing for certain back-end optimizations. Another insanity is the need to preserve column ordering, and even allow for duplicate column names in query output.
Unfortunately, rather than fix SQL at the core, we get tons of additional features jammed into the SQL standard, many of which are contradictory to the relational model, and which often force 'implementation showing through in the interface'.
RPF: Rabit Postgres Fanbois.
Honestly, the more rabid and on-the-offense a community gets, the more a am suspicious of the product.
Why be suspicious? It's pretty easy to get actual knowledge of what the product does without regard to fanbois or flamers. I don't make any choices for or against a product based on that. Also, if you browse the PostgreSQL mail lists, I think you'll see very little rabid-ness. You *will* see an intense dedication to quality, especially if you read the core developers' lists. Quite interesting discussions, there.
Anyway, isn't it just a little disingenuous to come to a PostgreSQL thread, and then accuse PostgreSQL supporters of being rabid? When something cool and new and shiny comes out in your favorite [whatever], don't you tend to get a little exuberant? Let them have their fun, and save the that stuff for a MySQL-vs-PostgreSQL thread.
Not one of these features is remotely compelling enough to switch an existing, working app from MySQL.
Maybe not the new features, but all the good features that PostgreSQL already had were plenty reason for me to switch my MySQL apps. I suppose it depends on your definition of 'working'. I found that modeling and enforcing constraints in application code instead of in the database was becoming prohibitive for any application of decent complexity. Of course, I know that there are two camps on that issue, and the OOP/Framework crowd (Ruby on Rails, DJango, etc...) tend to take the philosophy that the database is just a collection of table stores and all the intelligence belongs in the app.
I say "philosophy" rather than "opinion" because the difference deserves more respect. My meta-philosophy is that there are apps which work well that way, but there are many scenarios where database-oriented constraints provide much better long-term quality assurance.
Thanks!
Relational programming sounds interesting. Do you have any links or examples?
For shell scripts, all you need is php -c /path/to/alternative/php.ini
You can have as many alternate configurations as you want.
Honestly, if something seems like an obvious thing to want, chances are you just haven't looked hard enough to find it.
No, you're missing the point. You are mistaking the concept for the implementation. Relational database management systems are a concept (well, a combination of concepts), and they can be implemented any way you want at the physical level. Most of the perceived problems with 'relational databases' are really problems with how SQL systems are implemented. It doesn't matter what storage mechanisms you have. As long as the *front end* (or API, or querying interface) allows you to express your instructions and receive results via declarative set logic rather than hierarchical navigation, then you have a relational database management system.
In my case, I really didn't START to like Javascript until I began to read up on it's functional capabilities.
I think there is more to Javascript's popularity than what you say. It is actually a fairly nice little language, and hopefully when a few annoyances are cleaned up in version 2.0 it will be used outside the browser more and more. In fact, anyone who has done some serious Mozilla application programming with XUL realizes that there is no reason Javascript must be restrained to a web browser context to be useful.
Yes, what suckage. Who on earth wants a simple, dynamic, low-cruft language with first-class functions, closures, lambdas and a prototype object system that still manages to look like the C language family? Evil, evil, evil...
Note: I don't consider myself enough of a language expert to judge your first assertion, but your second assertion makes me strongly suspect the first. That you would claim Brendan Eich has no business being associated with language design doesn't exactly help your case.
The only problem is that JavaScript/ECMAScript from a language point of view isn't really good. A strongly statically typed script language would have been better since it would have allowed the developers to catch a lot of bugs that now occasionally blows up in the face of the users.
That would be the worst possible thing to happen to Javascript. I know, I know... let's not get into a religious war over static/dynamic typing. There are valid points for each in different contexts, but a language in Javascript's problem domain is probably one of the worst contexts for static typing.
Keeping the language small, clean and simple should be the priorities. If you want Java in the browser, well... that's already available.
Fair enough indeed.
Unwritten Slashdot rule #442: every discussion on PHP ends up on the most tangential matters.
Umm... So because I know how to use object-oriented languages, I don't understand relational logic? I'm rather surprised to hear that.
Nowhere in my comments did I say that I "dislike relational logic". I do, however, think that building large applications in sql is a terrible idea.
A little touchy, are we? Notice I never said anything negative about OOP (although I share some of Tablizer's doubts). Nor did I even imply you were one of "most programmers".
About your analogy, well, that's just fucked. I don't think that using a declarative language to build applications is "not programming". I think that it is not productive (as does the rest of world).
The analogy is very apt, when you think about the power of abstraction. What TCP/IP did was to create a declarative abstraction that was layered over the old world of networking (the old idea of networking was that a connection == a phone call), and this abstraction made it possible to no longer worry about the intimate details of just how your connection established a path through the telco machinery. Take a look at Van Jacobsen's excellent talk for more background on this, including the social aspects I mentioned.
In the same way, relational logic made it possible to make logical assertions over your data without worrying about just how the underlying programming handled the details. Yes, it uses programming, and uses it brilliantly. Separation of concerns. Write a data management framework once, formalize it and generalize it (ergo the DBMS), rather than write it for every application.
I know I know, the balls I must have to suggest that you use your query language for queries. I've apparently drunk the "not writing everything in an incomplete language" kool-aid.
You made the assumption that because I defended object-oriented programming (controversial, I admit), I don't understand how to design a db schema. That's insane (and illogical).
I wasn't assuming anything about you at all. I was responding to Tablizer. But anyway, of course you can't completely develop an application with SQL, nor was that the intent (and SQL is a fairly poor implementation of the relational model anyway). But you CAN manage the data completely within a relational system, and leave the programming to handle all the other aspects. This provides a benefit of separating concerns, so you can manage your data without poking the innards of your application, and vice-versa.
And yes, it is "most programmers", not all. Most programmers have never been taught what the relational model really is, or what it is good for. Most of them don't even know what a "relation" is. It's one of the most disinformation-heavy subjects on the internet. Unless you have read at least one of C.J. Date's books, as well as perhaps Hugh Darwen, David MgGoveran, maybe Fabian Pascal, etc... you don't really know the relational model. In fact, learning SQL itself is somewhat counterproductive to understanding the relational model. It takes a little work to unlearn the bad concepts.
SQL is a high-level language which can be very powerful, reducing the need to hand-code collection-oriented idioms over and over. Perhaps relational-heads think differently than OOP-heads.
I think the separation goes more like "most programmers" vs. "Relational-heads". Most programmers seem to regard such a thing as "not really programming", just like the Big Telcom engineers blustered about TCP/IP as being "not really networking" back in the 60s and 70s. I am convinced that most programmers dislike relational logic because it involves a changed mindset, and because it actually removes the need for some of the things they like to have their hands on.
I can't tell you the number of times I have come across some elaborate construct in an application that could be reduced to a simple combination of a couple tables and a some constraints or rules to govern what goes in them. But that's not really programming...
Agreed. If I have to do OO, Ruby is about the nicest way of doing it. And Javascript (1.7, 1.8), perhaps. Unfortunately, Ruby still has some serious performance problems to address, and while there have been a few attempts at mod_js for serverside Javascript, at present there is nothing definitive.
Well, with PHP 5.3 (alpha), they are starting to do some things that interest me again. They finally added closures and lambda functions, which are two major ways to get some of the advantages of OO without all the boilerplate. (In fact, some would go so far as to say OO was a poor workaround to lack of Functional capabilities in some languages)
Namespaces are back, also, so you don't have to spend so much time worrying about name collision in functions.
Mod parent up please. Parent of parent needs to read just a little about Misesian vs. Keynesian economics. Libertarians assert that one of the primary purposes of government is to enforce contractual obligations, and by no means to encourage malfeasance or bail out bad decisions by businesses at taxpayer expense. The subprime scandal, (combined with inflation) is a perfect example of government using business and economics as a tool of social change, and of how that inevitably blows up in society's face. Of course, it is also a prime example of big business being complicit in raping the public. Modern big business is closer to being a wing of government than a member of the free market, anyway.
PostgreSQL and Ron Paul...
The best are never the most popular. But who wants to be average?
Etc... and much more of this, so we had to hit scroll lock and review several pages worth of screen. And of course the other user's graphical interface had nothing to do with this, since all we were getting was keystrokes directly from the keyboard.
And yes, I did see this with my own eyes, and I've been working with Linux and Unix systems for nigh on 10 years now. The other person in the story had been doing serious Unix systems stuff for close to 20 years, so yes, this is credible.
In our development dept., one guy used a wireless Logitech keyboard to set up his test FreeBSD box, then left the box on for the next couple days without checking (he did log out, though). Next time we looked at it, the screen was covered with login passwords, chat discussions, company memos, etc... We fairly freaked for a minute, then after a bit of quick reconnaissance, discovered that the company's sales director was also using the same keyboard in an office 3 rooms over. So somehow not only did these two keyboards happen to have the same encryption key, but the signal went through 3 walls and 30 ft of space to reach our console. We stopped using wireless anything after that.