Programming Trends to Follow?

[aggle-rithm]

As software development matures as a discipline, and as more and more solutions appear to address various problems, I find myself torn between an ugly plethora of choices. I read up on the latest developments, and am constantly told "this is the next big thing!" It's something everyone is doing, all the jobs require this knowledge, etc., etc.

However, I know for a fact that yesterday's "next big thing" is often today's "what were we thinking?" When I first started working as a developer, Rapid Application Development (RAD) was the biggest thing since sliced bread; today, it is a stupid idea that we wasted too much time on ten years ago.

On the other hand, there is a serious problem with ignoring all the new trends and just sticking with what you know. That's what I did the first five years or so of my career, and I found myself seriously behind the times. Certain aspects of Agile development, Extreme Programming (XP), test-driven development, and domain-driven design have become essential tools for me in the last few years; none of this was taught in school.

Today the next big things are "the Cloud" (whatever that is), and dynamic programming languages like Ruby. There is still no universal development strategy for the Web. Even if you stick with Microsoft, you have to decide amongst ASP.Net, MVC, WebMatrix, Silverlight, and other technologies. After twenty years of the World Wide Web, you'd have thought they would have figured out how to develop for it by now.

At the same time, there are many people arguing that some tried and true technologies are dead and shouldn't be bothered with. C/C++, Java, PHP...these are platforms whose time has passed, according to some prognosticators, even though they are still dominant forces in the programming world.

Given that a single person can only learn a limited portion of what's out there, and we have no idea what's going to actually be used an three years...how does one choose what to focus on today?

[aggle-rithm]

Just a hint of what might be the key to sorting all this out...if it supports an established principle of programming that has been around for decades, then it will probably be successful in the long run. That's why I think it's better to focus on MVC than some of the other Microsoft offerings, because it's actually a quite old technology that's never had a suitable platform available until recently.

It's not simply that it's "old", it's also that it is based on very solid principles of software development.

[TjW]

As I understand it, "The Cloud" is putting your data on other people's computers, so that you don't have to worry about it.
For some reason, this worries me.

[aggle-rithm]

As I understand it, "The Cloud" is putting your data on other people's computers, so that you don't have to worry about it.
For some reason, this worries me.

That's one definition. It's also used to describe software-as-a-service. At one point, Dell defined "the Cloud" as a class of servers.

In my mind, if the industry cannot agree on what a certain buzzword is, then that buzzword is not something you should waste your time on.

But I could be wrong.

[arthwollipot]

'Cloud' is basically online storage. Dropbox, essentially. Google Docs. Save online and you can access your data anywhere.

[The Central Scrutinizer]

As software development matures as a discipline, and as more and more solutions appear to address various problems, I find myself torn between an ugly plethora of choices. I read up on the latest developments, and am constantly told "this is the next big thing!" It's something everyone is doing, all the jobs require this knowledge, etc., etc.

However, I know for a fact that yesterday's "next big thing" is often today's "what were we thinking?" When I first started working as a developer, Rapid Application Development (RAD) was the biggest thing since sliced bread; today, it is a stupid idea that we wasted too much time on ten years ago.

On the other hand, there is a serious problem with ignoring all the new trends and just sticking with what you know. That's what I did the first five years or so of my career, and I found myself seriously behind the times. Certain aspects of Agile development, Extreme Programming (XP), test-driven development, and domain-driven design have become essential tools for me in the last few years; none of this was taught in school.

Today the next big things are "the Cloud" (whatever that is), and dynamic programming languages like Ruby. There is still no universal development strategy for the Web. Even if you stick with Microsoft, you have to decide amongst ASP.Net, MVC, WebMatrix, Silverlight, and other technologies. After twenty years of the World Wide Web, you'd have thought they would have figured out how to develop for it by now.

At the same time, there are many people arguing that some tried and true technologies are dead and shouldn't be bothered with. C/C++, Java, PHP...these are platforms whose time has passed, according to some prognosticators, even though they are still dominant forces in the programming world.

Given that a single person can only learn a limited portion of what's out there, and we have no idea what's going to actually be used an three years...how does one choose what to focus on today?

Change a few of the names, and this exact post could have been written anytime during the last 50 years.

How does one choose? The one that pays the highest rates.

[aggle-rithm]

'Cloud' is basically online storage. Dropbox, essentially. Google Docs. Save online and you can access your data anywhere.

It includes Software as a Service, though. This is the part that is more difficult for the average consumer to understand, so Microsoft is marketing "the cloud" as, essentially, online storage.

Maybe that's what it will end up being. .Net was originally more than just a software development platform, but that's all it is today.

[aggle-rithm]

Change a few of the names, and this exact post could have been written anytime during the last 50 years.

How does one choose? The one that pays the highest rates.

COBOL once paid the highest rates.

Then it paid nothing, because no one needs outdated technology.

