Ada is my first love, and it's been my primary language since 1985. Unfortunately, nobody has wanted systems built in Ada since the 1980s, so I've had to settle for Ada dialects such as PL/SQL and PL/pgSQL.I've had to code in the more modern languages as well, and given the contributions these languages make to project failures, I'm firmly of the opinion that if you want a large system built to last, build it in Ada.
A few months back I posted a question in a couple Linux forums to the effect that:
I can get some of my non- and semi-technical clients to install Linux on their laptops, but they'd be stopped dead by the lack of drivers for Broadcom wireless cards. Is there a distro or method that a non-techie can use?
What I got back was answers which are what I've done myself, but which would be gibberish to most non-Unix people and especially non-techies. That's extremely annoying to an open source advocate.
Last year I had a corporate client ask me if it was feasible for them to switch desktops from Windows to Linux, and I had to tell them they could not do it without doubling their IT staff. Some of that was minor but unavoidable stuff like finding OpenOffice menus, but the killer was installation woes, all of which are avoidable if we start accepting that we're no longer a club of hobbyists.
By way of introduction, I was a Booch disciple in the 80s who learned the hard way the limits of OOD. Nowadays I'm a database architect working in UDB, Oracle and PostgreSQL, basically because that is what people pay for, not because I have an ideological bias.
There are several reasons why almost everybody who has studied the issue picked RDMBSs:
Speed - there is no way you can interact with an object store within an order of magnitude of the speed of an RDBMS query. The extra runtime checking and specialized data types slow you down. You might fix the second factor by having standard, simple data types, but that puts you back in relational territory.
Query capability - almost all data intensive applications work on large sets of data; OO has real trouble working above the level of a single instantiation. Imagine how you would say "total all invoice line items for part number 9999 and subtotal by region" in your favorite OOP environment and you'll see what I mean.
What I came to understand about OO is that while it can be applied to any problem domain, its practical problem domain is making programmers more effective. Now this is a practical, not theoretical limitation; at some point someone will invent a DBMS that is an RDBMS and an ODBMS (no, I'm not talking about Object-Relational DBMSs), and we'll all be happy. Oracle is drifting in that direction, and sonner or later they'll get there.
Now, there are database problem domains that are good fits for ODBMSs. For example, sharing medical records across doctors' offices. No one office would have a lot of data, and privacy issues would make it unusual to query all the data at once. My experience, though, is that there are almost no database problem domains that work at the single instantiation level.
Slashdot Mirror
Ada is my first love, and it's been my primary language since 1985. Unfortunately, nobody has wanted systems built in Ada since the 1980s, so I've had to settle for Ada dialects such as PL/SQL and PL/pgSQL.I've had to code in the more modern languages as well, and given the contributions these languages make to project failures, I'm firmly of the opinion that if you want a large system built to last, build it in Ada.
A few months back I posted a question in a couple Linux forums to the effect that:
I can get some of my non- and semi-technical clients to install Linux on their laptops, but they'd be stopped dead by the lack of drivers for Broadcom wireless cards. Is there a distro or method that a non-techie can use?
What I got back was answers which are what I've done myself, but which would be gibberish to most non-Unix people and especially non-techies. That's extremely annoying to an open source advocate.
Last year I had a corporate client ask me if it was feasible for them to switch desktops from Windows to Linux, and I had to tell them they could not do it without doubling their IT staff. Some of that was minor but unavoidable stuff like finding OpenOffice menus, but the killer was installation woes, all of which are avoidable if we start accepting that we're no longer a club of hobbyists.
http://en.wikipedia.org/wiki/Asperger%27s_Syndrome ...and a professional organization:
http://www.aspergia.com/
I bet a quarter to a half of the posters qualify...
By way of introduction, I was a Booch disciple in the 80s who learned the hard way the limits of OOD. Nowadays I'm a database architect working in UDB, Oracle and PostgreSQL, basically because that is what people pay for, not because I have an ideological bias. There are several reasons why almost everybody who has studied the issue picked RDMBSs: Speed - there is no way you can interact with an object store within an order of magnitude of the speed of an RDBMS query. The extra runtime checking and specialized data types slow you down. You might fix the second factor by having standard, simple data types, but that puts you back in relational territory. Query capability - almost all data intensive applications work on large sets of data; OO has real trouble working above the level of a single instantiation. Imagine how you would say "total all invoice line items for part number 9999 and subtotal by region" in your favorite OOP environment and you'll see what I mean. What I came to understand about OO is that while it can be applied to any problem domain, its practical problem domain is making programmers more effective. Now this is a practical, not theoretical limitation; at some point someone will invent a DBMS that is an RDBMS and an ODBMS (no, I'm not talking about Object-Relational DBMSs), and we'll all be happy. Oracle is drifting in that direction, and sonner or later they'll get there. Now, there are database problem domains that are good fits for ODBMSs. For example, sharing medical records across doctors' offices. No one office would have a lot of data, and privacy issues would make it unusual to query all the data at once. My experience, though, is that there are almost no database problem domains that work at the single instantiation level.