Hmm will MS ever get the web?

Sharing information. Tightening up the holes (instead of just putting a band-aid over them). The things they don't do, in other words; which make the web work.

The Big Bet

M$ is betting with your time and your sweat and your money.

Sweet deal for them.

If you don't want a bumpy ride, quit reinventing the wheel.

-HJC

@No, they don't get it., @And people develop with this

Microsoft insist on things that boil down to inserts selects and deletes, because that's what the back end is. I don't see the Ado.Net for entities to be a competing framework with Linq, it just solves a different problem.

In fact Data model architecture, despite being rubbished by people who think everything's an object referenced by and only by it's id, because they can only program in one language (usually c# or Java,) is in fact usually much faster than it's Domain model architecture equivalent. Data model architectures provide the ability to do _everything_ that object relational domain model architectures can do, but have the additional quality of a structure to the data.

I recently had an email from a mate describing how a load of "I've read software design in a Sun guide to selling more hardware design book, object relational types" came in and insisted pulling a basket full of skus from a database, and then checking the stock count via stored procedure for each is faster than simply returning the offending stock levels with the basket. How ridiculous. It was 30% easier for the DB to just give them the answer than to give them the data to work it out.

That said, the problem with the eponymous hibernate is not just the technology itself, but it's use encouraging the lazy into the failure to have balanced tiers, but when all you have is a hammer what can you expect?

Anyway, I foresee SQL Server's and Oracle's future generations to be genuine object stores, with tables migrating to lists, and Fields being objects themselves whose member variables become statically typed or strongly typed reference objects (FK); and the next versions of SQL to be more like Linq than anything else. Should scare the wits out of the Adabas crowd having a database that is truly object-hierarchic-relational.

Linq is a superset of SQL, and it's power is not in simply using it to parse objects. It's power is in two parts, its high level nature, and its fundamental distributed mechanism.

int thingsToDoCount =

(from r in myDiskFile

from row in myDatabaseTable where r.name == row.name

from tb in mySelectionBox.SelectedItems where tb.vale == r.name

from l in myInMemoryList where l.lastModifiedTime < row.Changed

from c in crm.Account where c.AccountType = "Business Account"

where c.name = r.name

select 1).Count();

Hardly rocket science to see why this will have less errors in it (and probably be faster for the average programmer) than the equivalent 200 lines of code in 3gl is it?

My view is that we should be coding in the highest level language that is scalable. Though I recognise there's a load of people out there who like programming for programming's sake, and don't really care about completer finishers, or performance.

It used to be that all those guys did c, because they loved its side effects. These days they all seem to be writing hibernate apps (before delivery - and leaving very before the second delayed delivery date) with the assumption that hibernate can handle multi million object aggregated transactions as well as a system designed predominantly for nothing else.

I remember when everyone thought XML was epic, it should be used for everything. Then people started realising that it took more time to unpack a 25 million element xml document than to rewrite the code.