|
> From: Hans Boldt > > Joe, sorry, but I have a *big* problem with your main contention > that somehow business applications are too complex for OO languages, > and yet a procedural language is just fine. The capabilities of the > typical OO language are clearly much greater than procedural > languages in many areas: Data structuring, interface definition, > modularization, function libraries, etc, etc. To argue that a > problem domain that is somehow too complex for OO can be handled > more easily by a less capable language just goes against plain > common sense, in my humble opinion. Hans, we're just going to have to agree to disagree here. I've written everything from operating systems to ERP applications. I've coded in every language from assembly language to ones I've written myself. On one end of the spectrum, I've programmed an 8259 PIC chip, a level of understanding of operating systems which few programmers ever achieve, while on the other end I am certified in inventory management, which means I understand the application requirements of ERP to a level that most programmers rarely need. I have 20 years of development background, which includes a heavy grounding in OO via Smalltalk, C++ and now some four years of Java. I also have programmed in several procedural languages, and have written literally hundreds of programs, besides being the manager of architecture for what was arguably the single most successful business application package ever written for the IBM midrange. The design decisions I made affected tens of thousands of users over a span of years. With all this experience, I have given you a concrete example (MRP generation) of a situation where OO is not appropriate, and why. Data driven programming such as that required in business applications requires either complex hierarchies or a heavy use of composition combined with lots of branching based on attributes. Inheritance clearly fails in this situation. But composition also fails, because of the sheer complexity of the code. As you move from inheritance to composition, you introduce branching logic, and in effect are coding procedurally within your containing class. Any benefits of OO are lost in that transition. But don't take my word for it. Write a non-trivial business application in OO. I can only surmise that your statements are from a lack of practical experience. The fact that you consider RPG a "less capable" language shows that you haven't yet understood the concept of "the best tool for the job". And it further begs the question why you're on the RPG compiler team, but that's a different issue for a different day. Let me be perfectly clear on this: OO is not fundamentally better than procedural. Just as native access is not fundamentally better (or worse!) than SQL. Each syntax has its proper problem domain (with the possible exception of Visual Basic <grin>). Data-driven business application programming is better suited to procedural code than to pure OO, in my opinion. And that opinion is based on 20 years of development both in application and systems design. If you'd like to argue the point, fine, but please argue with something a little more concrete than the unsubstantiated statement that OO is "more capable" than RPG. Because frankly, Hans, it ain't. Joe
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.