Your comments on SQL are totally out-of-line. <p>SQL Server's outstanding feature is that it "looks things up." In tying many files (tables) together it beats the ISAM form of organization hands down. <p>SQL doesn't look so hot to grey-headed record-by-record coders because they just don't get it! SQL is based on the SELECT set and that means the whole SELECT set. When you jump the shark, you will discover it involves a whole mind-set change. <p>Change: get OVER it! Change or impermanence is always here. And the 3/X folks used to drive that change as they buried Xerox, Honeywell, DEC and HP – mid/main-sized computers. <p>You can go on denying if you want, but the White Elephant just isn't in the room, it fills 95% of the room! That includes OO, .NET and XML. So just get over it! <p>I bet you are one of the whiners that complained that IBM dropped the "Move" operation in Free-Form RPG. To those of you in RPG-Land, the Equals sign (=) is used to move stuff everywhere else and has since FORTRAN days in the 50's. Don't delude yourselves that you can do anything you want from RPG with efficiency or ANY understanding. <p>This article was a shameless extended advertisement for one of the author's overpriced books, intended to lull you into thinking that with a few incremental changes you can operate in the Information as a developer – think again! <p>--John deCoville

Get over it? I don't think Joe would begin to argue (nor did he in this article) that SQL has no value. <p>As you say, SQL operates on 'the whole SELECT set.' That's great when you've got a 'set' of records. However, *business* (aka real world) doesn't always operate on a 'set' of records. Many times things are done one record at a time. If I read the same article correctly, Joe is saying, "When you've got a working function using 'native database access', don't jump ship to rewrite everything into SQL." <p>I love SQL and use it regularly. But I always like to think about when and where I apply any technology.

I appreciate your comments, John, but they seem to be just a little bit misdirected. <p>As TheQuigs points out, I'm not saying SQL is bad. In fact, like him I use SQL all the time... I doubt there's a day that goes by that I don't use it. I'm a big fan of CTEs, in fact, because they're so powerful. <p>My point is that SQL is not a replacement for native access. SQL and native access each have their place: SQL for set-based access and native access for record-at-a-time logic. My issue is not with SQL, but with those who would insist that it must replace all native access. <p>And in fact, with the possible exception of .NET (and that is absolutely a personal preference), I embrace the technologies you name: SQL, OO, XML, all have their place, and I use all of them (I code Java pretty much every day, right alongside RPG). But OO is not a replacement for procedural code and XML is not a replacement for databases or queues. Each is its own technology with its own place. <p>As to being a "whiner" about the MOVE instruction, why yes, I guess I am <grin>. But my issue is not that MOVE is better or worse than EVAL or the simple "=" assignment operator. My point was always that removing MOVE from the /free syntax means that roughly 30-40% of my code won't translate to /free without being carefully checked. If you really want to know my position you can read it here at MCPressOnline: <a href="http://www.mcpressonline.com/mc? This e-mail address is being protected from spam bots, you need JavaScript enabled to view it @.6ae72624">http://www.mcpressonline.com/mc? This e-mail address is being protected from spam bots, you need JavaScript enabled to view it @.6ae72624</a>. <BR>
And if you read through that and consider it whining, then I'm guilty as charged. <p>But I have to admit I'm just a teeny bit confused by the "shameless extended advertisement" remark! Exactly which one of my overpriced books was I promoting? I didn't mention either Eclipse or WDSC in the entire article and those are the topics of my recent books, so I gotta say that if this WAS an advertisement, it wasn't a very good one <smile>. <p>Joe

I haven't laughed this hard in a while. I not only can relate to the TV references (The 'Ted Mcginley' comment nearly put me on the floor) but I've lived through just about all of the technologies mentioned too. <BR>
Thumbs up from the floor!

<p> Re: Get over it comments. <p> I was looking at specs on an open source ERP the other day. They use SQL, but they started with an Oracle SQL programming version. <p> Why? Speed. <p> Business people really don't care what you like. <p> rd

Why thanks, Bill! I'm glad I got a chance to lighten your day. <p>I hope I was clear that I'm really not trying to bash any of these technologies; each has a place. But I find it very silly when someone tells me that if I don't get on Bandwagon A that I'm a dinosaur. Me, I'm kinda proud when I find out that a program I wrote 15 years ago is still doing its job! THAT is some serious return on investment! <p>I'm just a crusty old coot, I guess... <p>Joe <p>P.S. To paraphrase Douglas Adams: I love the whooshing sound buzzwords make as they go flying by (into oblivion).

I think the whole trick with bandwagons is to let the other guy get on first, let it go around the block, and on the return trip see if it is still the same wagon, and if the same guy is still on it. <p>OTOH, in my entire experience, I cannot remember seeing a band on a wagon. There was this one movie with Sonja Henie and the Ritz Brothers, but I think that was a bus not a wagon. <p>Dave

Joe, Your comment about a 15 year old program still running and providing the function it was written to support still today is what this work is really all about. I had a call once from an old client I had not visited in 3 years. They are a small business running an As/400 using an application originally written in COBOL on a 370, where it was migrated to a System/36 and an RPGII component was added. After failing to find software to replace it, this software was migrated to run on the As/400 in a System/36 subsystem. The reason for the call was because the system had IPL over the weekend and after that nothing could be printed. Turns out the system had never been IPL’d during the time the current staff had worked there and they had no concept of the QSYSOPR message queue. All that was needed was to enter “G” to a message. <p>My point is once your write it, that is what you have. My point is how much technology did this business miss. Technology is how things work, but it is not what we do. <p>In the old days, a customer would call the order entry department, who would write the order down and send it to the key punch department. Modernization is developing a system where that customer service person could enter the order into the system directly. There goes the key punch department. Modernization is developing a system where the customer enters the order without calling the customer service person. <p>Using new technology is great, I want to use the best technology available, but having a 15 year old program that still performs it function is “way more cool”. In my opinion, Technology for technology sake is not modernization.