(Although I recently heard of an outfit that uses COBOL to render HTML. Why, I'll never know.)

[The Central Scrutinizer]

COBOL once paid the highest rates.

Then it paid nothing, because no one needs outdated technology.

(Although I recently heard of an outfit that uses COBOL to render HTML. Why, I'll never know.)

Exactly. Which is why I suggested going with what pays the highest rates, then when that changes, move on to the next thing. Or you can try to guess, and maybe pick the wrong technology to follow.

[JWideman]

It works both ways. Java was considered a fad, now it's the new C++.

[aggle-rithm]

It works both ways. Java was considered a fad, now it's the new C++.

Interestingly, both Ruby and C++ developers say Java should be avoided. Ruby developers because Java is old-fashioned, C++ developers because it is slow (although not as slow as Ruby).

[Wowbagger]

Given that a single person can only learn a limited portion of what's out there, and we have no idea what's going to actually be used an three years...how does one choose what to focus on today?
Have you ever attended a developer's tradeshow or convention or expo? Attending these things, every now and then, will give you a good flavor of what is on the horizon. Which technologies are slick and will stick, and which ones are inherently weak and flimsy.

I find them to be more revealing, in this area, than magazines, book store browsing, or Internet articles. The tech demos are often right there to evaluate, with experts to answer questions standing by.


Certain aspects of Agile development, Extreme Programming (XP), test-driven development, and domain-driven design have become essential tools for me in the last few years; none of this was taught in school.Welcome to the real world.

This sort of thing happens in any profession, though I suspect that it is especially rapid in software development.

As long as one is always willing to learn, and keep tabs with what is going on, one will always be on the path to being a good developer.

You do not have to go it alone. Trade shows also present good opportunities for networking.

Today the next big things are "the Cloud" (whatever that is), The Cloud is more of a hosting strategy, than a development platform. True, it does require thinking about your application from a more distributed, service-oriented point of view. But, your choice of "cloud" or not is independent of which platform and languages you will be developing on.

I believe the concept of The Cloud will be around for a good long time. However, its usefulness is probably being oversold, at the moment. There could be a Cloud Backlash in the near future. But then it will slowly ramp up in popularity, again, once we get the knack for what it is truly useful for.

I am not, however, a cloud developer myself, yet. So, what do I know?

and dynamic programming languages like Ruby.And here I thought Ruby was on the way out, due in part to performance concerns. Well, again, what do I know?

There is still no universal development strategy for the Web. Nor should we expect there to ever be one. That is the nature of the web. The only thing its servers have to share is the TCP/IP protocol. (and even that is changing from v4 to v6). Everything else is open to whatever anyone happens to stuff into any servers that can use the protocol.

Even if you stick with Microsoft, you have to decide amongst ASP.Net, MVC, WebMatrix, Silverlight, and other technologies. First of all, WebMatrix is a management and coding tool, not a platform. You might have been thinking about Razor syntax.

And, Silverlight is of limited use on the Web.

If you choose to be a Microsoft-based web developer, (as I am) you ought to learn all three: Razor, Conventional ASP.NET, and ASP.NET MVC. Many skills are largely transferable between them, including the syntax and semantics of the languages. The size of the site might determine which you should consider using. But, so will whatever teams you happen to be working with, if any.

Silverlight is good for two things on the Web: Video playing (at least until HTML5 catches up), and Being All Arrogant ("Look at my web site! It is sooo special because it is Rich!").

(Adobe Flash might be even better in both cases, though if you are already a Microsoft coder, you might have an easier time coding for Silverlight.)

Of course, Silverlight is the platform of choice for Windows Phone 7. But, why would anyone want to develop anything for that?!

After twenty years of the World Wide Web, you'd have thought they would have figured out how to develop for it by now. The problem is that you can't have one dream team of people coming up with all the good ideas, no matter how hard you try.

We do have committees to establish HTML and protocol standards, since those must be shared. But, not server technologies, because they do not have to be.

Someone comes up with a good idea for web development (MVC-style, for example), which was not previously considered by a big player before (Microsoft, in this case), and the big player would be stupid not to adopt it once it is proven. (as we see with the roll-out of ASP.NET MVC)

And, this repeats with everything else: AJAX*, Clouds, agile programming, etc.

(*Funny how AJAX was first invented by Microsoft, but it took outside parties to demonstrate how useful it could be, before MS widely adopted it!)


At the same time, there are many people arguing that some tried and true technologies are dead and shouldn't be bothered with. C/C++, Java, PHP...these are platforms whose time has passed, according to some prognosticators, even though they are still dominant forces in the programming world.
C/C++ still dominates the desktop application world, and even a good portion of the mobile device app world.

Java is not going away, either. It also dominates a good portion of the mobile world, at least. And, other stuff.

PHP: Who knows? It is popular enough that it will stick around for a good long while. But, I was never much into it, myself.

There are some truly dead or dying languages, as far as opportunities for new projects are concerned: VB6, Pascal, FoxPro, just to name a few. Even COBOL and Fortran, though not entirely dead, offer few opportunities to grow as a developer, and are considered niche expertise.

(COBOL programmers might be paid well as a result. But, it is more difficult to master the skills to compete in that limited market.)

When I first started working as a developer, Rapid Application Development (RAD) was the biggest thing since sliced bread; today, it is a stupid idea that we wasted too much time on ten years ago.RAD is still a viable strategy, in cases where software needs to be developed… well… rapidly. Highly customized data-entry applications, for example. Especially if they are limited to usage in a particular office or something.

I would not use a RAD approach to commercial software, of course. Ugh.

However, if you use a CMS for a web app, you are essentially utilizing a lot of RAD principles, right there. So, the approach is hardly a complete waste of time.

It includes Software as a Service, though. This is the part that is more difficult for the average consumer to understand, so Microsoft is marketing "the cloud" as, essentially, online storage.Right.

Maybe that's what it will end up being. .Net was originally more than just a software development platform, but that's all it is today..NET was never anything more than a development platform (with a special focus on web services, for better or worse). It was marketed as something more than it really was, for a while.

With the Cloud you have the opposite: It IS a bit more than merely online storage. But, it is commonly sold as less than it could be, to most people.

Someday, I will see if I can find a use for it.

[aggle-rithm]

Someday, I will see if I can find a use for it.

Good, keep us posted!

[Robin]

COBOL once paid the highest rates.

Then it paid nothing, because no one needs outdated technology.

(Although I recently heard of an outfit that uses COBOL to render HTML. Why, I'll never know.)
There is at least one banking system that I know of, used in a number of major banks and deposit/lending institutions that is written in COBOL. I know that there are modules to do with online payments that we have to install from time to time that are written in COBOL.

I suppose I can understand why COBOL persists in financial institutions.

I agree completely about the HTML.

[Unabogie]

Maybe I'm wrong, but in my personal experience, these changes just sort of organically become best practices and for the most part, you'll build software the way your employer wants you to. Or you'll get a job babysitting some piece of legacy code and you'll code in that language for a few years. So if you become well versed in "agile" or become great with C#? Great, unless your client or employer wants to work differently.

IMHO, it's much more important to understand design patterns and work on creating orderly, well crafted code, because then you'll be equipped for anything.

(Although I do love working with our MVC system in AS3).

[The Central Scrutinizer]

There is at least one banking system that I know of, used in a number of major banks and deposit/lending institutions that is written in COBOL. I know that there are modules to do with online payments that we have to install from time to time that are written in COBOL.

I suppose I can understand why COBOL persists in financial institutions.

I agree completely about the HTML.

I've been in IT for 30 years. There is tons of COBOL still around.

[a_unique_person]

Interestingly, both Ruby and C++ developers say Java should be avoided. Ruby developers because Java is old-fashioned, C++ developers because it is slow (although not as slow as Ruby).

Java is a pig of a thing. Once you write any sufficiently complex application in Java, it becomes a massive lump of slowness, that takes forever to start. SAP was going to use Java as the future direction for all it's application development. They have quietly dropped it, and are moving applications from Java back to their own in house programming language of ABAP. ABAP is a derivative of COBOL. Not as theoretically correct as JAVA, but a hell of a lot faster, and less memory intensive. I saw a JAVA part of it use 48GB of memory the other day, to process one single transaction of data. You can't do that in a commercial environment, even today.

The problem is the Object Oriented programming paradigm. It leads to inherenently inefficient code. SAP managed to make an incredibly complex application that used the relational database method of describing the data, and that does work. Using OO to describe your data leads to an unmanageable pile of junk.

As for the future, functional programming is the way to go. When people will realise that and pay for it is another matter.

[aggle-rithm]

The problem is the Object Oriented programming paradigm. It leads to inherenently inefficient code. SAP managed to make an incredibly complex application that used the relational database method of describing the data, and that does work. Using OO to describe your data leads to an unmanageable pile of junk.


It CAN lead to that. If used properly, it's a way to manage complexity. Sure, it would be more efficient to write spaghetti code, provided it works perfectly and you don't have to maintain it.

Assembly code would be WAY faster than any other method, but who has time for that?


As for the future, functional programming is the way to go.

If you can reconcile the fact that functional programming has no side effects with the need for the application to actually do something, sure...

Functional principles are working their way into mainstream languages, and that may be as far as it ever goes.

[aggle-rithm]

I've been in IT for 30 years. There is tons of COBOL still around.

Our ERP system, which we've been trying to get rid of for three years, ocassionally throws a COBOL error.

[a_unique_person]

It CAN lead to that. If used properly, it's a way to manage complexity. Sure, it would be more efficient to write spaghetti code, provided it works perfectly and you don't have to maintain it.


"If used properly" is a way out for Java, but OO leads to a complexity that cannot be managed. Relational Databases have proven to be far more capable of managing complex data, and it's the data that code exists to manage. This 48GB of memory was probably done perfectly correctly at the design stage, then has to be hacked to make it workable, which they are doing now.

There is no need to resort to spaghetti code to create efficient applications. I would doubt that spaghetti code can create efficient applications, as it rapidly becomes unmaintainable.

[raspax]

In my humble opinion I think it all boils down to what delivers the best product in a limited amount of time for the least amount of money to the customer.

When you speak of Agile development, Extreme Programming (XP), test-driven development, and domain-driven design I think these are responses to the poor results of the Waterfall SDLC lifecycle. They tend to heavily emphasize communication and quick feedback between the developer and customer. This generally increases product quality and development speed. All pluses in the eyes of the customer!

In response to the upcoming dynamic languages such as Ruby or Python. I think these are rising primarily due to the low friction of scaffolding a brand new site in a matter of minutes. For example, I could easily create a new prototype blog in ruby in a matter of 5 minutes and have a working prototype for my customer. From there you could literally add or remove properties from the model while your customer is sitting next to you, redeploy and they could see the changes immediately. This in my opinion lends itself well to delivering the highest quality product, in the least amount of time for the least amount of money.

[a_unique_person]

That is the trap, isn't it. What if you want to create an application that wil do

*Accounts
*Sales
*Purchasing
*Reporting
*HR
*Materials Management
*Production Planning
*Warehouse Management
*Customer Relationship Management
*Supplier Relationship Management
*Custom Development and Modification
*Handle terabytes of data
*Tie all this up into a consistent package

The 'matter of minutes' is not the issue any more. It is scalability, the ability to handle tens of thousands of tables, security, reliability, availability that start to matter more.

[raspax]

That is the trap, isn't it. What if you want to create an application that wil do

*Accounts
*Sales
*Purchasing
*Reporting
*HR
*Materials Management
*Production Planning
*Warehouse Management
*Customer Relationship Management
*Supplier Relationship Management
*Custom Development and Modification
*Handle terabytes of data
*Tie all this up into a consistent package

The 'matter of minutes' is not the issue any more. It is scalability, the ability to handle tens of thousands of tables, security, reliability, availability that start to matter more.

If those are the upfront requirement then that would be communicated and obviously a different approach would be used. However keep in mind that if you rely on the database as your point of integration you will still have a monolithic system that for one doesn't scale well and more importantly isn't easily maintainable for future feature changes.

I challenge you to show me a large erp system that has easily maintainable code, scalable with the flip of a switch, has super high availability, and is super secure.

[stevea]

WowBagger brings up a god point about certain Microsoft concepts being less than advertised, but this complaint is not specific to Microsoft - it's common. Marketing types like to make up hype-words and you will see a LOT of that at trade-shows. I suggest you join/subscribe to ACM or IEEE software publications to get a professional viewpoint without (as much) hype, exaggeration.

A lot of marketing concepts have no 'there' 'there'. Middleware, CloudComputing ,in there end there it almost nothing new - just new emphasis, spin.

As software development matures as a discipline, and as more and more solutions appear to address various problems, I find myself torn between an ugly plethora of choices. I read up on the latest developments, and am constantly told "this is the next big thing!" It's something everyone is doing, all the jobs require this knowledge, etc., etc.

It's your job to sort the jive from the facts. No curious person has enough time to learn all they would like, but you need to examine these concepts deeply enough to evaluate the value. Sometimes you will be wrong.

When I first started working as a developer, Rapid Application Development (RAD) was the biggest thing since sliced bread; today, it is a stupid idea that we wasted too much time on ten years ago.

That was a clear fad IMO; tho' design/throw-away/redesign has some value. My opinion is that "design patterns" has pretty much run it's course. That doesn't mean "zero value" or that you can ignore it, but you need not become either a fanatical acolyte nor a blinder-wearing curmudgeon. Study a little. To the extent you find it useful study more.

On the other hand, there is a serious problem with ignoring all the new trends and just sticking with what you know. That's what I did the first five years or so of my career, and I found myself seriously behind the times. Certain aspects of Agile development, Extreme Programming (XP), test-driven development, and domain-driven design have become essential tools for me in the last few years; none of this was taught in school.

Understood, I agree. Again - follow trend to the extent YOU find useful and continue to explore, read.

Today the next big things are "the Cloud" (whatever that is), and dynamic programming languages like Ruby. There is still no universal development strategy for the Web. Even if you stick with Microsoft, you have to decide amongst ASP.Net, MVC, WebMatrix, Silverlight, and other technologies. After twenty years of the World Wide Web, you'd have thought they would have figured out how to develop for it by now.

Get outside of the Microsoft hothouse and look around. That's a sad, inbred culture. There is no one perfect solution to web or anything else. The better solutions, subsume and absorb the lesser ones. It takes long periods of time if the two opposing 'schools' have much depth. Don't become a foot-soldier/true-believer; see both sides clearly.


At the same time, there are many people arguing that some tried and true technologies are dead and shouldn't be bothered with. C/C++, Java, PHP...these are platforms whose time has passed, according to some prognosticators, even though they are still dominant forces in the programming world.

As background (the sort you SHOULD have gotten as an undergrad), you should be able to use a procedural language with pointers, like C, and also have decent skills in an object oriented programming/design. C++(which version?) is ubiquitous but not the best IMO. You should have have a solid introduction to functional programming - that was Lisp and Scheme in my day. but I'd suggest Haskell today.

Sadly Java was used as the sole undergrad language at some schools and the results weren't good IMO. There is nothing wrong with Java, however it's not a broad enough basis for an education; it's the Pascal of the 90's. Given the trends you really need to consider the impact of parallelism and concurrency in software - both as functional languages and parallelizing libraries and as distributed systems.

Many BSCS types couldn't understand a semaphore, race condition or sketch a device driver if their lives depended on it. If you don't understand the foundation your stand on -then you can't make good decisions about building the next floor.

Given that a single person can only learn a limited portion of what's out there, and we have no idea what's going to actually be used an three years...how does one choose what to focus on today?

Plan to 'learn' 3 or more languages per year, not necessarily 100% mastery but good basics coverage and some thinking about the rest. Then it's not so important to choose the 'perfect' language to learn next. If you really enjoy one - then stick with it longer. You'll never regret following your intellectual interests. Read some good journals, but primarily opinion & thought that contradicts your own. Become a sukisha - a person of taste; learn to express comparative advantages and disadvantages of alternatives using your experience and reading. Think about how to express the differences.

[aggle-rithm]

WowBagger brings up a god point about certain Microsoft concepts being less than advertised, but this complaint is not specific to Microsoft - it's common.

It's not a bad point, but I wouldn't call it a god point.

[DallasDad]

In my experience, things like Ruby are good for putting up quick demos, more as a proof of concept or validity check (is this really what the customer wanted?) than anything else. Unless the application or website is going to remain with fewer than a hundred users, you have to code the final project in something else.

Ruby itself is pure C for a reason.

I like many of the ideas behind OOP, especially the encapsulation and the ability to keep the manipulation together with the data. But it all breaks down when you need to process 170 million records recoverably into a redundant data set during a 30-minute window. The tried and true procedural languages can take advantage of the processor power in a way that the newer languages can't -- and do so while minimizing the use of resources (other programs need to be running, too).

I use C++ every day. Compilers have long since reached the stage where it's actively counterproductive to hand-code inner loops in assembler (or almost always), but I still prefer C over C++ for anything time-sensitive.

Like most disciplines, programming involves trade-offs. Speed of development vs. robustness of the final product. Ease of encapsulation vs. efficiency of algorithms. And so forth.

If you're just writing web apps for small companies, use whatever they want, or whatever you want (if you have the option). If you're going to work on large projects, or plan to serve millions of simultaneous customers, no interpreted language is going to have the chops.

Most large companies have standards for coding. Some of them are stupid, some of them are bitterly-learned lessons that come from trying to maintain something over a period of years or decades. Your bright newfangled language may be gone, or YOU may be gone, when it comes time to update the application. No one wants to pay those costs.

If you're flittering from job to job, or only doing lightweight one-offs, then you need to keep up with whatever's new and popular, if only because your customer might insist on using it. But you need the basics far more. Newer languages make tasks easier, but only by robbing you of knowing what's really happening. (Well, perhaps not robbing, but at least eliminating the need to know.)

[PixyMisa]

In my experience, things like Ruby are good for putting up quick demos, more as a proof of concept or validity check (is this really what the customer wanted?) than anything else. Unless the application or website is going to remain with fewer than a hundred users, you have to code the final project is something else.
Yeah, that's what Python is for. :)

[a_unique_person]

If those are the upfront requirement then that would be communicated and obviously a different approach would be used. However keep in mind that if you rely on the database as your point of integration you will still have a monolithic system that for one doesn't scale well and more importantly isn't easily maintainable for future feature changes.

I challenge you to show me a large erp system that has easily maintainable code, scalable with the flip of a switch, has super high availability, and is super secure.

SAP does a good job of it. They started with a hierarchical database, and quickly changed to relational. Best design decision they ever made. Their experiment with Java was a major setback.

[raspax]

Plan to 'learn' 3 or more languages per year, not necessarily 100% mastery but good basics coverage and some thinking about the rest. Then it's not so important to choose the 'perfect' language to learn next. If you really enjoy one - then stick with it longer. You'll never regret following your intellectual interests. Read some good journals, but primarily opinion & thought that contradicts your own. Become a sukisha - a person of taste; learn to express comparative advantages and disadvantages of alternatives using your experience and reading. Think about how to express the differences.

This is probably the best advice I've seen in quite a while.

[aggle-rithm]

In my experience, things like Ruby are good for putting up quick demos, more as a proof of concept or validity check (is this really what the customer wanted?) than anything else. Unless the application or website is going to remain with fewer than a hundred users, you have to code the final project in something else.


I have seen quite a few applications that bear the tell-tale markings of having been merely a demo/proof-of-concept, but some bone-headed manager said, "It looks great, ship it!"

[aggle-rithm]

That is the trap, isn't it. What if you want to create an application that wil do

*Accounts
*Sales
*Purchasing
*Reporting
*HR
*Materials Management
*Production Planning
*Warehouse Management
*Customer Relationship Management
*Supplier Relationship Management
*Custom Development and Modification
*Handle terabytes of data
*Tie all this up into a consistent package


Why would you want to do that? A distributed system would work much better.

[aggle-rithm]

SAP does a good job of it. They started with a hierarchical database, and quickly changed to relational. Best design decision they ever made. Their experiment with Java was a major setback.

I don't want to say too much about SAP, because I don't have that much experience with it. However, it does always seem to be connected to a ridiculously over-complicated operation, in my limited experience.

Dell tried to implement SAP a while back. After spending millions of dollars and thousands of man-hours, they abandoned the project as unworkable.

This sort of thing is what keeps ERP consultants in business.

[Ethan Thane Athen]

'Cloud' is basically online storage. Dropbox, essentially. Google Docs. Save online and you can access your data anywhere.

If you added in the concept of your applications being available online, on demand as well as 'storage' for your data then I'd agree with your definition.

[Ethan Thane Athen]

It CAN lead to that. If used properly, it's a way to manage complexity. Sure, it would be more efficient to write spaghetti code, provided it works perfectly and you don't have to maintain it.



Non O-O code does not have to be spaghetti code. I have worked in IT for around 25 years, starting with Cobol and now working with J2EE. I don't see any great advantage to O-O that we didn't get from sensibly modularising our sequential code - indeed I am often in dispute with my programmers estimates because I know how long something would have taken me to code 'the old way' and yet the new, 'fantastically re-useable' O-O approach gets estimated (and subsequently takes) nearly double or triple the time to write and then is a bugger to maintain because 'Ooooh if you change that you'll have to spend weeks re-testing all this other stuff 'cos it all uses it.' NB Don't take this as me thinking O-O is a waste of time - each just has its pros and cons and, in pure programming terms we really don't seem to have moved on in the last 25 years. Computing power, nicety of interface etc, absolutely but efficiency of programming logic? Nope - other than there being a lot more ready written code out there to copy and the internet making it easier to find.

Humph, I remember the claims for 4th generation languages and how they would bring programming to the end user and then the next big thing that came along was java! Hardly end-user in its syntax and setup!

It's all a bit depressing really.:p

[raspax]

SAP does a good job of it. They started with a hierarchical database, and quickly changed to relational. Best design decision they ever made. Their experiment with Java was a major setback.

Due to the easily maintainable and uncomplicated code that is the reason that all SAP consultants are willing to work for pennies on the dollar, and developers are falling over each other trying to become SAP consultants. ;)

[raspax]

Non O-O code does not have to be spaghetti code. I have worked in IT for around 25 years, starting with Cobol and now working with J2EE. I don't see any great advantage to O-O that we didn't get from sensibly modularising our sequential code - indeed I am often in dispute with my programmers estimates because I know how long something would have taken me to code 'the old way' and yet the new, 'fantastically re-useable' O-O approach gets estimated (and subsequently takes) nearly double or triple the time to write and then is a bugger to maintain because 'Ooooh if you change that you'll have to spend weeks re-testing all this other stuff 'cos it all uses it.'

So wait. Let me get this straight. Does this mean we're supposed to have 50 different ship functions? And if tomorrow the business changes it's ship via from FedEx to UPS we need to touch 50 different files? Damn.. I didn't realize. I've been doing it all wrong this whole time.

[aggle-rithm]

Non O-O code does not have to be spaghetti code.


I'm using the term liberally--what I mean by "spaghetti code" is purely procedural programming.

I have worked in IT for around 25 years, starting with Cobol and now working with J2EE. I don't see any great advantage to O-O that we didn't get from sensibly modularising our sequential code - indeed I am often in dispute with my programmers estimates because I know how long something would have taken me to code 'the old way' and yet the new, 'fantastically re-useable' O-O approach gets estimated (and subsequently takes) nearly double or triple the time to write

Ninety-five percent of programmers do not know how long a project will take. The other five percent are liars.


and then is a bugger to maintain because 'Ooooh if you change that you'll have to spend weeks re-testing all this other stuff 'cos it all uses it.'


Not if you do it properly, with unit tests and continuous integration. Of course, this only works if you do OOP properly.

NB Don't take this as me thinking O-O is a waste of time - each just has its pros and cons and, in pure programming terms we really don't seem to have moved on in the last 25 years. Computing power, nicety of interface etc, absolutely but efficiency of programming logic? Nope - other than there being a lot more ready written code out there to copy and the internet making it easier to find.


That's the big dilemma these days...the more efficient it is, the less maintainable, and vice-versa.


Humph, I remember the claims for 4th generation languages and how they would bring programming to the end user and then the next big thing that came along was java! Hardly end-user in its syntax and setup!

It's all a bit depressing really.:p

I agree, the industry has been far too optimistic about how easy they can make programming. Programming is hard, period. There's simply no other way around it. What the 4th generation languages do it make it (potentially!) more maintainable.

[not daSkeptic]

Java is a pig of a thing. Once you write any sufficiently complex application in Java, it becomes a massive lump of slowness, that takes forever to start.

It can be a pig in some cases, especially on memory usage. C/C++ will always be better in this regard because it doesn't need to run a VM. However, I've seen real-world Java code run faster than a C++ version. It really depends on the specifics.

The problem is the Object Oriented programming paradigm. It leads to inherenently inefficient code. SAP managed to make an incredibly complex application that used the relational database method of describing the data, and that does work. Using OO to describe your data leads to an unmanageable pile of junk.

That's not necessarily the fault of OOP so much as the fault of the developers. Not every tool is the right fit for the job. If one's primary need is to arbitrarily query large sets of tabular data, then naturally a relational database is the better choice.

[not daSkeptic]

... OO leads to a complexity that cannot be managed.

It can, but not always. One trouble area is unit-testing. In order to completely isolate an object from all others, any collaboration must take place through abstract interfaces. This can result in tiny, 200-line applications exploding into 15 parts for no reason other than to satisfy testing requirements.

Relational Databases have proven to be far more capable of managing complex data ...

Relational systems are capable of managing some complex data, but not all. They often have difficulty with less-than-fully-structured information, for instance.

... it's the data that code exists to manage.

Not necessarily. Not all software systems are built around data-stores.

[not daSkeptic]

What if you want to create an application that wil do

*Accounts
*Sales
*Purchasing
*Reporting
*HR
*Materials Management
*Production Planning
*Warehouse Management
*Customer Relationship Management
*Supplier Relationship Management
*Custom Development and Modification
*Handle terabytes of data
*Tie all this up into a consistent package


I would argue that one should not attempt to create an application that does all of these things. In my experience, attempting to fit a large system into a single model is asking for trouble.

[The Central Scrutinizer]

In my experience, things like Ruby are good for putting up quick demos, more as a proof of concept or validity check (is this really what the customer wanted?) than anything else.

That's how Visual Basic started out.

[The Central Scrutinizer]

I don't want to say too much about SAP, because I don't have that much experience with it. However, it does always seem to be connected to a ridiculously over-complicated operation, in my limited experience.

Dell tried to implement SAP a while back. After spending millions of dollars and thousands of man-hours, they abandoned the project as unworkable.

This sort of thing is what keeps ERP consultants in business.

My only experience with SAP is when I'm trying to work with some sort of system and I'll remark "this is a hunk of crap, what is it written in?", the answer is invariably "SAP".

[stevea]

In my experience, things like Ruby are good for putting up quick demos, [...]

This depends greatly on the requirements, the context of the application. The apps on your smart-phone or your chumby or the warehouse-mgr's data tablet will never have more than one user, but then there are performance and size limitations that may dictate the language.

I recall one embedded project where the handheld system had a generous 32MB of flash storage to hold kernel, apps and data. Some of the software designers couldn't get used to the idea that, even ignoring performance, we weren't going to put 20MB of perl libraries & binaries on the device.

I like many of the ideas behind OOP, especially the encapsulation and the ability to keep the manipulation together with the data.

There is more than a little to like, and the OO concept is not restricted to classic OOP languages. Kernels like BSD or a Linux is very much OO in design despite the fact these are all written in C with some assembler. For example there is an informal 'class' for the MMU interface, where each architecture is a instance written in assembler. The file-systems are a class with numerous instances. Device drivers are a class w/ two inheriting (sub) classes. In some kernels processes are a class with a well defined and variable set of operations. Access control is implemented as a class with several instances. The implementation is in some cases, fairly close to the way an OO compiler would generate code.

It's better to have an HLL to enforce and check, but it's impractical to use a language like C++ because of the extensive run-time support needed. And efficiency ....

But it all breaks down when you need to process 170 million records[...]

Apps in some OO languages can be just as fast and efficient as in a comparable procedural languages, *BUT* it's very difficult for a developer to determine which libraries and methods are efficient and which are not. Also it's somewhat difficult to estimate the performance of in-line code in most HLLs and that's critical for the heavily used bits.

'Efficiency' whether in performance or space or power consumption .. shouldn't become a fetish, but it also is never ignorable and occasionally critical.

Like most disciplines, programming involves trade-offs. Speed of development vs. robustness of the final product. Ease of encapsulation vs. efficiency of algorithms. And so forth.

Exactly, and it's this complex 'tension' between competing requirements (including project schedule, life-cycle, development time, app performance) that makes design interesting. How that tension is resolved is the 'art'.

If you're just writing web apps for small companies, use whatever they want, or whatever you want (if you have the option).

You should always be able to justify the decision against project goals. It seems a lot of developers are undisciplined and substitute their personal biases for objective comparisons. That can ruin a small company.

Most large companies have standards for coding. Some of them are stupid, some of them are bitterly-learned lessons that come from trying to maintain something over a period of years or decades. Your bright newfangled language may be gone, or YOU may be gone, when it comes time to update the application. No one wants to pay those costs.

A stupid coding standard is usually better than no standard.

Amen ! I've earned a lot of money as a consultant un-doing bad design decisions made by undisciplined egotistical developers. 'Cowboy' developers who have since ridden into the sunset - leaving behind a big pile of horse poop, and little or no documentation. We all have favorite tools - the problem occurs when our tool-bias distorts our view of design problems. If you are overestimating the advantages of your pet-tool and underestimating the limitations, then you can't make good decisions.

So my earlier point - learn a lot of languages and understand these in comparison. Read (good) criticisms of your favorites. Be a good skeptic - always doubt and question, especially your own preferences.


I don't see any great advantage to O-O that we didn't get from sensibly modularising our sequential code

Really ? The ability of an OO compiler to manage classes and inheritance and namespaces and all the strong type checking is no advantage ? We do (some of) this in the kernels in C, passing around lists of function pointers and all sorts of pointer indirections - it's massively complex and error prone and humans do all the checking. I think OO compilers provide a huge advantage.

- indeed I am often in dispute with my programmers estimates because I know how long something would have taken me to code 'the old way' and yet the new, 'fantastically re-useable' O-O approach gets estimated (and subsequently takes) nearly double or triple the time to write and then is a bugger to maintain because

Somewhat agree. I don't think the difference in development time is so great as you suggest. Properly written OO strongly disposes the developer to think through all the data types and methods before writing code and that sames time. OTOH the notion that this creates much re-usability seems generally untrue. My experience is that expanding or changing the requirements after the fact usually causes "refactoring" which is often an OO synonym for throwing your code away and starting over. That's no better and no worse that with procedural languages.

A website that is likely to make you think, and perhaps change some opinions,
http://c2.com/cgi/wiki?RefactoringWithCeePlusPlus


That's the big dilemma these days...the more efficient it is, the less maintainable, and vice-versa.

That's not new - it's fundamental. It's rare that a naive approach to any problem is efficient by any measure except 'design' time. There is usually added efficiency (by some well defined metric) to be had at the cost of added complexity + design time.

[Ethan Thane Athen]

....
Really ? The ability of an OO compiler to manage classes and inheritance and namespaces and all the strong type checking is no advantage ? We do (some of) this in the kernels in C, passing around lists of function pointers and all sorts of pointer indirections - it's massively complex and error prone and humans do all the checking. I think OO compilers provide a huge advantage.

We don't use much C, mostly java. In my experience, my programmers struggle to keep track of the object library (at least more than I used to struggle to know what module to call to eg calculate dates) because stuff is split down into such small chunks.

...

Somewhat agree. I don't think the difference in development time is so great as you suggest. Properly written OO strongly disposes the developer to think through all the data types and methods before writing code and that sames time. OTOH the notion that this creates much re-usability seems generally untrue. My experience is that expanding or changing the requirements after the fact usually causes "refactoring" which is often an OO synonym for throwing your code away and starting over. That's no better and no worse that with procedural languages.



Yeah, I'm probably exaggerating a bit but I'm not talking about estimating the whole project, just one component - possibly even a simple problem fix that, in my 'procedural' head I can work a simple 'one line fix' for. Oh and yeah, I hear the 'refactoring' word a lot!

...
A website that is likely to make you think, and perhaps change some opinions,
http://c2.com/cgi/wiki?RefactoringWithCeePlusPlus



Thanks for the link. I haven't done any C++ for about 10 years though!;)

[aggle-rithm]

OOP greatly reduces cyclomatic complexity. I never use switch statements anymore, and rarely use if statements.

[aggle-rithm]

SAP was going to use Java as the future direction for all it's application development. They have quietly dropped it, and are moving applications from Java back to their own in house programming language of ABAP. ABAP is a derivative of COBOL. Not as theoretically correct as JAVA, but a hell of a lot faster, and less memory intensive. I saw a JAVA part of it use 48GB of memory the other day, to process one single transaction of data. You can't do that in a commercial environment, even today.


I'd never heard of ABAP before.

It's my policy never to make snap judgements based on superficial impressions, but...I refuse to use a programming language that sounds like the first thing I'd say after a debilitating stroke.

[Wudang]

I dislike application-specific languages on general principles.

For trends I look at job ads and what's hot on developerworks that isn't IBM pushing their new toy.

[not daSkeptic]

My experience is that expanding or changing the requirements after the fact usually causes "refactoring" which is often an OO synonym for throwing your code away and starting over.

The goal of refactoring is to improve the design of code without altering its behavior. By definition that means tossing out the bad stuff and replacing it with something better. Occasionally it may mean starting over on certain components, but if this happens frequently you've got problems.

[raspax]

The goal of refactoring is to improve the design of code without altering its behavior. By definition that means tossing out the bad stuff and replacing it with something better. Occasionally it may mean starting over on certain components, but if this happens frequently you've got problems.

Why would constant refactoring mean that you've got problems? Every developer knows that requirements change and new features are always added. With every change there is always technical debt that's introduced. Eventually you need to repay that debt by refactoring sections of the system. I would argue that if you're not refactoring enough, your system is not changing enough, and your company is not innovating enough.

[not daSkeptic]

Why would constant refactoring mean that you've got problems?

I never said it did.

[The Central Scrutinizer]

Like I said, pick the one that pays the best rates. Let the nerds argue over the technicalities.

[jnelso99]

Or pick the one that's paying you now. For me, that's C++, MFC, and Java.

[a_unique_person]

I'd never heard of ABAP before.

It's my policy never to make snap judgements based on superficial impressions, but...I refuse to use a programming language that sounds like the first thing I'd say after a debilitating stroke.

There is plenty of work and it pays well.

http://www.seek.com.au/JobSearch?DateRange=31&Keywords=abap&nation=3000&SearchFrom=quick

It is not at all theoretically sound, but it is designed to easily interface to relational databases, and has even hacked on an OO component.

[Paul C. Anagnostopoulos]

OOP greatly reduces cyclomatic complexity. I never use switch statements anymore, and rarely use if statements.
And yet the complexity of those conditions must be realized somewhere. Is it more perspicuous to have them buried in the underlying structure of the language?

~~ Paul

[Ray Brady]

When I first started working as a developer, Rapid Application Development (RAD) was the biggest thing since sliced bread; today, it is a stupid idea that we wasted too much time on ten years ago.

I've made a very lucrative career out of Rapid Application Development. It's an extremely beneficial strategy when you have clients who know they need some kind of software solution, but are unable to articulate exactly what it's supposed to do. Clients like these want someone to show them what they need, and this is most easily accomplished when you can provide them with functioning prototypes quickly and with a minimum of upfront input.

I'm not going to pretend I have a clue as to what software development will look like in ten years, but I would be very surprised if there were no room for the kind of quick turnaround services I provide.

[aggle-rithm]

And yet the complexity of those conditions must be realized somewhere. Is it more perspicuous to have them buried in the underlying structure of the language?

~~ Paul

The goal of reducing cyclic complexity is to make the source code easier to understand...perhaps at the expense of performance.

It's like the old fish-or-cut-bait dilemma. The more fast and efficient code is, the more likely it will be difficult to maintain. The easier it is to maintain, the less efficient it will be. (In general. I know there are exceptions.)

Performance usually isn't an issue with the software I work with, since most of the execution time is spent waiting for database access, not in crunching data.

[Paul C. Anagnostopoulos]

The goal of reducing cyclic complexity is to make the source code easier to understand...perhaps at the expense of performance.
Right, but if the complexity is simply buried in the semantics of the language, rather than programmed explicitly, have we gained anything?

I don't know, just askin'.

~~ Paul

[aggle-rithm]

Right, but if the complexity is simply buried in the semantics of the language, rather than programmed explicitly, have we gained anything?

I don't know, just askin'.

~~ Paul

I see what you're saying...

Yes, because the execution paths you're not interested in are hidden inside another class, rather than cluttering up the page.

[whitefork]

figure 85% of all business apps are in COBOL. You get money out of an ATM, you're probably interfacing with a CICS backend and dealing with COBOL. Your monthly statements and the batch cycles behind them - COBOL. Between 30 and 40,000 mainframes worldwide according to what I've been able to find and most of those are being used by businesses.

[whitefork]

COBOL programmers are dying off and retiring and there are very few university programs that teach it. There's still a market but it's recovering slowly. Meanwhile I entertain myself by learning JAVA.

[aggle-rithm]

COBOL programmers are dying off and retiring and there are very few university programs that teach it. There's still a market but it's recovering slowly. Meanwhile I entertain myself by learning JAVA.

In the short-lived Dilbert TV series, Asok mentioned that he knew COBOL. "They still teach that in school?" he was asked.

"Yes, in history class."

[CynicalSkeptic]

If those are the upfront requirements...
You actually get upfront requirements? Can I come work for your company?

[MortFurd]

OOP greatly reduces cyclomatic complexity. I never use switch statements anymore, and rarely use if statements.

What are you doing that you can get away without making any decisions? Or perhaps I should ask - How are you hiding them?

[Paul C. Anagnostopoulos]

Yes, because the execution paths you're not interested in are hidden inside another class, rather than cluttering up the page.
I can do that with a function; don't need OOP.

I thought you were saying that the OO language semantics reduces the number of switch and if statements that you have to code anywhere. Otherwise how can you not be using switch statements and rarely if statements?

Ah, perhaps they are in other classes that you did not write.

~~ Paul

[aggle-rithm]

What are you doing that you can get away without making any decisions? Or perhaps I should ask - How are you hiding them?

Check this link:

http://www.antiifcampaign.com/

ETA: On second thought, don't. That's a crap site.

Basically, you replace if's and switch statements with design patterns like chain of responsibility, strategy, or specification.

[CynicalSkeptic]

What are you doing that you can get away without making any decisions? Or perhaps I should ask - How are you hiding them?

Method Overloading and Polymorphism?

[not daSkeptic]

What are you doing that you can get away without making any decisions? Or perhaps I should ask - How are you hiding them?

This actually isn't that uncommon when dealing with CRUD applications, which are defined by their lack of any significant business logic. When all you're doing is shuttling information back and forth between the user and a database, there isn't a whole lot to be conditional about.

[aggle-rithm]

I thought you were saying that the OO language semantics reduces the number of switch and if statements that you have to code anywhere. Otherwise how can you not be using switch statements and rarely if statements?


It doesn't do that inherently, you have to use design patterns.

Such as:

void HandleObject(obj)
{
var lst = GetListOfHandlers();

var handler = lst.Find(h.CanHandleObject(obj));

handler.Handle(obj);
}

"lst" is a list of ICanHandleObject interfaces.

[Wudang]

COBOL programmers are dying off and retiring and there are very few university programs that teach it. There's still a market but it's recovering slowly. Meanwhile I entertain myself by learning JAVA.

Well yes, my very large bank uses a lot of COBOL which has to be maintained and reworked to meet fiduciary, legislative and other requirements but we (sadly) do all training in house and is largely geared to produce "coding clerks".
And IBM are still developing COBOL though I believe they didn't act on our feedback that the Linkage Section is bloody ridiculous on MVS.

[Paul C. Anagnostopoulos]

It doesn't do that inherently, you have to use design patterns.

Such as:

void HandleObject(obj)
{
var lst = GetListOfHandlers();

var handler = lst.Find(h.CanHandleObject(obj));

handler.Handle(obj);
}

"lst" is a list of ICanHandleObject interfaces.
Right, so the decisions are buried in the Find method, which you did not write. I agree that this can make your code clearer, assuming that the reader understands the behavior of Find. If not, then the reader has to dig through Find.

~~ Paul

[aggle-rithm]

Right, so the decisions are buried in the Find method, which you did not write. I agree that this can make your code clearer, assuming that the reader understands the behavior of Find. If not, then the reader has to dig through Find.

~~ Paul

In C#, Find() is an extension method on the standard list class. It takes as a parameter a lambda function that tells Find() what to look for in each item in the list.

The CanHandleObject() function basically replaces the "case" clause in a switch statement. It usually looks something like this:

public bool CanHandleObject(object obj)
{
return this.Status == StatusEnum.New;
}

This is a little bit of functional programming within a procedural language...it's a function that takes a function as a parameter which, in turn, calls another function.

[jnelso99]

Right, so the decisions are buried in the Find method, which you did not write.

Why should somebody reinvent the wheel every time a "Find" is needed if an API provides it already?

Hmm...a coworker implemented some function, but I don't want to have to dig through his code since I didn't write it. I better write my own version of that function! Without using any standard API calls, since I didn't write those either! Assembly all the way!

I agree that this can make your code clearer, assuming that the reader understands the behavior of Find. If not, then the reader has to dig through Find.

~~ Paul

OH MY GOD! You mean the reader may have to <gasp> LOOK AT THE DOCUMENTATION? The HORROR! :rolleyes:

[aggle-rithm]

Why should somebody reinvent the wheel every time a "Find" is needed if an API provides it already?

Hmm...a coworker implemented some function, but I don't want to have to dig through his code since I didn't write it. I better write my own version of that function! Without using any standard API calls, since I didn't write those either! Assembly all the way!



OH MY GOD! You mean the reader may have to <gasp> LOOK AT THE DOCUMENTATION? The HORROR! :rolleyes:

I read an article recently by someone who dislikes C# for, among other reasons, turning algorithms into methods. "Find()" being an example.

It's a big time-saver to use Microsoft's implementation of Find() (or "Where()" or "OrderBy()"), but it takes away your choice of which specific algorithm to use.

Personally...I don't think it's a problem. If micro-optimizing performance is that important, I'll code in C++ instead.

[whitefork]

Well yes, my very large bank uses a lot of COBOL which has to be maintained and reworked to meet fiduciary, legislative and other requirements but we (sadly) do all training in house and is largely geared to produce "coding clerks".
And IBM are still developing COBOL though I believe they didn't act on our feedback that the Linkage Section is bloody ridiculous on MVS.
I believe they still support SERVICE RELOAD but it's treated as a comment. ALTER remains as well as far as I know but I haven't seen it used in maybe 30 years.

[Paul C. Anagnostopoulos]

Why should somebody reinvent the wheel every time a "Find" is needed if an API provides it already?
I don't think anyone should reinvent the wheel. We were talking about whether the code was easier to follow or not.


Hmm...a coworker implemented some function, but I don't want to have to dig through his code since I didn't write it. I better write my own version of that function! Without using any standard API calls, since I didn't write those either! Assembly all the way!
Well, that's pretty much my opinion, but I'm not proposing it for anyone else. Your coworker probably wrote a broken version of the function. The standard API calls are whacky. Go assembler!


OH MY GOD! You mean the reader may have to <gasp> LOOK AT THE DOCUMENTATION? The HORROR!
The question was about cyclomatic complexity, not reuse. I'm all for reuse, in spite of my previous statement.

~~ Paul

[W.D.Clinger]

OOP greatly reduces cyclomatic complexity. I never use switch statements anymore, and rarely use if statements.

And yet the complexity of those conditions must be realized somewhere. Is it more perspicuous to have them buried in the underlying structure of the language?

The goal of reducing cyclic complexity is to make the source code easier to understand...perhaps at the expense of performance.

Right, but if the complexity is simply buried in the semantics of the language, rather than programmed explicitly, have we gained anything?


Yes, because the execution paths you're not interested in are hidden inside another class, rather than cluttering up the page.

I can do that with a function; don't need OOP.

I thought you were saying that the OO language semantics reduces the number of switch and if statements that you have to code anywhere. Otherwise how can you not be using switch statements and rarely if statements?

Ah, perhaps they are in other classes that you did not write.


Basically, you replace if's and switch statements with design patterns like chain of responsibility, strategy, or specification.


Method Overloading and Polymorphism?
Yes.

Dynamic method dispatch writes the switch and/or if statements for you when you're trying to implement:

inclusion polymorphism
ad hoc polymorphism
extensible-sum-of-extensible-product types

If those things account for a large fraction of your code, then dynamic method dispatch can be worthwhile.

(Most current implementations of OO languages implement dynamic method dispatch badly, but that's another topic.)

[a_unique_person]

Business rules can be very complex. The problem that OO has not solved is persistence.

[hodgy]

As I understand it, "The Cloud" is putting your data on other people's computers, so that you don't have to worry about it.
For some reason, this worries me.

When done properly, putting your data and / or applications on the Cloud can be much less worrisome and have significant advantages versus an on-premise approach. There can be major economies and capabilities afforded by scale.

Consider that when using something like Salesforce a one-man-band business benefits from the same redundancy, scalability, disaster recovery, security etc... as that provided to large corporations.

[TjW]

And wonderfully, when it breaks, you're not responsible. No worries!

[not daSkeptic]

The problem that OO has not solved is persistence.

How so?

[hodgy]

And wonderfully, when it breaks, you're not responsible. No worries!

If you are a CIO or otherwise the person who makes IT platform decisions then of course you are responsible for those decisions. The point is that the 'cloud' offers some options and advantages that would otherwise be inaccessible to many / most.

Those advantages can translate into reducing the risk that things will break in the first place. Which medium sized companies can afford to have redundant data centres on separate continents and redundant fibre connectivity from multiple operators (for example)?

[TjW]

Yes, of course they're responsible for the decisions. But they won't be responsible for making it work when it stops. Thus, no worries. Someone else is doing the worrying for you.
Shucks, get a reliable provider like Amazon. What could go wrong?

[hodgy]

Yes, of course they're responsible for the decisions. But they won't be responsible for making it work when it stops. Thus, no worries. Someone else is doing the worrying for you.
Shucks, get a reliable provider like Amazon. What could go wrong?

Hmmm - maybe you are right - your IT bloke Joe is surely less likely to mess up your backups than a company that services millions of customers worldwide and has highly automated, audited and tested procedures upon which their stock market value depends.

I have been Joe BTW so I know how fallible he is.

[TjW]

Hmmm - maybe you are right - your IT bloke Joe is surely less likely to mess up your backups than a company that services millions of customers worldwide and has highly automated, audited and tested procedures upon which their stock market value depends.

I have been Joe BTW so I know how fallible he is.

Yep. Cloud-sitting Joe won't make those mistakes. Why, the company is ISO9000 certified, and practices six sigma, and stuff.

[a_unique_person]

How so?

OO databases died an early death, never to be resurrected.

[not daSkeptic]

OO databases died an early death, never to be resurrected.

And?

[Rasmus]

And wonderfully, when it breaks, you're not responsible. No worries!

The end user or their on-site tech support is rather unlikely to be responsible for stuff that is significantly broken. That's what warranties and service agreements and uptime guarantees are there for.

If it's important, then you wouldn't replace let alone fix a broken component: You'd call the responsible service people to come and do that for you.

And I wouldn't be surprised if you could find much higher availability somewhere in the cloud than you could ever afford for a small business. (And getting multiple redundancy in your Internet connection on-site is fairly simple - a router that connects to your DSL and switches to a backup cellular service will only cost you a couple of hundred bucks.)

[aggle-rithm]

OO databases died an early death, never to be resurrected.

Are you talking about no-SQL databases or object relational mapping? Both are solutions to the persistence problem with object orientation that are still widely used.

[a_unique_person]

The only industrial strength databases are still the SQL databases, and OR mapping is just a nasty kludge. The SQL language itself needs to be revised, because it was never meant to be what it is. The developers came up with a quick prototype, IBM just took it over and sold it before they developed a real language that was more elegant.

[aggle-rithm]

The only industrial strength databases are still the SQL databases, and OR mapping is just a nasty kludge.

Well, nasty kludge or not, OR mapping is indicative of something that developers have had to deal with all along and will continue to have to deal with...getting differently-designed systems* to work together. That's why it's important to establish firm lines of demarcation and put anti-corruption layers between them.


The SQL language itself needs to be revised, because it was never meant to be what it is. The developers came up with a quick prototype, IBM just took it over and sold it before they developed a real language that was more elegant.

What kind of revisions do you think should be made? I assume you're not talking about something like the extensions provided by Microsoft/Sybase and Oracle.


*Here I'm not just talking about systems that happen to be designed differently, but those that are designed for different purposes and so have different priorities.

[a_unique_person]

See "the third manifesto" http://c2.com/cgi/wiki?TheThirdManifesto. SQL can be much easier. Proprietary hacks usually just debase the original intentions of SQL.

[not daSkeptic]

The only industrial strength databases are still the SQL databases ...

And?

[a_unique_person]

And?

I think that says a lot. The hierarchical databases, and other technologies, died off long ago. OO is based on the concept of hierarchies and inheritance. That was demonstrated long ago to be a computing dead end with the hierarchical database, then was resurrected with OO.

[Wudang]

Yes but OO doesn't stop you developing relational software. Any message or event driven system, for example, can be regarded as relational so you can easily apply relational solutions to appropriate problems.

[a_unique_person]

As soon as you use inheritance, relational is gone. A friend who used OO said to me years ago that inheritance was becoming deprecated in favor of encapsulation. That is, each object was becoming a sort of view. However, that tosses out the whole inheritance basis, which was always broken anyway. No one has ever come up with a viable way to use multiple inheritance.

[Wudang]

As soon as you use inheritance, relational is gone.
Evidence?

[aggle-rithm]

As soon as you use inheritance, relational is gone. A friend who used OO said to me years ago that inheritance was becoming deprecated in favor of encapsulation. That is, each object was becoming a sort of view. However, that tosses out the whole inheritance basis, which was always broken anyway. No one has ever come up with a viable way to use multiple inheritance.

The biggest problem with inheritence is an issue of maintainability. Maintainable software minimizes coupling and maximizes cohesion. Inheritance is kind of counterproductive in that regard.

However, polymorphism is still good, so nowadays we normally achieve this with interfaces rather than base classes. Although base classes are sometimes very useful as well.

[a_unique_person]

Evidence?
;) Good question.

The "Third Manifesto" does indeed try to implement a form of inheritance, within a relational framework. The design of inheritance within OO is a hierarchical one. That is very similar to the design of the old hierarchical databases such as IMS. It's an inherently broken design, with a hierarchy that, once created, is pretty well set in concrete once products are built using that design. A simple example, a truck, which is a vehicle, and inherits the vehicle attributes. What if it's a toy truck? How does it inherit the attributes of a toy? Java just takes the easy way out, and makes you do the work. What if the truck is not a vehicle any more, but it seems that it would be more logical to make it part of the manufactured goods hierarchy, just for example. All the trucks out there are now broken, it can't be done.

[aggle-rithm]

;) Good question.

The "Third Manifesto" does indeed try to implement a form of inheritance, within a relational framework. The design of inheritance within OO is a hierarchical one. That is very similar to the design of the old hierarchical databases such as IMS. It's an inherently broken design, with a hierarchy that, once created, is pretty well set in concrete once products are built using that design. A simple example, a truck, which is a vehicle, and inherits the vehicle attributes. What if it's a toy truck? How does it inherit the attributes of a toy?

One of the principles of good OO design is the Liskov Substitution Principle, which addresses exactly this issue.

Not everyone who uses OO does it correctly. That doesn't make it an inherently broken concept.

[not daSkeptic]

The hierarchical databases, and other technologies, died off long ago.

What other technologies are you referring to?

[a_unique_person]

What other technologies are you referring to?

Network databases, various "4GL" products, keyed flat file with indexes and hierarchical data, known in IBM as VSAM.

[not daSkeptic]

Network databases, various "4GL" products, keyed flat file with indexes and hierarchical data, known in IBM as VSAM.

What precisely you do mean when you say these things have died off? Do you mean that non-RDBMS persistence technologies are no longer commonly employed in the development of new software systems?

[aggle-rithm]

Network databases, various "4GL" products, keyed flat file with indexes and hierarchical data, known in IBM as VSAM.

Just curious...how do you feel about normalization?

[a_unique_person]

I'm OK about it. Is this a trick question?

[a_unique_person]

What precisely you do mean when you say these things have died off? Do you mean that non-RDBMS persistence technologies are no longer commonly employed in the development of new software systems?

If you want a database off the self to do a job that can scale well, most people will use an RDB these days.

[aggle-rithm]

I'm OK about it. Is this a trick question?

Not at all, just curious.

[a_unique_person]

Not at all, just curious.
Considering you aren't going to be doing anything sensible with an RDB without using normalisation, it just seemed to be a strange question.

[aggle-rithm]

Considering you aren't going to be doing anything sensible with an RDB without using normalisation, it just seemed to be a strange question.

I've found that more data-centric people tend to favor normalization, while process-oriented people like to have everything in denormalized flat files. I was just interested in knowing where you stood with that.

I have yet to see an ERP system where the tables are even in first normal form. I think it has something to do with the practice of using the transaction database for reporting.

[not daSkeptic]

If you want a database off the self to do a job that can scale well, most people will use an RDB these days.

What if one does not want a database at all?

[not daSkeptic]

Considering you aren't going to be doing anything sensible with an RDB without using normalisation, it just seemed to be a strange question.

Define sensible.

[a_unique_person]

Define sensible.

I have seen an early version of SAP use DB2 for the database, rather than IMS, which it originally used. All they did was transfer the IMS 'tables' into DB2 tables. No columns, no normalisation. They just used it to store hierarchical data. It was pretty stupid. That changed with the next Release, they normalised most of it for that.

[a_unique_person]

I've found that more data-centric people tend to favor normalization, while process-oriented people like to have everything in denormalized flat files. I was just interested in knowing where you stood with that.

I have yet to see an ERP system where the tables are even in first normal form. I think it has something to do with the practice of using the transaction database for reporting.

SAP is the worlds largest, most popular and most complex ERP system. It is up to something like 30,000 tables now, most of it normalised. It could not work unless it was normalised, because the data is so complex. The transactional data is not in that many tables, but it would be in, about several thousand of them, at a quick guess.

[a_unique_person]

OO and Relational theory are both datacentric. That is why OO is called Object Oriented. Relational Theory is based on a Mathematical Theory, though. Relational Theory also is concerned with process. It is really a matter of how the data is structured. The theoretical basis for an RDB is much sounder than OO.

[not daSkeptic]

I have seen an early version of SAP use DB2 for the database, rather than IMS, which it originally used. All they did was transfer the IMS 'tables' into DB2 tables. No columns, no normalisation. They just used it to store hierarchical data. It was pretty stupid. That changed with the next Release, they normalised most of it for that.

That sounds like a poor use of the technology. How does it follow from this that nothing sensible is done with an RDBMS without normalization?

[not daSkeptic]

The theoretical basis for an RDB is much sounder than OO.

That may be, but does not applicability of any technology depend greatly upon the problem to be solved?

[a_unique_person]

It would, so games or web sites that don't need persistence will not need a database. However, IIRC, Microsoft has now made .Net languages able to process internal tables using SQL commands. A smart move. Relational theory is good for more than just persistance, IMHO.

[not daSkeptic]

It would, so games or web sites that don't need persistence will not need a database.

What about things that do need persistence?

[a_unique_person]

What about things that do need persistence?

Are we playing 20 questions here?

[aggle-rithm]

It would, so games or web sites that don't need persistence will not need a database. However, IIRC, Microsoft has now made .Net languages able to process internal tables using SQL commands. A smart move. Relational theory is good for more than just persistance, IMHO.

Are you talking about LINQ? Very useful in working with aggragate lists. Personally, I don't like to use the SQL-like syntax, which was just added as window-dressing and doesn't behave much like SQL, anyway.

ETA: It looks something like this:

var widgetList = from widgetComponent wc in widgetComponents
where wc.IsReady()
select new widget(widgetComponent)

[aggle-rithm]

That sounds like a poor use of the technology. How does it follow from this that nothing sensible is done with an RDBMS without normalization?

If data integrity is more important than performance, then the more normalized, the better. If performance is more important than data integrity, then denormalized tables are often best.

Denormalized tables are useful in OLAP and other data warehousing technologies.

[aggle-rithm]

OO and Relational theory are both datacentric. That is why OO is called Object Oriented. Relational Theory is based on a Mathematical Theory, though. Relational Theory also is concerned with process. It is really a matter of how the data is structured. The theoretical basis for an RDB is much sounder than OO.

A well-designed database schema allows a system to be reconstructed if the codebase is lost (I know...I've had to do it before in MS Access when all the VBA modules were lost). However, it is difficult to visualize what the process is unless you already know something about it.

On the other hand, a well-designed OO system tends to automatically result in a persistence layer that is good database design. In fact, using Fluent NHibernate, I create the database schema entirely in the code without having to look at the RDMS at all.

Domain Driven Design (IMO) attempts to smooth the differences between data and process by, in part, using some of the same language to conceptualize units of data...for instance, the term "Entity" in DDD is practically interchangable with the same term in database design.

[not daSkeptic]

Are we playing 20 questions here?

No, I'm trying to see if you've actually thought this through.

Once again, what about things that do require persistence? Does not the specifics of those systems determine the applicability of various technologies?

[not daSkeptic]

If data integrity is more important than performance, then the more normalized, the better. If performance is more important than data integrity, then denormalized tables are often best.

Denormalized tables are useful in OLAP and other data warehousing technologies.

This has been my experience as well. Denormalized tables see frequent use in situations where they are not the primary, authoritative source of information, but rather are built from such a primary. In such cases, integrity is enforced elsewhere.

[Leif Roar]

The only industrial strength databases are still the SQL databases

Simply not true. You don't think Hadoop or CouchDB are industrial strength? How about Google BigTable? Is that "industrial strength"?

In fact, there's been a resurgence in the development and use of non-relational databases in recent years, driven partly by the focus on cloud computing and partly by the massive data requirements of actors like Google and Facebook.

[a_unique_person]

This has been my experience as well. Denormalized tables see frequent use in situations where they are not the primary, authoritative source of information, but rather are built from such a primary. In such cases, integrity is enforced elsewhere.

The classic case I have heard of one of the limitations of RDB theory is the bank account balance. You aren't going to have a record of every transaction, and add that up each time someone wants a balance.

That is a valid point, as is the use of reporting tools such as OLAP, although I do wonder at the massive use of resources it takes to build up the result. I wonder if just a regular query would do just as well.

My point was more about OO databases, based on hierarchical concepts, which were proven years ago to be inherently dysfunctional. An OO system based on relational concepts would be, IMHO, a much better direction. Their is nothing inherently wrong with OO, it was just the wrong headed use of hierarchy that has wrong footed it for many years.

[a_unique_person]

Simply not true. You don't think Hadoop or CouchDB are industrial strength? How about Google BigTable? Is that "industrial strength"?

In fact, there's been a resurgence in the development and use of non-relational databases in recent years, driven partly by the focus on cloud computing and partly by the massive data requirements of actors like Google and Facebook.

Parallelism is great, MS SQL Server uses it, and it speeds up large queries significantly.

[not daSkeptic]

My point was more about OO databases, based on hierarchical concepts, which were proven years ago to be inherently dysfunctional.

Your original statement was about persistence, not databases. The two are not necessarily synonymous.

[Leif Roar]

Parallelism is great, MS SQL Server uses it, and it speeds up large queries significantly.

Yes, but what does that have to do with the price of tea in China?

[aggle-rithm]

My point was more about OO databases, based on hierarchical concepts, which were proven years ago to be inherently dysfunctional.

The hierarchical concepts were proven dysfunctional, or the OO databases?

How were they proven dysfunctional?

Not being adversarial, just interested.

[aggle-rithm]

That is a valid point, as is the use of reporting tools such as OLAP, although I do wonder at the massive use of resources it takes to build up the result. I wonder if just a regular query would do just as well.


OLAP works best when the system makes use of command/query separation and inserts and updates are event-driven. If this is the case, then you can have two different systems listening for the events; one the transaction database and one the reporting/OLAP database. The data warehouse would take a lot of resources, but it would be a separate system whose operation doesn't hurt performance of the production system.

[a_unique_person]

The hierarchical concepts were proven dysfunctional, or the OO databases?

How were they proven dysfunctional?

Not being adversarial, just interested.

The hierarchical database, such as the one sold by IBM for many years, was proven to be dysfunctional over time. You had to arrange the data in it's hierarchy, and naturally ran into problems with data that came along later, insertions into the hierarchy, how to relate the data to data not in the hierarchy. It was a dead end, once set in place, the hierarchy was inflexible, it only allowed one direct view of your data.


The RDB then came along, which solved that 'set in concrete' view of your data problem. It was based on mathematical concepts, not ad hoc day dreaming. In a very short period of time, the hierarchical database was consigned to the backwaters of legacy systems and a few dedicated applications that just wanted something simple and inflexible. The RDB rapidly became the most popular database model, and still is, because it works.

The OO concept, while good in many ways, used the hierarchical data model. OO is not intrinsically wrong, but it used a bad meta data organisation. It was supposed to provide multiple inheritance, but that never worked properly, so Java dropped that concept. But even single inheritance still causes problems, when something is not where it should be, or it would be good if it was somewhere else. Java provides interfaces, but you have to code these yourself.

[tesscaline]

The hierarchical database, such as the one sold by IBM for many years, was proven to be dysfunctional over time. You had to arrange the data in it's hierarchy, and naturally ran into problems with data that came along later, insertions into the hierarchy, how to relate the data to data not in the hierarchy. It was a dead end, once set in place, the hierarchy was inflexible, it only allowed one direct view of your data.


The RDB then came along, which solved that 'set in concrete' view of your data problem. It was based on mathematical concepts, not ad hoc day dreaming. In a very short period of time, the hierarchical database was consigned to the backwaters of legacy systems and a few dedicated applications that just wanted something simple and inflexible. The RDB rapidly became the most popular database model, and still is, because it works.

The OO concept, while good in many ways, used the hierarchical data model. OO is not intrinsically wrong, but it used a bad meta data organisation. It was supposed to provide multiple inheritance, but that never worked properly, so Java dropped that concept. But even single inheritance still causes problems, when something is not where it should be, or it would be good if it was somewhere else. Java provides interfaces, but you have to code these yourself.So... To sum up your statements about OO:

Hammers are "dysfunctional" because I cannot use them to saw a board in half.

[Leif Roar]

The OO concept, while good in many ways, used the hierarchical data model.

No it doesn't. Object-oriented programming has a hierarchical type system and, in some sense, a hierarchical system for behaviour, but there is nothing intrinsically hierarchical about the way data is represented in OOP. If anything, OOP lends itself to structuring data as a directed graph.

[not daSkeptic]

The hierarchical database, such as the one sold by IBM for many years, was proven to be dysfunctional over time. You had to arrange the data in it's hierarchy, and naturally ran into problems with data that came along later, insertions into the hierarchy, how to relate the data to data not in the hierarchy. It was a dead end, once set in place, the hierarchy was inflexible, it only allowed one direct view of your data.

This is only a problem if one is trying to apply the technology indiscriminately. All tools have limitations, even relational systems.

The RDB rapidly became the most popular database model, and still is, because it works.

It became popular because it provided a solution to a very common problem. It was not inherently better than other models, it was just better at doing what a lot of people needed.

The OO concept, while good in many ways, used the hierarchical data model. OO is not intrinsically wrong, but it used a bad meta data organisation. It was supposed to provide multiple inheritance, but that never worked properly, so Java dropped that concept. But even single inheritance still causes problems, when something is not where it should be, or it would be good if it was somewhere else. Java provides interfaces, but you have to code these yourself.

Do not confuse type-taxonomy with data-model. They are not the same thing. One could have a complex class-hierarchy of file-types, for instance, and a data-model that's just a set of filenames.

[Wudang]

And don't forget that RDBMSes are not so strong at dealing with hierarchies. See for instance Joe Celko's Trees and Hierarchies where he struggles to deal with some fairly simple* cases.


*for given values of "fairly simple"

[aggle-rithm]

And don't forget that RDBMSes are not so strong at dealing with hierarchies. See for instance Joe Celko's Trees and Hierarchies where he struggles to deal with some fairly simple* cases.


*for given values of "fairly simple"

Dealing with recursive relationships (trees of arbitrary depth) gets ugly really quickly in an RDMS setting.

I found this out when designing an EDI system.

[a_unique_person]

This is only a problem if one is trying to apply the technology indiscriminately. All tools have limitations, even relational systems.



It became popular because it provided a solution to a very common problem. It was not inherently better than other models, it was just better at doing what a lot of people needed.



Do not confuse type-taxonomy with data-model. They are not the same thing. One could have a complex class-hierarchy of file-types, for instance, and a data-model that's just a set of filenames.

I said meta data because I believe that it is just as valid a use of relationships. Why not have classes defined using a relational model? Another hierarchical system that leads to pain is the file system that was developed for C and appears to be the universal model for a file system these days. It is a mess.

Hierarchies are good where needed, a relational database index is implemented as a hierarchy in every product I've used.

What I am questioning is what appears to be the default for many developments, of a data system that is hierarchical, when it was discovered many years ago that it is inherently problematic, for reasons discovered years ago. The newest mess is XML, for example.

[not daSkeptic]

Why not have classes defined using a relational model?

I'm not sure what value, if any, that would have. Object orientation is about behavior, not data.

What I am questioning is what appears to be the default for many developments, of a data system that is hierarchical, when it was discovered many years ago that it is inherently problematic, for reasons discovered years ago.

It's not inherently problematic. It's just limited in a way that relational systems are not. Whether or not that limitation is a problem depends on the situation.

The newest mess is XML, for example.

XML is perfectly fine in some cases. Unfortunately, as with any technology, people sometimes employ it inappropriately.

[a_unique_person]

I'm not sure what value, if any, that would have. Object orientation is about behavior, not data.


Since all computing is about data in some way, the data is important, including the metadata.

[Leif Roar]

Since all computing is about data in some way, the data is important, including the metadata.

There's two things wrong with this argument.

First, and least important, not all computing is about data in some way. A program that calculates the value of pi or the embedded system which controls the anti-lock braking system on your car do not deal with data in this sense at all. (There is a difference between inputs and data.)

Secondly, and more importantly, even though most computing systems do involve data at some level it doesn't follow that data is the only or the central or most interesting aspect of them. For many systems behaviour is the aspect that will need the most modeling. For those systems (and, as data-flow is behaviour, that is most non-trivial systems -- even the data-heavy ones) the implementation language should be tooled more towards matching the behaviour model than the data model.

[a_unique_person]

Pi is your data.

[Leif Roar]

Pi is your data.

You didn't address the second and primary rebuttal of your argument at all.

Anyway, pi is not data in any meaningful sense. The program doesn't even have to store the calculated value of pi anywhere: maybe it's just displaying the most recently calculated digit briefly on screen as part of an art installation. But let's disregard that, and concentrate on the other objection I raised: that even for those computer programs that clearly do deal with data, data is not necessarily the driving aspect of modelling.

[aggle-rithm]

We should probably draw a distinction between data and persistence.

[Leif Roar]

We should probably draw a distinction between data and persistence.

I don't think it's a question so much of persistence as of conceptual integrity: A web-page being sent from a web-server to your browser is clearly a transfer of data (in the meaning "part of the data-model"), even if it's not persisted on either end. However, a value which has no existence1 independently of a program or computer system can not be said to be data in this sense.

Nobody would in all seriousness claim that, for instance, a loop index should be part of the data model. Likewise, button-presses in an elevator control system are not data. They are "merely inputs."


[1] Whether in a raw or transformed form.

[aggle-rithm]

I don't think it's a question so much of persistence as of conceptual integrity: A web-page being sent from a web-server to your browser is clearly a transfer of data (in the meaning "part of the data-model"), even if it's not persisted on either end. However, a value which has no existence1 independently of a program or computer system can not be said to be data in this sense.


That's similar to the way Domain Driven Design draws a distinction between an entity and a value, even though both can be complex data types. The value has no existence independent of an entity.

[not daSkeptic]

The value has no existence independent of an entity.

That's not really correct. A value can indeed exist independently. The distinction lies in how the two define their identity. A value has no identity distinct from its content, whereas an entity does. For example, three Money values that all contain $100.00 are said to be the same (and thus interchangeable). They are distinguished by the information they hold. However, three Employee entities that all have the name John Smith are not necessarily the same. They are distinguished by something else (e.g. employee ID).

[not daSkeptic]

Since all computing is about data in some way, the data is important, including the metadata.

As Leif has already pointed out, this is not true. All computing involves information in some fashion, but not everything necessarily revolves around (or even uses) an organized and managed data-model. Regardless, you're ignoring the other term of the computing equation, which is behavior. Both are required for anything meaningful to be accomplished. Information is pointless if nothing is done with it, and code is pointless if there's nothing for it to operate upon.

Relational theory provides a means of managing complex data-models. Object orientation provides a means of managing complex behavioral-models. The two are designed to handle very different situations. Whether or not those situations exist, and their relative importance, depends on the context. It's naive to just walk into a new project and say, "Let's use Java and MySQL." It may be better to use Ruby and CouchDB, or perhaps Python and flat-files, or even BASH and no persistence whatsoever.

[a_unique_person]

As Leif has already pointed out, this is not true. All computing involves information in some fashion, but not everything necessarily revolves around (or even uses) an organized and managed data-model. Regardless, you're ignoring the other term of the computing equation, which is behavior. Both are required for anything meaningful to be accomplished. Information is pointless if nothing is done with it, and code is pointless if there's nothing for it to operate upon.

Relational theory provides a means of managing complex data-models. Object orientation provides a means of managing complex behavioral-models. The two are designed to handle very different situations. Whether or not those situations exist, and their relative importance, depends on the context. It's naive to just walk into a new project and say, "Let's use Java and MySQL." It may be better to use Ruby and CouchDB, or perhaps Python and flat-files, or even BASH and no persistence whatsoever.

The "Third Manifesto" outlines an extension of the RDB to include

*code with native access to the RDB
*much better SQL which is easier to use
*definition of OO that is inherently part of the RDB, not just hack tacked onto it.

It was written specifically to address the behaviour of data or objects.

It combines the two elegantly. I would really like to see the result of as much effort had been put into this as into the current OO fad.

I still don't see why so many data structures by default are tree based, such as the average file system.

[not daSkeptic]

The "Third Manifesto" outlines an extension of the RDB to include

*code with native access to the RDB
*much better SQL which is easier to use
*definition of OO that is inherently part of the RDB, not just hack tacked onto it.

It was written specifically to address the behaviour of data or objects.

It combines the two elegantly.

Do you understand the purpose of the relational model?

I still don't see why so many data structures by default are tree based, such as the average file system.

Think outside the computer. What hierarchies exist in the physical world?

[a_unique_person]

Do you understand the purpose of the relational model?


Yes, also the hierarchical model.



Think outside the computer. What hierarchies exist in the physical world?

Plenty. Why does it seem to be the default structure for software development? There are more options.

[not daSkeptic]

Yes, also the hierarchical model.

What is the purpose of the relational model? Why was it created?

Why does it seem to be the default structure for software development?

What makes you think it's the default?

[aggle-rithm]

The "Third Manifesto" outlines an extension of the RDB to include

*code with native access to the RDB
*much better SQL which is easier to use
*definition of OO that is inherently part of the RDB, not just hack tacked onto it.

It was written specifically to address the behaviour of data or objects.


This looks good on paper, but I believe that persistence and behavior are two separate issues, and should not be shoehorned into the same model. Perhaps that is why this hasn't been developed more thoroughly.


It combines the two elegantly. I would really like to see the result of as much effort had been put into this as into the current OO fad.


The current OO fad has been going on for about 25 years.


I still don't see why so many data structures by default are tree based, such as the average file system.

Many schemas in a RDMS are tree based as well. Just follow the dependencies through foreign keys and the tree structure begins to emerge.

On the other hand...with a lot of systems moving towards a distributed model, the structure is often dislocated at several carefully chosen points so parts of the structure can act independently. In many cases, these autonomous modules can make good use of a non-relational storage method.

[aggle-rithm]

The truth is, OO solves all the problems it was intended to solve IF USED CORRECTLY. The same is true of the SQL/relational model...there is nothing to keep a clueless organization from putting all their data into a single denormalized "God Table".

When I was doing tech support for Microsoft Access, there was an unfortunate lady who was having trouble with a database she had been putting together for several months. The more tables she added to it, the harder it was to enter new records.

Turns out all the tables had one-to-one constraints placed on them, so to insert a record in one you had to simultaneously insert records in all the others.

I used Viseo to draw up a more rational database design, then sent it to her with instructions to start over.

[aggle-rithm]

Why does it seem to be the default structure for software development? There are more options.

I'm sure it's the default structure for most enterprise software development, just because it matches up well with the actual conditions it's designed to model. I can see where there would be other applications (scientific, mathematical, etc.) in which different approaches might work better.