A recent thread triggered me to think about OOP and its place within software development. Though OOP of course is something that has proven its tremendous value in software development in the last two decades, I personally get the impression that there is too much emphasis on the OO aspect of programming languages and that the level off OO is an indicator of the quality of the development tool.

However, such thinking totally ignores the fact that there is no standardized way of handling data in an OO way. There is nothing OO to SQL. Stored procedures and user defined functions are characteristics of a procedural language. Though about 10 years ago OO databases where the buzz on the street, nowadays they seem further from being used in mainstream development than ever.

Speaking of databases, that also has some holy wars to it. I remember some discussions here in the past about comparing SQL server and VFP databases. Though SQL server is a robust and very usefull RDBMS, it by no means is the answer to all data related problems. Being blamed more than once for being too theoretical rather than having actual experience, let me explain this with a simple example:

There are two different ways to access data: 'Record oriented' and 'set oriented'. The first databases were record oriented, often called hierarchical databases, meaning that the database is optimized to handle individual records. Its implementation is often depended on the physical storage of records. The set oriented technique is younger and developped by EF codd in the 70's. It is much more concerned about retrieving sets of data from the database and its exposed scheme should be detached from its physical implementation as much as possible,

Though many do not realise, every computer user use a hierarchical database each and every day. Thats because the file system of any OS in fact is a hierarchical database. Its tremendously fast in looking up individual files, but is terrible in searching a whole set of files through a search function. Though Microsoft in its development of Vista tried to replace the file system with a more set oriented database it utterly failed and had to drop this feature from the actual release. It just did not perform wel enough. Oracle had a simular project, driving a file system on a database, with the same result: Performance was not adequate.


This makes me think of all the discussions up here about strict type (.Net) and dynamic typing (VFP). Lets look at SQL again. Though you indeed must specify the types of variables in functions and procedures, there actually is nothing that checks the type other than at runtime, there is nothing preventing you to change the type of a column if there are stored procedures and UDF stored in the database. All conflicts will be detected at runtime, much like in VFP. I wonder how strict typing would benefit software development in SQL, can it be beneficial or is it going to be a PITA.

Strict type languages will, whether you like it or not, have to deal with dynamically typed situations. Doing a SELECT * FROM myTable will return a set of data with unknown types for the compiler unless using typed datasets, but even in the latter there is no compiletime check and changing the datatypes on the database will not trigger anything in your project at compiletime. The error will have to be catched at runtime.

How simular with using COM objects. Take for example MS office. Though one can use early binding, it binds your program to a specific instance of MS office since the object model and therefor type library of each new version is different in each version. Lets be realistic here, if you develop software that needs to automate MS word, you cannot enforce your client to use a specific version of office. My clients might use office version as old as 10 years and my applications will just work fine. In such situations there is no place for early binding. Late binding is the only alternative in this case. Unfortunately in strict type languages you then will have to workarround the issue that the compiler insist to know the types when accessing anything in the COM object.


I think that we all should realise that each programming paradigm has its place and we should use one over another where it makes sense, but using this as arguments in holy language wars only proves that people tend to be narrow minded and don't realise its place in software development.