Once the software needs to evolve the point will be moot.
Depends on the system and the need to evolve. If you are using RAD software for the screens and the evolution is just new fields, then it can evolve just fine. If you have to do real business logic and other complex processing, then you get an advantage and motivation for OO.
And, it isn't that I disagree on tending to prefer OO for the general solution in the transaction processing space ... I do have a certain reputation as an evangelist, after all. I just have a problem with people complaining about OO not doing a particular thing well and then considering this a condemnation of OO for everything.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
abevoelker wrote:Truthfully, I probably only sound like some OO nut because I'm surrounded by people daily who aren't even convinced that OO is useful in any case, so I am constantly defending it / trying to teach it. It might just be my own sensitivity to the issue, but I felt like I was detecting some of that on these forums as well. I've got my own incendiary opinions about the types of programmers that ABL breeds/sustains, but I don't have the energy to go there.
Truthfully, I probably only sound like some OO nut because I'm surrounded by people daily who aren't even convinced that OO is useful in any case, so I am constantly defending it / trying to teach it. It might just be my own sensitivity to the issue, but I felt like I was detecting some of that on these forums as well. I've got my own incendiary opinions about the types of programmers that ABL breeds/sustains, but I don't have the energy to go there.
We all learn/teach one another. Isnt it? Just, the way you thinging is too idealistics.
Programming isnt art, it is engineering. We have tasks to solve and tools to use, and we are restricted by them. We can change a tool but always there are "+" and "-".
Progress from the begining has strong side - good integration of db and bussiness layers. If you choose best BL tool - Java for example, and best DB tool - Oracle, for example, it doesnt create best tool for both layers. Because layer intergation is essential component too. If we add presentation layer we will have 5 components as total. Mixing of tools always slow down develepment cycle, just because you have to spend a lot of time to learn each tool and make them work together.
This year i've worked on web project. My choice for presentation layers was Flex. It is OO tool with 1000+ easy to use classes. All other 4 compoments (2 bridges and db + BL layers I used were from Progress). Flex has a lot async interfaces and my choice was WebService. I have spent a lot of time for intergration. It is not just sending queries and mapping results to forms or browsers. Total work imcluded also web server setup/tomcat setup/wsa setup/wsa deploy/app server setup/reogranisation on BL layer (ABL code) to face new interface. On flex part it also included mapping data to Progress datatypes, and my BL datatypes.
Yes, it is "modern" architecture and works even on my htc desire, but it really takes a lot of time especially if there are no white papers on topic.
Programming isnt art, it is engineering.
Your programs might be bolt together assemblies, but mine aren't.
Seriously, through, programming is a mix of science, engineering, and art. There is no way that decisions made in programming are all driven by mechanical rules. Art has rules too and artists must be careful about when to break them or they simply produce bad art.
What makes Java "best" when it comes to BL for intense transaction processing applications. You know what language actually dominates for these applications? COBOL.
What makes Oracle best for the DB? Because you need to buy more iron to support any given load? Because you need a full time DBA for even a small site? These are marks of goodness?
The white papers mean that it takes more time?