This is nothing but bat poo. I'm guessing you are either a manager or an ivory-tower theoretician.
Software development (hacking, programming, coding, software engineering, whatever) is a hard problem. Bits and pieces get easier as new tools and techniques become available, but that just extends our reach. We end up working on harder problems, not just working on the same old problems quicker. It is a specialized kind of problem solving, and the only way to automate it is to have an automaton that is as smart, creative, perverse, disgruntled, persistent, flaky, masochistic, amazing, beatiful, and maddening as the human mind it is replacing.
I am not sure I believe in the existence of "software engineering," but, if I did, I would have to point out that all engineering requires that creative problem-solving approach that appears only in the human mind.
I am sure that you can do everything necessary with the current incarnation of style sheets in MS Word, but I certainly don't find using them straightforward. The last version where I thought style sheets worked the way they should was Word for Dos version 5.
Oh, dear, I'm dating myself again. And it is so much better to date someone else...
As both a programmer and DBA, I am often disgusted by the atrocious way that most programmers treat the database. Joining tables by scan-and-select, naive use of features, bad assumptions, "it's all just rows and columns" thinking, etc. Modern RDBMSs are very sophisticated tools, with many ways to either shoot yourself in the foot or to provide serious value to the application, depending on the sophistication of the programmers.
In some cases, yes, you should keep all or most of your logic in your applications. In others, it makes sense to push some of the logic closer to the data. Like everything in this business, it depends on your goals and constraints.
As for "control-freak DBAs"... If you got blamed every time some idiot screwed up a WHERE clause, you'd be a bit of a control freak, too.
"In general, if a person can read your comment and then figure out how to translate what you said into code, then your comment is pretty good."
That is the programming equivalent of the old pilot's saw: "A good landing is one you walk away from."
I think it is better to set the bar a little higher. Most pilots aim to walk away from a landing AND be able to fly the plane again later.
Likewise, a good goal for comments could be, "Explain this piece of code and its context without insulting the reader's intelligence." Or, maybe, "Ensure that maintainer isn't tempted to change this code without understanding it." Or even, "Tell myself why I did it this way so I'm not tempted to break it next month."
And even worse was a movie based roughly on the ideas in the story. I walked out of the theatre after about fifteen minutes. David Birney (almost as talentless as a Baldwin) as some kind of weird priest, using a hawk to blind a pretty volunteer so she could understand the coming darkness. Or something. I can't remember if Asimov was still alive at the time, but if he was, I suspect this movie killed him. Bleh.
The class of problems that must be serialized is smaller than we tend to think it is.
If you look up some of the old research that Thinking Machines did with the Connection Machine (a hyper-cube architecture; a common configuration was 64K processes in 16K nodes of 4 processors each), one of the surprising results was parsing large program files in logarithmic time.
I do not claim that is a practical result, but I hope that it is enough to make some of us drop our assumptions about whether a given problem is fundamentally serial, with no hope of improving the performance with parallel processing.
Anything Gartner (or any other analyst company) says is bought and paid for by someone.
Ignore them the same way and for the same reasons that you don't watch the shopping channels: They are peddling over-priced garbage that you don't need.
In my work, compatibility with MS file formats is a prime requirement. From that perspective, OOO is a mixed success.
I have received timesheet documents with pretty complex formatting that works just fine. However, the formulas in them are completely broken. Also, I have sometimes been completely unable to open spreadsheets that had write protected some cells.
As for presentations: Forget it. Whether reading files generated by PowerPoint or creating new ones for PowerPoint to open, the chances of success are very small, in my experience. If you have no need for MS users to open your presentations, it works fine.
The word processing files are by far the most compatible, but even so I often see bulleted lists marching off the left side of the page, each line being farther to the left...
>> Software development will never be made reliable and inexpensive until we get rid of the programmers.
This is the same as saying "Law will never be fair and inexpensive until we get rid of the lawyers."
Or "Medicine will never be painless and inexpensive until we get rid of the doctors."
I'm not comparing software development with medicine or law (that's a different discussion), but I believe that software development is a FUNDAMENTALLY HARD PROBLEM. That is, it cannot be completely automated. It requires analysis, problem-solving, creative, mathematical, language-parsing, language-producing, context-matching, common sense, and a raft of other skills.
>>No two programmers will produce a program in exactly the same way.
That's bad if you have four "artisans" crafting fundamentally different wheels for each corner of a car. Is it, however, a bad thing in software development? If you use a linked list and I use an array, which of us has done it wrong?
>>What we need is an easy way to translate analysis directly into code in a reliable way without human intervention.
And who does the analysis? It's those stinking humans again. They do things that no other tool can do, but they don't do anything perfectly.
>>This will give us the consistency and repeatability that translates into reliability and lower cost.
Repeatability is good for making many copies of physical parts. Once you have made one wheel, you still have to make 399,999 more to run a 100,000 cars.
Repeatability in software development? If it's the same problem, you use the same "wheel" 100,000 times.
If it's a different problem, it needs a gear, or an axle, or a submersible pump, and a wheel just won't do.
Slashdot Mirror
This is nothing but bat poo. I'm guessing you are either a manager or an ivory-tower theoretician.
Software development (hacking, programming, coding, software engineering, whatever) is a hard problem. Bits and pieces get easier as new tools and techniques become available, but that just extends our reach. We end up working on harder problems, not just working on the same old problems quicker. It is a specialized kind of problem solving, and the only way to automate it is to have an automaton that is as smart, creative, perverse, disgruntled, persistent, flaky, masochistic, amazing, beatiful, and maddening as the human mind it is replacing.
I am not sure I believe in the existence of "software engineering," but, if I did, I would have to point out that all engineering requires that creative problem-solving approach that appears only in the human mind.
I am sure that you can do everything necessary with the current incarnation of style sheets in MS Word, but I certainly don't find using them straightforward. The last version where I thought style sheets worked the way they should was Word for Dos version 5.
Oh, dear, I'm dating myself again. And it is so much better to date someone else ...
Ha! Poser! I built my own 8K memory expansion card. And a current-loop interface to print to my surplus ASR-33.
Later, I upgraded to a C64. The 8K memory card wasn't much good, but the current loop interface still worked.
Only the most clueless PHBs pay attention to Gartner, the biggest whores in the IT business.
As both a programmer and DBA, I am often disgusted by the atrocious way that most programmers treat the database. Joining tables by scan-and-select, naive use of features, bad assumptions, "it's all just rows and columns" thinking, etc. Modern RDBMSs are very sophisticated tools, with many ways to either shoot yourself in the foot or to provide serious value to the application, depending on the sophistication of the programmers.
In some cases, yes, you should keep all or most of your logic in your applications. In others, it makes sense to push some of the logic closer to the data. Like everything in this business, it depends on your goals and constraints.
As for "control-freak DBAs" ... If you got blamed every time some idiot screwed up a WHERE clause, you'd be a bit of a control freak, too.
"In general, if a person can read your comment and then figure out how to translate what you said into code, then your comment is pretty good."
That is the programming equivalent of the old pilot's saw: "A good landing is one you walk away from."
I think it is better to set the bar a little higher. Most pilots aim to walk away from a landing AND be able to fly the plane again later.
Likewise, a good goal for comments could be, "Explain this piece of code and its context without insulting the reader's intelligence." Or, maybe, "Ensure that maintainer isn't tempted to change this code without understanding it." Or even, "Tell myself why I did it this way so I'm not tempted to break it next month."
And even worse was a movie based roughly on the ideas in the story. I walked out of the theatre after about fifteen minutes. David Birney (almost as talentless as a Baldwin) as some kind of weird priest, using a hawk to blind a pretty volunteer so she could understand the coming darkness. Or something. I can't remember if Asimov was still alive at the time, but if he was, I suspect this movie killed him. Bleh.
The class of problems that must be serialized is smaller than we tend to think it is.
If you look up some of the old research that Thinking Machines did with the Connection Machine (a hyper-cube architecture; a common configuration was 64K processes in 16K nodes of 4 processors each), one of the surprising results was parsing large program files in logarithmic time.
I do not claim that is a practical result, but I hope that it is enough to make some of us drop our assumptions about whether a given problem is fundamentally serial, with no hope of improving the performance with parallel processing.
Anything Gartner (or any other analyst company) says is bought and paid for by someone.
Ignore them the same way and for the same reasons that you don't watch the shopping channels: They are peddling over-priced garbage that you don't need.
In my work, compatibility with MS file formats is a prime requirement. From that perspective, OOO is a mixed success. I have received timesheet documents with pretty complex formatting that works just fine. However, the formulas in them are completely broken. Also, I have sometimes been completely unable to open spreadsheets that had write protected some cells. As for presentations: Forget it. Whether reading files generated by PowerPoint or creating new ones for PowerPoint to open, the chances of success are very small, in my experience. If you have no need for MS users to open your presentations, it works fine. The word processing files are by far the most compatible, but even so I often see bulleted lists marching off the left side of the page, each line being farther to the left ...
This is the same as saying "Law will never be fair and inexpensive until we get rid of the lawyers."
Or "Medicine will never be painless and inexpensive until we get rid of the doctors."
I'm not comparing software development with medicine or law (that's a different discussion), but I believe that software development is a FUNDAMENTALLY HARD PROBLEM. That is, it cannot be completely automated. It requires analysis, problem-solving, creative, mathematical, language-parsing, language-producing, context-matching, common sense, and a raft of other skills.
>>No two programmers will produce a program in exactly the same way.
That's bad if you have four "artisans" crafting fundamentally different wheels for each corner of a car. Is it, however, a bad thing in software development? If you use a linked list and I use an array, which of us has done it wrong?
>>What we need is an easy way to translate analysis directly into code in a reliable way without human intervention.
And who does the analysis? It's those stinking humans again. They do things that no other tool can do, but they don't do anything perfectly.
>>This will give us the consistency and repeatability that translates into reliability and lower cost.
Repeatability is good for making many copies of physical parts. Once you have made one wheel, you still have to make 399,999 more to run a 100,000 cars.
Repeatability in software development? If it's the same problem, you use the same "wheel" 100,000 times.
If it's a different problem, it needs a gear, or an axle, or a submersible pump, and a wheel just won't do.