Problems with Object/Relational Mapping (2006)

99.9% of the teams in the world are out there right now, either cranking out reams of unnecessarily boilerplate CRUD, or else torturing their application and database performance trying to get their ORM to accomplish things for which it is not at all suited.

My favorite question. Have a look at the sidebar in this link [1] for starters (by 'alternative' you didn't mean you expect me to advocate complete abolishment of OOP did you?). I'd say being familiar with at least 5-10 diverse paradigms from that list works wonders.

[1] https://en.wikipedia.org/wiki/Programming_paradigm

The biggest lie OOP ever told was that breaking things into smaller components is specific to OOP

When you have a algorithm that goes Red-Hot, use Data-Orientated-Programming.

When you have lots of annonymous objects repeatetly passing through recombined pipelines, with minimal work, try a functional approach.

Try to see OOP not as the final stage of a masterpiece, rather as the launch-pad - and a first working version.

Also- what is the best approach, highly depends upon the goals of the project. Speed at all cost? Safety trumps all? Rapid development? Scale-ability?

PS: Regarding Object-Relational Databases- i found the true nest of snakes to be that for each object basically a small hand crafted version of git is needed to resolve the changes, once several applications start using the same DB. Not only that, but changes made, that relate to the changed data, needs to propagate- and can not do so only by simple trigger, but often by program-logic.

Sloppy work can lead to data fragments being part of two separate objects. What if two programs use one of two classes, but one resides within the other? Who has the right of update?

In addition ORM can hold duplicates of a Datum, and very soon, the urge will appear to replace every datafragment in your saved object with a pointer (key) to one, and only one instance of the real-world data piece.

TL,DR; This is one of the cases, where the pain comes not instantly, but after a while - and then never leaves. Get somebody who witnessed something like that blow up in another company to help you avoiding the worst.

It's a novice mistake to think the solution that wins out is the one with the most technical merit. Virtually nothing is truly meritocratic.

> It's natural to break large systems into component parts recursively, and to let components have their own state.

That's just modularity. Nearly every language has it, and OOP is merely one way to achieve it.

If other languages were used, perhaps they would not need to be so complex and resource-consuming, but this is also why any "actual facts" which you're looking for are difficult to find: you'd need to essentially do the same project multiple times in different languages and perform a very highly controlled comparison, and there are numerous other confounding factors. Failures or successes alike can easily be spun into blaming the languages.

IMHO there is no one perfect paradigm for everything, and the only failure is in promoting one as panacea or trying to view all of programming in the same way. I think trying to classify languages or code as strictly OOP, procedural, functional, etc. and shunning "hybrids" or even basic common-sense pragmatism for dogmatic purity has had the greatest negative effect on productivity.

NO. Functional people claim that, but never had a proof, since there aren't that many people using it to build large systems. Thus this myth lives on. :)

That's a really bad argument. We reuse vast amounts of non-OO code too(libpng, libjpeg, libwhatever). We don't reuse code because it's written in a paradigm, but because we need it. Since OO spread like a virus (some argue it was for the better, I argue it was for the worse) and is now the most popular paradigm, it makes sense it will have produced lots of frameworks, but it doesn't mean OOP was needed to write and use them.

Right on. So many passionate arguments amongst developers could be cut off at the pass if people simply accepted that in computing the answer is always...

It depends.

OOP is a useful and powerful abstraction for logical, artifical situations, like modelling a mobile platform.

Its a completely crap solution for modelling real world, gray situations like "employee ISA person".

Unfortunately, "employee is a person" is the first example that many people think to trot out to explain OOP, since it is easily understood by the recipient.

That doesn't appear to be about Laos though?

From Wikipedia, the Vietnamese apparently refer to the war as the "Resistance War Against America" or "the American War" [1]. A CS paper named after this would be interesting.

"ORMs - the CS Resistance War Against America" , or even "The America of Computer Science" :-P

[1] From https://en.wikipedia.org/wiki/Vietnam_War

The Vietnam War (Vietnamese: Chiến tranh Việt Nam), also known as the Second Indochina War,[56] and known in Vietnam as the Resistance War Against America (Vietnamese: Kháng chiến chống Mỹ) or simply the American War,

Lol, I don't assume anything of the kind.

But when you talk of a war at high level, you identify the viewpoints by generic terms.

"The Confederates thought that England and France would come to their aid" is valid, even when there were people in the Confederacy whose beliefs were the opposite.

Likewise the Royalists who shifted to/were exiled to London after American Independence would call the victorious Americans rebels and traitors to the Crown and Mother England.

You don't have to have every single American in the War of Independence to anti-British to talk about "the Americans had soured on 'taxation without representation' ", or demand that every single Briton be anti- American to say "From the British point of view the war appeared to be stalled."

It is understood that these usages refer to distinct sides in a war, even in the presence of factions who may fight for 'the other side'.

Likewise with the Algerians who left for France. And the Afghans who fought along US troops who are leaving for the USA.(make that 'trying to leave' in the age of Trump).

The Vietnamese who cut your hair in Silicon Valley are by definition no longer Vietnamese citizens. They are Americans and have nothing to do with how the war is viewed by the majority of the Vietnamese living in Vietnam.

Many Americans were against the Vietnam war too. But there still was an American war effort, an American strategy and so on.

With your level of hair splitting, you couldn't generalize about anything ever, because you could always dig up some unlikely exception. Which would makes history books ... interesting ... to read and write. Every sentence would have to be prefixed by 'Most of ', 'by and large, ' and so on.

There is no absolute view point on anything in History. There will always be dissenters.

Well duh.

All of which has nothing to do with the point about the perils of naming CS papers from specific political viewpoints, and how shifting these viewpoints would change the import of such names.