On program engineering.
Posted: 2002-09-23 03:47pm
To add depth to the shallow confusion on a favorite topic of alledgely computer-knowledgeable people, lets talk about XML, data transfers, exstensibility vs. practicality, and metadata in different forms.
To most people, XML is the ultimate technology, formless, yet useful in a endless configurable way. XML is like the sand at the beach, you can build it into anything you want, like a castle, a car, a home, or even a sand man with enough effort. Its just time consuming, and quite frankly inpractical as the project grows, both in size and scope.
Talk of SOAP/WSDL, XML based transmission protocols as the keys to interconnectibility between disperete systems is a bit hyperoble. Most meaningful transfers of data occur in XML data documents itself, the wrapper of communication is not really that important, as long as its aggreeded upon by everyone. So XML is just as usless as any other protocol i people don't aggree on the syntax of the language, and them hard code into the program.
There are those that argue, that it will lead to the truely extensible programming model, entire programs defined in an XML document using advanced self building routines based on something called "reflection".
Please excuse me for a moment while I laugh. Look I got a program that needs to clear, and I don't need to universally define a program in textual metadata, I need it in some real programing language doing what I want it do --- namely doing something. If I want cross platform capacity, I will do it perl or java. I think people are missing the point. what they really want to do is turn data files into programs, and they are probably forgeting that programs themselves are simply data files for the operating system, or the hardware itself. So we already have and use a broad range of extremely extensible metadata tools. what does taking it to nth degree of abstraction really bring us?
An object oriented programming proccess going crazy?
Programmers are idea people. They take an idea (concept) and as it becomes more abstract, they fall in love with it, because for some twisted reason as Abstraction appraoches infinity, programmer love grows, but at the same time the practical usefullness of such capacities grows smaller, becasue at one point or another, you have to hardcode what you want ito do, or how you want things to work into the program.
Missing the forest for the trees
The task you want the program to do is the forest, the trees are how you do it. Unfortuneately most programmers look at it the other way around. They want to figure out how they want to do something before figuring out what they want to do. THIS IS A HUGE MISTAKE!! Programmers are paid to create programs to do tasks, how you do it should be the most effecient utilization of resources at hand. Getting the most bang for the buck in other words. thats how they can afford to pay you, and turn a profit.
Object Oriented Programming is Independent of Whether its an Object Oriented Language
I can write a Object Oriented (OO) program in C, and write a structured program in C++. OO Design is a methodology in how you do things, not the tools on hand. OO languages just make it easier to code in a OO manner. However again, people mistake the forest for the trees. The view the tools the implement something equal to how it is actually implemented. As long as it is poorly coded, the program is not going to be very changeable, or modifiabe in any language. Good programing style and effiecent use of resources is key to whether a program is good or not. Remeber Cost per CPU cycle AND time to market (or internal use) is key to successful coding. The fewer Cycles that it takes to proccess data, the more data a program can handle.
Another Approach
Here is a typical definition file for WSDL in a simple transaction.
(I don't work with XML much anymore, so I might get some types wrong as to its compliance to defined data types, really just pseudo code)
Why does it have to be more than this?
To Hell With Engineering!!
Techonlogy changes all the time, unless you are in the need of a truely generically engineered application, just doing it the simplest way is the way to go. The only place that I always demand that be designed OO is the database. If it isn't designed OO or relationally, your data could get "stuck", and many times you can't really engineer your way out of that.
My point of view, for internal use, and taken with a grain of salt. My way is about cost effectivenes, not so much about making upgrades to the code base, except for additions. If you are designing something for mass consumption, and doesn't need to parse allot of data, XML may be the way to go.
To most people, XML is the ultimate technology, formless, yet useful in a endless configurable way. XML is like the sand at the beach, you can build it into anything you want, like a castle, a car, a home, or even a sand man with enough effort. Its just time consuming, and quite frankly inpractical as the project grows, both in size and scope.
Talk of SOAP/WSDL, XML based transmission protocols as the keys to interconnectibility between disperete systems is a bit hyperoble. Most meaningful transfers of data occur in XML data documents itself, the wrapper of communication is not really that important, as long as its aggreeded upon by everyone. So XML is just as usless as any other protocol i people don't aggree on the syntax of the language, and them hard code into the program.
There are those that argue, that it will lead to the truely extensible programming model, entire programs defined in an XML document using advanced self building routines based on something called "reflection".
Please excuse me for a moment while I laugh. Look I got a program that needs to clear, and I don't need to universally define a program in textual metadata, I need it in some real programing language doing what I want it do --- namely doing something. If I want cross platform capacity, I will do it perl or java. I think people are missing the point. what they really want to do is turn data files into programs, and they are probably forgeting that programs themselves are simply data files for the operating system, or the hardware itself. So we already have and use a broad range of extremely extensible metadata tools. what does taking it to nth degree of abstraction really bring us?
An object oriented programming proccess going crazy?
Programmers are idea people. They take an idea (concept) and as it becomes more abstract, they fall in love with it, because for some twisted reason as Abstraction appraoches infinity, programmer love grows, but at the same time the practical usefullness of such capacities grows smaller, becasue at one point or another, you have to hardcode what you want ito do, or how you want things to work into the program.
Missing the forest for the trees
The task you want the program to do is the forest, the trees are how you do it. Unfortuneately most programmers look at it the other way around. They want to figure out how they want to do something before figuring out what they want to do. THIS IS A HUGE MISTAKE!! Programmers are paid to create programs to do tasks, how you do it should be the most effecient utilization of resources at hand. Getting the most bang for the buck in other words. thats how they can afford to pay you, and turn a profit.
Object Oriented Programming is Independent of Whether its an Object Oriented Language
I can write a Object Oriented (OO) program in C, and write a structured program in C++. OO Design is a methodology in how you do things, not the tools on hand. OO languages just make it easier to code in a OO manner. However again, people mistake the forest for the trees. The view the tools the implement something equal to how it is actually implemented. As long as it is poorly coded, the program is not going to be very changeable, or modifiabe in any language. Good programing style and effiecent use of resources is key to whether a program is good or not. Remeber Cost per CPU cycle AND time to market (or internal use) is key to successful coding. The fewer Cycles that it takes to proccess data, the more data a program can handle.
Another Approach
Here is a typical definition file for WSDL in a simple transaction.
(I don't work with XML much anymore, so I might get some types wrong as to its compliance to defined data types, really just pseudo code)
Code: Select all
<? xml version='1.0' ?>
<sellOrder:customerTransaction xlns='http://www.myBiz.com/data.xsd'>
<user:customerAuthentication name='string' password='string' />
<usertransaction:transactionOrder>
<userStock:objectStock stockID='int' />
<userSalePrice:transactionPrice price='float' />
<userQuantity:transactionQuantity quantity='int' />
<userAccount:objectAccount number='string' />
</user>
</sellOrder>
Code: Select all
//type tag | User Name | Password | Account # | Stock ID | Price | Quantity
@152|<string>|<string>|<int>|<int>|<float>|<int>
Techonlogy changes all the time, unless you are in the need of a truely generically engineered application, just doing it the simplest way is the way to go. The only place that I always demand that be designed OO is the database. If it isn't designed OO or relationally, your data could get "stuck", and many times you can't really engineer your way out of that.
My point of view, for internal use, and taken with a grain of salt. My way is about cost effectivenes, not so much about making upgrades to the code base, except for additions. If you are designing something for mass consumption, and doesn't need to parse allot of data, XML may be the way to go.
I won't even bother,