Yes, and it is no coincidence that those who write unreadable code also write unreadable comments. I notice that the more I progressed in programming skill, the less I made comments because I found myself stating the obvious.

When I look back over an old horrible VB program I had to take over maintenance of for awhile I notice that I left quite a few comments of both my changes and existing code, but that most of those comments were just about as esoteric as the code. It's hard to clearly explain the logic behind a twisted mess.

Whenever I review the comments in my latest project I find that there are few and most of them are meta-comments that describe the use of generic objects, typically notes on the business logic, not technical notes.

Our IT staff has the option of wearing a uniform, which is provided by the company for off-site work, and they have taken to wearing it Monday-Friday even though it's not required. They do this for the reasons that you mentioned. I don't think your IT staff is going to mind unless they're already harassed by bureaucracy. If that is the case, they'll probably take it as a fascist move. It probably won't do anything to change the atmosphere unless you've got problems with the atmosphere already.

Only partially accurate, but humorous. Most of the best programmers I know started with some form of BASIC, often on C64. The fact that you have to unlearn a lot when migrating to strongly typed lower level languages can actually make your fundamental understanding of the second language stronger. In other words, you have to justify everything new that you learn rather than accepting it as "how it's done."

I would recommend learning with BASIC, but not staying with it for long and taking it with a grain of salt. It's fairly unlikely that anyone would stay with BASIC long anyways.

You don't need complex memory references to take advantage of OO. And the "secret" to OO languages is most definitely not procedural programming. That statement is just absurd. That being said, OO is generally something that developers come to to see the advantages of by getting their hands dirty with procedural programming first. OO is best learned as a solution to design challenges rather than a programming basic. Even though PHP's OO implementation is very weak compared to languages such as Java or C#, I find it a good language to learn OO concepts, partially because of its limitations. Plus a kid can easily deploy/show off his work if he's using a web-based interface. I haven't had much experience with Flash, but from what I've seen the same is true for it also.

I don't feel a personal need to be part of a political party and I'm registered as an independent voter. And yes, if everyone was completely unaffected by large, organized groups composed of their peers and always thought completely independently, then the government most certainly would be better.

However, with two giant, over-powered political groups to contend with on this very matter, I wouldn't have a problem aligning with a coalition of people who shared my primary ideals. I was simply iterating the reasons why the Libertarian Party is not able to be that party.

While I tend toward moderate libertarian ideals myself, this is a great example of why I always end up feeling alienated from the party itself. They always end up harping on legalizing hard drugs, having your own private tank, or some other extremist nonsense, and when they're not doing that they're pulling stuff like this that isn't even in line with their supposed values. There are some brilliant men in the party, but they usually end up taking a back seat to the louder-speaking loonies.

Overrated? If anything it was underrated. It never got that much press and only one low-budget sequel. The only reason you could call it overrated now is because it's become a cult classic of sorts. And sure, the graphics look dated now, but it's still one of the most cohesive open-ended stories I've ever played. The gameplay is an acquired taste, but is very deep and satisfying if you can get into it.

I would have read and participated in this discussion but I was too busy enjoying that NetApp ad in the upper right corner.

As bad as this study is, I'm definitely saving it for the next "Video Games Linked to Violence" debate.

While I completely agree with the point that you are trying to make, which is that the performance is almost certainly due to poorly designed database or at least related to database issues, I disagree with one of the assertions that you made along the way.

I would like to point out that some of us database developers take great pride in the fact that while your statement has a tendency to be true in poorly managed environments, a few of us actually get really good at our job. I come from a C++ system-level coding background and can easily deal with issues like memory fragmentation, but I actually like database programming.

The problem isn't that all the good programmers do system-level coding only; there is a completely different skill set required for database programming, especially if application design is involved. The problem is that expectations for database programmers have not been as established as those for system level developers.

It is rare to find an application developer/database developer that is really good at their job. Most of them are actually trained more toward system-level development. Academia done very little to help the advancement of application development.

It's not the cast-offs of system development that write successful database applications; it is rather those of us that continue to polish our skills, educate ourselves to existing standards and get involved in the creation of new ones that actually can develop high-performance, easily maintainable, and highly functional enterprise solutions. And we do it with in .NET technologies, among others.

The inefficiency to which I am referring is file system design that causes regular fragmentation. Undelete works very inconsistently on well-designed file systems such as HFS because data gets overwritten regularly.

I probably should have said the only reason we can use undelete relatively reliably is inefficient design.

My point is that undeletion is an accidental "feature" of Windows and should not be considered the expected behavior of a file system. Both the Trash Can and Time Machine are explicit implementations of file recovery.

Let's not forget the whole reason that we can undelete from FAT and NTFS disks is because of inefficient design. He treats this as though it's a feature of Windows, but it was actually an accident that you could undelete at all. This is the whole reason that the Mac has a trash can and now Time Machine. When you permanently delete something, it should be gone, not hanging around on the disk unbeknownst to your average user.

My experience concurs with this completely. Being an open-source fan and often contributor, I hated to give in to something like .NET, but honestly it is the most complete development library I've encountered. I've used KDE and MFC also, and find them lacking in both design and power. Visual Studio is also an outstanding IDE.

I have my criticisms (documentation and extensibility), but before using .NET I would have not believed that a proprietary language could grow as actively and efficiently as .NET.