Programming Trends to Follow?

TjW said:
And wonderfully, when it breaks, you're not responsible. No worries!
Click to expand...

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)?
 
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?
 
TjW said:
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?
Click to expand...

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.
 
hodgy said:
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.
Click to expand...

Yep. Cloud-sitting Joe won't make those mistakes. Why, the company is ISO9000 certified, and practices six sigma, and stuff.
 
TjW said:
And wonderfully, when it breaks, you're not responsible. No worries!
Click to expand...

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.)
 
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.
 
a_unique_person said:
The only industrial strength databases are still the SQL databases, and OR mapping is just a nasty kludge.
Click to expand...

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.
Click to expand...

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.
 
Last edited:
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.
 
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.
 
a_unique_person said:
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.
Click to expand...

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.
 
Wudang said:
Evidence?
Click to expand...
;) 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.
 
a_unique_person said:
;) 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?
Click to expand...

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.
 
You must log in or register to reply here.

Back
Top Bottom