I definitely agree. No real problems with any of the technologies you mentioned. I just laugh at the mindset that you have to jump on board every technological 'latest and greatest' that gets hyped to the forefront. <p>And don't start using Douglas Adams quotes now or I'll probably wet myself. <p>Thanks, Bill

I totally agree with your technical analysis as I have myself programmed in FORTRAN in the 70s. I have been in argument with Joe many times, (especially the MOVE that you mentioned). He was kind enough to enter into the argument with me in the first place. <p>What I do not agree is the language you have used for ol' Joe. I hope I am wrong but I got the impression that you doubted his personal and professional integrity. Please tell me it ain't so.

Joe, bang on. I couldn't have said it better myself. (Curses!) <p>It's been a while since I was a programmer. When I left, client/server was being touted as the technology that absolutely no company could live without. Most of the other technologies you mentioned came in after my programming days, but I agree 100% with the gist of what you said. <p>By pet peeve back when I was a programmer was my fellow programmers who spent hours on end arguing about a relational database's percentage compliance, down to three decimal places, to Codd's rules. What incredible jerks. Yes, relational databases were and are wonderful things, but there are no doubt times when a fully normalized relational database is not be the best choice for a particular requirement. The argument should always be how well the technology serves the business purpose, not how well it serves some theoretical model. <p>Thanks Joe !

Don't get me wrong, I love new technology! I really like to try new things and I'm even occasionally guilty of shoehorning some brand new technique in where it doesn't belong. Typically that infatuation won't last more than a week or two and then often as not I have to go back to the code I wrote and rip out all the "clever" coding ("clever" being my code word for "unnecessarily complex, often due to using the latest technique inappropriately"). <p>But at the end of the day, the value of software is ROI: how much did this program help my bottom line vs. how much did it cost. If I don't have to touch a program for 15 years, that's a whole lot of ROI. <p>You're absolutely right: change "just because" is not advancement. <p>Joe

Funny thing is that the database argument goes on, except that it's gotten to the point where the arguers no longer even understand the argument. I've heard lots of complaints about how DB/2 is not a relational database and yet at last review, there isn't one database today that completely supports Codd's original rules. <p>In fact, neither Codd nor Chris Date (arguably even more influential in the uptake of RDBMSs than Codd himself) liked SQL. Codd thought it was a flawed implementation, and Date flat out hated it (and does to this day). <p>So when the SQL zealots trot out Codd, it's sort of ironic (and just a tiny bit sad). They miss the point: it's not about Codd, it's about the query. <p>Joe

Joe, I couldn't agree with you more. <p>Many people are unaware that Codd model proved unsatisfactory, even to Codd! And on a fundamental level. <p>The concept that eliminated data redundancy was the principle point of concern. <p>And as you point out, for purposes of querying, it is often more convenient to have the data readily available in one place, rather than to go fishing for it. <p>I've always felt that one of the advantages of DB2 was the ability to perform direct reads and writes without having to use SQL. I am not aware of another RDBMS that has that capability. <p>Dave

In my opinion, Dave, I would describe the denormalization for performance reasons, to avoid the overhead of table joins. In other words, just as in many areas of IT philosophical excess, practicality considerations lead to a golden mean of architecture. <p> And if they don't, you have software systems that are unusable. See any government major software development effort since IT became mired in lowest common denominator philosophical zealousness. <p> As far as the direct reads and writes, I have done some searching on this. I saw Microsoft is adding it to their Unified Database Access layer above ODBC where they now have it only in Jet. Microsoft ran into major problems with their Project Green ERP development, which basically would have been to take all four of their ERP packages and rewrite database access in SQL. <p> SAP's paid version of their database has it, and of course as a high performance ERP they would have it. <p> Oracle bought the best small direct read open source database out there, Berkeley, and it is their showcase solution for embedded databases. I will be using it. <p> One interesting thing I found is that MUMPS is a critical core base for very successful health care systems such as the VA has developed, and it hasn't been able to be replaced yet. See failed government software development above, aka Oracle and IBM. <p> rd

Excellent article, Joe. <p>Please consider adding object-relational mapping to the list. It appears that our product managers are being told that they will be able redesign their databases in the future, and it won't have any impact on applications, because Hibernate will make the transition seamless. <p>Nathan.

A new acquaintance of mine, after finding out that I was a coder on an ____ (was as/400), acted surprised. She said that her company had one and that it was so old, with outdated "screens", and it was "so different and unfriendly"; ‘couldn’t believe that I worked down the road a piece programming such an ancient machine. <p>She further said that all the computer folks left the company. They have a local consultant come in every once and a while to make sure things run OK. <p>I asked how big the company was, and she didn't know but did say that they have seven locations nationwide and that receipts are around 2.5 mil per week. I asked what the system was used for—it performs their order entry and inventory functions. <p>Some quick and silent arithmetic told me that here was a local company, bringing in about 100 million in sales annually, and their most critical apps are being run on a system that requires no full-time employees with an uptime is probably so high that nobody pays attention to it. <p>I’m thinking, “This is a BAD THING?” <p>It seems warped to me, but that’s the world we live in. Luckily, we still have some folks left like Joe who can see it and tell it like it is.

This is a discussion about <B>Jumping the Sharks of Technology</b>.<p align='center'><a href=http://www.mcpressonline.com/mc? This e-mail address is being protected from spam bots, you need JavaScript enabled to view it @.6b3a52c0>Click here for the article</a>.</p>

"There are two kinds of fool. One says, 'This is old, and therefore good.' And one says, 'This is new, and therefore better.' <BR>
The Shockwave Rider -- John Brunner