It's a good description of the problems of ORM and their possible resolutions.
Personally, I prefer to interact with a relational database via a good query builder. The advantage of a query builder is that you inevitably end up with dozens of slightly different queries. With a query builder you can make a query just like another, but with slightly different constraints or joins or whatever you like.
You can then populate objects with said queries when it make sense, and do other non-objecty operations like reporting and search. The entire point of an object system is to reduce coupling, so IDK why people are so eager to tightly couple their programming model to storage.
But about the Vietnam part... really, that's a shocking analogy. The overlong, painfully US-centric military history part could be completely excised. I didn't even understand the title at first. Vietnam is not solely defined by America's failed attempt to ~~napalm it into submission~~ nobly preserve democracy.
The entire point of relational algebra was also to reduce coupling... let's couple them!
Though to be fair, I suspect the relational approach became popular more because it was easier/faster than because it was flexible. ORM popularity then makes sense.
I agree that the Vietnam war exposition was very odd and out of place for a technical article. Gavin King (creator of hibernate/nhibernate) has always said ORM's are just a tool in a box and encouraged people to use what's appropriate[1]. I often see project teams adopting an ORM and attempting to shoehorn all database access into the ORM framework they've adopted. Needless to say, these teams grow to hate their ORM, with good reason.
The way this manifests in applications is often times a frontend client making several calls to the ORM backend for lists of objects, then mixing, matching, swizzling the data to what needs to be displayed to the user when a single call to a well crafted query would save bandwidth, improve application responsiveness, and be easier to debug and maintain.
It is relatively easy to draw a clear line between using ORMs for domain model persistence (complex, stateful CRUD) and SQL for relational model interaction (complex, stateless querying). It really comes down to: don't use ORMs for querying and don't use SQL for complex CRUD
Convincing a team to choose the best approach based on the situation is the hardest thing to do in the universe. It's got to be an all-or-nothing decision!
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.
Have worked on 9 teams in the past 5 1/2 years or so, and 0 of them had the wherewithal to choose the optimal data access strategy on a situational basis. So, 100%, not 99.9% :-)
I was dating a Vietnamese woman a little while ago. This eventually, inevitably came up. It is extremely difficult to defend a US policy that measures "success" as a body count metric. The Vietnamese people vividly remember this, I don't think it's appropriate to make flip comparisons to a humanitarian catastrophe perpetrated by people the likes of Henry Kissinger in multiple countries, with body counts of millions.
One two year spell with Hibernate was the end of all flirtations with ORM at our gaff. "No transparent persistence shall be the sum of transparent persistence."
ORM is the Vietnam of Computer Science, because OOP is the Vietnam of Computer Science: A 25-year failed experiment in boosting productivity of masses of mediocre programmers using this one true silver bullet.
OOP is the most popular paradigm because it works the best for the greatest number of people and projects. It's natural to break large systems into component parts recursively, and to let components have their own state.
What alternative did you have in mind? Functional programming?
Since you seem confident that your understanding of OOP is better than that of "misinformed" people like me who don't think that coupling state and function is completely orthoganal OOP, can you explain what isn't completely orthoganal?
A succinct definition of OOP would be nice to combat the misinformation you're complaining about.
The description of OOP provided in the Wikipedia article on programming paradigms [1] matches my current understanding of OOP.
> object-oriented which groups code together with the state the code modifies,
Maybe that's a little too succinct, because I think it's also worth noting how [2]
> In OOP, computer programs are designed by making them out of objects that interact with one another.
I certainly wouldn't consider coupling state and function completely orthogonal to OOP though. I doubt most other programmers would either.
I guess this might demonstrate the inertia of the so-called misinformation, but when the majority disagree with your definition of a term, you might want to step back and consider whether you're the one who's misinformed.
The fundamental ideas of OOP are pervasive data privacy and the consequent synchronization via message passing. Now, many OO languages have badly butchered that, but that is the idea, as in Smalltalk: Objects are opaque participants in a colloquy.
I'm not sure where you got "the majority disagree with your definition of the term" when I didn't even attempt to define the term until this reply! Or why you key on the word "orthogonal" which is in the parent of my comment, and certainly is imprecise: A better description would be, OOP holds no exclusive claim to these ideas. We don't all despise OOP, but rather the false notion that it is a "silver bullet." I quite like well done OOP with expressive types.
I'd be irritated by you linking to Wikipedia articles for "Programming paradigm" and OOP except they're mobile links, which means you're getting all in a hissy on the go, and that's sorta cute.
I probably put too much stock in the "As is" at the beginning of your post.
A hissy is a good description of my last comment lol. I was getting pretty annoyed at people claiming that my understanding of OOP is wrong. I don't think OOP should be this incomprehensible thing.
I now understand that you just meant that not all encapsulation is OOP. I certainly agree there. Cheers.
OOP does not start with Smalltalk, but rather with Simula 67 a decade earlier.
Simula 67 - not Smalltalk - was the main force that drove Bjarne Stroustrup to extend C into C++ and the rest history:
While Smalltalk did enjoy a period of mild popularity in the late 80s early 90s and went on to influence other languages like Objective C and Ruby, the mainstream of OOP was defined by C++ and later Java.
These languages viewed focused on statically determined method dispatch rather than message-passing, but this is a feature of their older lineage rather than the butchering of the original pristine form of OOP which never was.
I'd go a little further than Wikipedia however - in my book you need to have a variable that represents more variables. In Java you can do this with a class and an object of that class. In C you can do this with a struct. Both languages are capable of being OOP. Now, in both languages you can also make mistakes, as a programmer. In Java I can decide to make a class called "Monitor" that has a bunch of static methods to control the monitor... such as on/off, change resolution, etc... I would personally consider that a poor design, because while in 1990 a computer had 1 monitor, in 2017, a computer may have unlimited monitors (think controlling monitors over a network for example).
We can make the same mistake of assuming a single monitor in Java or C, but both languages can also easily support multiple monitors ;)
> I certainly wouldn't consider coupling state and function completely orthogonal to OOP though. I doubt most other programmers would either.
The point I was making is that this is not an idea invented by, or reserved for, OOP.
If there's anything somewhat unique to OOP approach (both Smalltalk-like and Java-like), it's constructing the program as a graph of objects communicating with each other (be it via methods or messages).
> but when the majority disagree with your definition of a term, you might want to step back and consider whether you're the one who's misinformed.
Here's the thing: the majority of popular software engineering books were written during the OOP fad. They like to mix up OOP-specific things with universal techniques, making the latter look like a feature (or invention) of the former. A good cure for that is to grab something from pre-OOP era. Consider e.g. reading SICP (or watching SICP lectures) - it's the first book that made me realize just how much concepts popularly associated with OOP are paradigm-independent ways of structuring programs.
TL;DR: OOP did not invent abstraction, it only appropriated it.
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.
And now we're slinging obnoxious insulting mud. Lovely. Thank you for your contribution. I'm going to be that guy. Citation please, even one statement anywhere by an author if an OOP language or of a book on OOP where they say it's the only way to do that.
They don't have to say it, it's implied by omission. When OOP proponents keep repeating that it breaks a program into smaller, more manageable parts, it's easy for beginning programmers to assume that this is a defining feature of OOP and that it's somehow specific to it.
It depends- basically, the approach is to not think of OOP as the default approach, just one of the tools in the box.
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.
What other paradigm focuses on components with encapsulated state? Definitely not functional! Isn't any nounish "thing" with state an object anyways? Why else could it be?
Because there are no "nounish" things. It is a false construct.
Also see Actor model or "out of the tarpit". Also Barbara Liskov "Programming with Abstract Data Type". Encapsulating state instead of behaviours is a mistake.
Simula objects were not a Actor like, they were exactly like today object. Smalltalk originally was like Actors, and it is what spawned the idea in Hewitt mind.
Our Objects of today come straight from Simula.
Edit : and yes, there is a reason i said behaviour and not state. Objects are bad at encapsulating state, because you do not encapsulate state like that.
Contrary to popular belief, OOP doesn't really encapsulate state, it just hides it. Encapsulated state should mean state that does not contribute to the global state space of the system. The danger of OOP is that one ends up with a combinatorial explosion of possible states your system may be in. This may be desired in some situations (e.g. simulations) but does not make a good general approach.
Note that functional languages are also capable of building stateful systems this way, for example Erlang actors or composing finate-state automata.
> If a module has state, is it not named with a noun, is not an object even if we try calling it an entity, an actor, or anything else?
But we're talking about OOP, which is characterized by specific logical properties surrounding modelling, encapsulation and extension, not about colloquial terms like "objects" that are referred to by nouns.
Conflating colloquial language with the programming language is one of many reasons why OOP seems seductive but is often misleading.
My current hypothesis on OOP[1] is that it because popular simply because it was the easiest way to get GUIs to work. I don't see any other critical reason for its rise.
[1] And I could have tested this hypothesis by doing more background reading of the history, but I haven't.
> My current hypothesis on OOP[1] is that it because popular simply because it was the easiest way to get GUIs to work.
Not sure it was the easiest way (see IMGUI), but I agree with you that some early UI frameworks took that approach and it was probably so much better than what came before it, that OOP is still riding that wave of enthusiasm.
I cannot upvote this enough. The "silver bullet" bit is the primary point, though I'll say I've found very few actual uses of OOP-as-described-in-the-mainstream in my ~30 year carreer.
The only problem with that sales pitch is that you don't actually have to combine all of them into a single concept ("OOP"). They are pretty much all orthogonal.
[1] That's was actually called Abstraction before "OOP" was invented as "a thing" in the mainstream. Well, it still is, but it's just that it applies beyond "public/private/package" scope (and the like). For example, O'Caml has "modules" which give you abstraction at what would be equivalent to Java's package scope. Amazing, I know. /s
[2] To be fair, I was absolutely entranced by the promise of implementation interitance[3]: What can I say, I was young and naive, and knew only Turbo Pascal and Delphi. With considerably more experience I consider it a fundamental mistake to include such a construct in your language.
[3] As was the rest of the industry, at least I had the excuse of inexperience. Such mistakes we've (collectively) made! :)
Are there actual facts to back up claims to productivity boosts or failures with a given paradigm across large numbers of programmers and organizations?
I'm not a big fan of Java or C++, but they have been used to write tons of code running software that's complex and in wide use.
Maybe a functional, non-mutable approach is better, but until it has a similar widespread use and enough time for people to complain about it and suggest new superior paradigms, I'm not sold on the truth of these claims.
It sounds more like preference and opinion than fact. Also, I can't help but wonder if it's the C++/Java model of OOP that's more than issue than OOP itself. Would the same complaints be made of Smalltalk? Personally, I prefer the OOP of Ruby than that of Java, and don't really see a problem with using it.
I'm not a big fan of Java or C++, but they have been used to write tons of code running software that's complex and in wide use.
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.
"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."
That's it. Rigid ideology is the real problem. In software engineering and other areas too, eg politics.
> Are there actual facts to back up claims to productivity boosts or failures with a given paradigm across large numbers of programmers and organizations?
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. :)
Actually most of us do not have a choice, OOP languages, tools and frameworks are usually forced upon us. At least OOP languages are finally adopting functional features, but if one really wants to favour immutability and composition (modern OOP advice), one needs a functional-first language.
OOP isn't the problem, the problem is putting faith in the concept of silver bullets. OOP is a useful technique, like many others. I've seen "overly OOP" code that will make your head spin, but more often than not I've seen code that could have been a bit more object oriented. The problem is the cargo cult mentality that you can just follow something formulaically and then magically you'll get amazing results.
There are plenty of highly useful techniques and tools, including OOP, but you have to do the work, you have to apply the techniques skillfully and conscientiously. You have to know when you're just adding complexity with your design and when you're managing it well.
Well, let's unpack this a bit. No Silver Bullet – Essence and Accident in Software Engineering[1] was written in 1986 by Turing Award winner and author of The Mythical Man Month Fred Brooks.
His thesis was that there was no single technology or technique which by itself promises even one order of magnitude of improvement within a decade.
However, he did write this of OOP:
"Object-oriented programming. Many students of the art hold out more hope for object oriented programming than for any of the other technical fads of the day. I am among them" [2]
In addition to OOP, the biggy he identified was reuse, mostly in COTS.
"A disciplined, consistent effort to develop, propagate, and exploit these innovations should indeed yield an order-of-magnitude improvement. There is no royal road, but there is a road."
20 years after the original essay, there was a retrospective at OOPSLA. Here is what Brooks had to say[3]:
"Of the candidates enumerated in 'NSB', object-oriented programming has made the biggest change, and it is a real attack on the inherent complexity itself. The most promising attack continues to be re-use, and re-use of COTS programs in particular. "
And of course he is absolutely right. OOP has delivered massive increases in productivity, we are successfully tackling problems of far bigger complexity than we did back then. Just as a small example, the WWW was invented by a single person in a couple of months in his spare time! On NeXTStep a highly OO platform. Replicating that with lesser tech took a team a year, and they had to leave out editing, which was in the original.
And of course we reuse OO libraries/frameworks all the time, and really don't take notice of this anymore. Write an application on iOS or Android, and you are reusing vast amounts of OO code.
So the idea that OO is a failed "silver bullet" is nothing short of ridiculous. It has succeeded, and in succeeding has pushed us against new frontiers of our ignorance.
> And of course we reuse OO libraries/frameworks all the time, and really don't take notice of this anymore. Write an application on iOS or Android, and you are reusing vast amounts of OO code.
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.
I don't see how "other things work as well" is a good counter-argument to "OO works well".
Of course, things like libpng and libjpeg are for fairly small and more importantly well-contained functionality, so simpler reuse mechanisms are sufficient.
Anyway, you are entitled to your opinion, however at odds it is with reality.
My point was you didn't establish a causation anywhere. We have lots of software written in OOP, yes, but you didn't (and can't, really) prove that it wouldn't have been written without OOP. There are and have been APIs that work just fine without OOP, so it doesn't seem like not having OOP was barrier to entry. FFmpeg is doing fine without OOP, by the way, and so is Linux.
Here is how I can read the last few decades - software started becoming more and more popular, and in the beginning of the 90s people jumped on the OO hype/bandwagon (and haven't let go ever since). Now, OOP done wrong was worse than procedural done wrong, but since the hype and koolaid were so strong, and the fast-growing market really needed the software, programmers have just plowed through, DESPITE OOP. Classic Starcraft story, jump to "Game engine architecture" - http://www.codeofhonor.com/blog/tough-times-on-the-road-to-s... . My point being, you can release software even when you get held back by OOP.
Another thing that you failed to do is comprehend my message. Of course we have a lot of OO frameworks, since OOP is the most popular programming paradigm. If functional were the most popular then you would have a lot of FP frameworks. You're using argumentum ad populum, basically.
Without controlled experiments we cannot "establish" causation. However, citing things that work with OOP certainly disproves that OOP doesn't work. You can then fall back to the weaker position of "OOP doesn't matter", but it certainly does work.
Anyway, I certainly did a LOT more to make my case than you did, because all you did was make ever wilder claim, even claiming hypotheticals as absolute truth with ZERO backup whatsoever.
I gave the example of the WWW App. Written on NeXTStep/Objective-C, which is the closest the Smalltalk-like OOP and frameworks you could get at the time. One guy, a couple of months in his spare time. Editing included (largely because he was reusing an existing class library). 5KLOC. From scratch. Inventing.
NCSA Mosaic was created on top of non OO X-Windows and later Windows and Mac. 5 people, a year, 100KLOC, just copying something that already existed. No editing. So arguably lesser functionality, 20x the code, 10x or more the development effort.
So if your point is that OO doesn't work, you have utterly and completely failed to make that point. In fact, you just list projects that succeeded with OOP and then claim without any evidence whatsoever that they succeeded "despite" OOP.
A: "Rockets don't work".
B: "Here are some rockets launching satellites into space"
A: "But you don't understand, these satellite launched despite the rockets"
B: <stepping away slowly> "OK, whatever makes you happy."
And you are reversing cause and effect. How do you think OOP became popular? Because it allowed us to tackle larger projects more easily.
Try to back off the religion a little and look at actual evidence.
Does that mean OOP is the be-all and end-all of Software Development? Nope. At least I think not and I certainly hope not. Because it is deeply flawed, just like all of our current paradigms are deeply flawed (and IMHO FP is flawed even more, but that's another discussion). However, it was a lot less flawed than what preceded it, and therefore allowed us to get a lot more done. Or maybe not even less flawed, but had more useful points that compensated.
And I gave you the example of Starcraft, where the use of OOP actually slowed them down. And it had ever so slightly more than 5KLOC, so it's probably a better way to illustrate OOP's pitfalls.
> NCSA Mosaic ... just copying something that already existed.
Not familiar with Mosaic's history, but what you appear to be describing is porting an OO codebase to a non-OO codebase, which is not an easy feat. I know some OO codebases that are so tangled in various layers of inheritance and composition that it is only natural to be a lot of effort involved. And generally, porting isn't always a clear-cut affair; for example, straight ports from PCs to consoles are rarely straight, unless you're using a generic engine that will do that for you.
> So if your point is that OO doesn't work, you have utterly and completely failed to make that point.
No, my point was your argument by popularity is flawed, and you don't seem to have graped it. Read my original comment.
> In fact, you just list projects that succeeded with OOP
Even the author of that piece describes "the horror of the class hierarchy" and how OOP gave them a hard time. You can travel between cities with the handbreak on, but that doesn't mean you should.
> "But you don't understand, these satellite launched despite the rockets"
This analogy is so flawed I'm not going to even bother dissecting it, that's just lazy on your part.
> here are productivity numbers:
From where I gather we should all be using Haskell or something.
> And you are reversing cause and effect. How do you think OOP became popular?
C++, Java, marketing, marketing, marketing.
> Try to back off the religion a little and look at actual evidence.
Quite so. Show me evidence that OOP is better than other programming paradigms.
> Show me evidence that OOP is better than other programming paradigms.
Huh? Why should I? I was responding to someone who claimed that OO had "failed".
It hasn't, and for non-failure, existence is quite sufficient (and no, this is not the "proof by popularity" you keep talking about for no particular reason I can surmise). Fact is that we have been able to successfully tackle much larger projects (and finish them with less code) than previous paradigms.
In addition, the very person who wrote about "No Silver Bullets" predicted that OOP (which was new at the time) was one of closest things to a SB that he sees, and 20 years later confirmed that estimation. He took a little harder look than you did.
> From where I gather we should all be using Haskell or something.
You should improve your reading skills. Haskell language level is 8.5, Objective-C is 12.0, Smalltalk is 15.0. Higher is better.
Once again, I wouldn't claim that OO is "best", though right now it is probably one of the least bad we have. However, the evidence is overwhelming that it hasn't "failed". (And no, single projects failing doesn't mean OO failed. And you are probably going to have more failed OO projects than other paradigms, simply because there are more OO projects).
> [NCSA Mosaic] Not familiar with Mosaic's history
Then how about you don't make specious claims about it??
> Write an application on iOS or Android, and you are reusing vast amounts of OO code.
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.
ORM frameworks in many languages such as Ruby, Python, Java, etc. have improved enormously since that time. I think they'll continue to improve as metaprogramming facilities improve, it is very feasible to convert an expression like 'x>2*y-7' from conventional programming languages to SQL and other query languages.
Also there is immense interest in document databases such as CouchDB, Marklogic, Elasticsearch, DynamoDB, etc. These solve some of the problems of object-relational mapping, and we will someday see new frameworks.
ORM frameworks in the languages you listed primarily act as mutating state functions. So, to be honest: no, they haven't improved enormously at all.
If your framework doesn't work first-and-foremost on immutable objects on which defined state transforms can be applied, you're putting your foot in a bucket that's very hard to extricate yourself from.
Data mappers are pretty much the only reasonable mode, it seems. And they kinda suck, but they suck much less.
I came here to say that too. Back then ORM:s were clunky because the languages (Java) and techniques we were using were clunky.
For example, the article talks about object identity and equality. Nowadays, you would try and design your data so that object identity doesn't matter because that works better with the functional paradigm.
He also discusses how to map inheritance to database tables, but that is a moot point -- people don't use inheritance to model data anymore. The old "an Employee class is an instance of a Person class and has a reference to a Manager class which is also a Person-instance" thinking isn't used anymore.
We're trained not to compare things to the holocaust because it's in bad taste. Somehow lessons of how to treat other people don't translate from case to case. Us soldiers in Vietnam were supposed to be bad people doing inhumane things but US soldiers in Iraq somehow aren't. History keeps repeating and even though we remember it, we always think this time is special.
I'm most often hearing about the Iraq war in terms of "bad things <coalition forces> did". Not sure where you get the positive-sounding perspective (the most positive thing I ever hear is "Saddam was even worse").
Satan Hussein. He was considered even worst than Hitler and soldiers carried freedom to Iraq, how the army was called? freedom coalition force). It was the opposite.
Yeah, no kidding. It was distracting and a low-grade insult to those who endured the real Vietnam war. Maybe it sounded better in 2006... Trump fatigue has really dampened my sense of humor.
Interesting article but I feel like the metaphor is a little shallow. There are plenty of troublesome topics in computer science that could be compared to Vietnam in the same way, it just feels a little excessive to compare those things to war.
I did end up getting sucked into reading a lot of history about the actual war, turns out TFA should probably be split into two, one about the tech aspect and one about the pure history. The history section was well written.
A classic, the information about Vietnam isn't really relevant but I still find it interesting. Ran into this post back when I was busy implementing ORM's in umpteen different languages myself, and I remember that it motivated me to keep looking for better ways. Lately, I got the chance to sidestep the whole issue and implement my own persistence from the ground up in Snackis (https://github.com/andreas-gone-wild/snackis/tree/master/src...). It is still based on tables and records, but having them available as first class objects helps bridge the gap considerably.
At one time, I was in that object, relational, etc. stuff. Some people wanted all that stuff combined into some one, unified thingy.
My conclusion: The whole was a mess. Better just to leave the separate pieces separate.
One
of the pieces was, sure, relational data base.
Then there was the international work on CMIS/P -- IIRC common management informaiton system/protocol. This work seemed to want to model the world and everything in it, but really the goal was how do define and specify data for real time computer and network system management.
This work was object oriented and, thereby, open to a lot of confusion: Really, what the work was talking about was just some data, say, describing a printer. So, there be fields with data -- character strings, numbers, arrays, etc. All it was was just data; that is, there was no associated code; no subroutines or functions to call; no applications programmer interfaces (API). The object part was that the definition of data from/for printer A could draw from, inherit from, the definition from printer B, etc.
The next part was something we called Resource Object Data Model (RODM). So, the idea was that in real time management of server farms and networks, there could be several different programs trying to manage different aspects of the work, communicating with the same computer or network node, and causing conflicts. So the idea was to have a system, RODM, to present to all the programs trying to manage a single view of the servers and networks to be managed, a single view that would handle locking, exclusive access, cache data from the servers and networks, etc. So, RODM was a hierarchy, say, something like a file system hierarchy. At the leaves were objects that described parts of the servers or networks. The objects were active in the sense that they could run their own, if you will threads of execution, set timers, respond to timers, send and receive messages with other objects, the servers, the networks, programs doing the management, etc. All the hierarchy and objects were dynamic in the sense, much like in a file system, they could be created, changed, and deleted all during real time operations. RODM had some curious, tricky stuff: Could reserve an address space just for data. An address space for code could jump into another address space for code and execute code there. Etc.
One role for RODM was for programs to do system management based on AI (expert systems) to have RODM to talk to as model of the servers and networks being managed.
It flopped.
I contributed a little: Part of such management is detecting and correcting problems in real time. Some of the problems are ones never seen before. So, I worked up how to detect those problems, with known, adjustable false alarm rate, etc. So, that was to be a much better approach to anomaly and early problem detection than we could expect
just from the usually intended uses of expert systems.
But, really, as for the OP, it was all too complicated.
> Johnson’s successor, Republican $g(Richard Nixon), tried several tactics to bring pressure to the NVA/VC forces to bargain [...]
One such tactic the author fails to mention was the successful effort to undermine Johnson's peace negotations by doing illegal covert dealings with the South Vietnamese through Nixon's underlings. Nixon was undermining the negotiations between the U.S. executive branch and North/South Vietnam when Nixon was still a candidate, encouraging the South to hold out until after the election.
You can read about it and much more in Christopher Hitchens' "The Trial of Henry Kissinger." Regardless of one's opinion of Hitchens, he refers to unclassified documents and many other reputable sources in his section on this.
The only reason I mention it here is because the author has attempted to flesh out an analogy with what I must assume were supposed to be the salient details of each item being compared. To do that and leave out the fact that a presidential candidate undermined the acting president's effort to end the war is quite strange.
Also, I'd be interested to hear the author explain what "regular violations of nearby Laos and Cambodia" actually means.
"There were more than 580,000 bombing missions on Laos from 1964 to 1973 during the Vietnam War. That's equivalent to one bombing mission every eight minutes, 24 hours a day, for nine years. Over two million tons of ordnance was dropped on the country, with up to 30 per cent failing to explode as designed."
More than 40 years after the war, one-third of the country is still contaminated by unexploded ordnance — an ongoing cost of war that affects the Lao people daily.
I'd be interested to hear the author explain what "regular violations of nearby Laos and Cambodia" actually means.
The same bombing campaign hit both countries similarly. Laos seems to have been slightly worse off, but the concept applies to both countries. The information at the museum in Cambodia will broadly inform the Laos situation. Besides if there is a similar resource in Laos I'm unaware of it.
Oh, I assumed the museum would be more about the Khmer Rouge. In fact Wikipedia says
> The landmines in Cambodia were placed by different governments and factions (including the Lon Nol, Khmer Rouge, the Heng Samrin and Hun Sen regimes, as well as the Coalition Government of Democratic Kampuchea who, with international support retained the UN seat throughout much of the 1980s) that clashed during the Civil War in Cambodia in the 1970s and 1980s
I believe you are correct about the Khmer Rouge period being the source of the bulk of the Cambodian problem, however the museum's collection was quite comprehensive. It's been too long since I visited (and it seems they have since been forced to relocate) for me to be certain of what if any of the collection covers US secret war period, but I'm certain that I saw American made mines in their collection.
My visit to this museum sticks with me to this day, and my desire to promote it is perhaps out of place on this specific topic.
I stand by all of my other links as being directly relevant.
ah yes, "the vietnam of computer science." a classic. never forget. can't wait for "the holocaust of programming." heard good things about "ethnic cleansing and compiler theory" too.
Interesting how "The Vietnam of ..." assumes the US viewpoint as the default.
From the Vietnamese viewpoint, the war could (for example) be seen as underdog patriots resisting waves of invaders possessing an overwhelming material and technical superiority and utterly defeating them through sheer willpower and sacrifice, thus gaining a nation of their own.
Which would make a paper titled "The Vietnam(War) of Computer Science" a description of some kind of breakthrough in CS, attained after a tremendous struggle.
So yes, dumb analogy. The paper would read as well without the bullshit title.
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
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,
You mistakenly assume that all Vietnamese were on the same side in the war. Millions of Vietnamese lost that war to domestic forces who would never allow free speech, free elections, etc., armed by foreigners (Soviets) who never allowed free speech, free elections, etc.
The Vietnamese who cut my hair here in Silicon Valley possess nothing remotely resembling what you naively call "the Vietnamese viewpoint."
"You mistakenly assume that all Vietnamese were on the same side in the 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.
> 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'.
Well stated, but in this case, a civil war with North Vietnamese on one side and South on the other, your statement does not read well:
> From the Vietnamese viewpoint, the war could (for example) be seen as underdog patriots resisting waves of invaders
Had you said, from the North Vietnamese viewpoint, fair enough.
97 comments
[ 2.7 ms ] story [ 143 ms ] threadPersonally, I prefer to interact with a relational database via a good query builder. The advantage of a query builder is that you inevitably end up with dozens of slightly different queries. With a query builder you can make a query just like another, but with slightly different constraints or joins or whatever you like.
You can then populate objects with said queries when it make sense, and do other non-objecty operations like reporting and search. The entire point of an object system is to reduce coupling, so IDK why people are so eager to tightly couple their programming model to storage.
But about the Vietnam part... really, that's a shocking analogy. The overlong, painfully US-centric military history part could be completely excised. I didn't even understand the title at first. Vietnam is not solely defined by America's failed attempt to ~~napalm it into submission~~ nobly preserve democracy.
Though to be fair, I suspect the relational approach became popular more because it was easier/faster than because it was flexible. ORM popularity then makes sense.
The way this manifests in applications is often times a frontend client making several calls to the ORM backend for lists of objects, then mixing, matching, swizzling the data to what needs to be displayed to the user when a single call to a well crafted query would save bandwidth, improve application responsiveness, and be easier to debug and maintain.
It is relatively easy to draw a clear line between using ORMs for domain model persistence (complex, stateful CRUD) and SQL for relational model interaction (complex, stateless querying). It really comes down to: don't use ORMs for querying and don't use SQL for complex CRUD
[1] https://www.reddit.com/r/programming/comments/2cnw8x/what_or...
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.
OOP is the most popular paradigm because it works the best for the greatest number of people and projects. It's natural to break large systems into component parts recursively, and to let components have their own state.
What alternative did you have in mind? Functional programming?
A succinct definition of OOP would be nice to combat the misinformation you're complaining about.
The description of OOP provided in the Wikipedia article on programming paradigms [1] matches my current understanding of OOP.
> object-oriented which groups code together with the state the code modifies,
Maybe that's a little too succinct, because I think it's also worth noting how [2]
> In OOP, computer programs are designed by making them out of objects that interact with one another.
I certainly wouldn't consider coupling state and function completely orthogonal to OOP though. I doubt most other programmers would either.
I guess this might demonstrate the inertia of the so-called misinformation, but when the majority disagree with your definition of a term, you might want to step back and consider whether you're the one who's misinformed.
[1] https://en.m.wikipedia.org/wiki/Programming_paradigm
[2] https://en.m.wikipedia.org/wiki/Object-oriented_programming
I'm not sure where you got "the majority disagree with your definition of the term" when I didn't even attempt to define the term until this reply! Or why you key on the word "orthogonal" which is in the parent of my comment, and certainly is imprecise: A better description would be, OOP holds no exclusive claim to these ideas. We don't all despise OOP, but rather the false notion that it is a "silver bullet." I quite like well done OOP with expressive types.
I'd be irritated by you linking to Wikipedia articles for "Programming paradigm" and OOP except they're mobile links, which means you're getting all in a hissy on the go, and that's sorta cute.
A hissy is a good description of my last comment lol. I was getting pretty annoyed at people claiming that my understanding of OOP is wrong. I don't think OOP should be this incomprehensible thing.
I now understand that you just meant that not all encapsulation is OOP. I certainly agree there. Cheers.
We can make the same mistake of assuming a single monitor in Java or C, but both languages can also easily support multiple monitors ;)
The point I was making is that this is not an idea invented by, or reserved for, OOP.
If there's anything somewhat unique to OOP approach (both Smalltalk-like and Java-like), it's constructing the program as a graph of objects communicating with each other (be it via methods or messages).
> but when the majority disagree with your definition of a term, you might want to step back and consider whether you're the one who's misinformed.
Here's the thing: the majority of popular software engineering books were written during the OOP fad. They like to mix up OOP-specific things with universal techniques, making the latter look like a feature (or invention) of the former. A good cure for that is to grab something from pre-OOP era. Consider e.g. reading SICP (or watching SICP lectures) - it's the first book that made me realize just how much concepts popularly associated with OOP are paradigm-independent ways of structuring programs.
TL;DR: OOP did not invent abstraction, it only appropriated it.
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.
Also see Actor model or "out of the tarpit". Also Barbara Liskov "Programming with Abstract Data Type". Encapsulating state instead of behaviours is a mistake.
Grand parent is talking specifically about encapsulating state and not just behaviors.
Our Objects of today come straight from Simula.
Edit : and yes, there is a reason i said behaviour and not state. Objects are bad at encapsulating state, because you do not encapsulate state like that.
2. Where you do want them, like at coarser service boundaries, virtually all general purpose languages have modules of some sort.
2. If a module has state, is it not named with a noun, is not an object even if we try calling it an entity, an actor, or anything else?
But we're talking about OOP, which is characterized by specific logical properties surrounding modelling, encapsulation and extension, not about colloquial terms like "objects" that are referred to by nouns.
Conflating colloquial language with the programming language is one of many reasons why OOP seems seductive but is often misleading.
[1] And I could have tested this hypothesis by doing more background reading of the history, but I haven't.
Not sure it was the easiest way (see IMGUI), but I agree with you that some early UI frameworks took that approach and it was probably so much better than what came before it, that OOP is still riding that wave of enthusiasm.
Polymorphism, sure! Composition, sure! Information Hiding[1], sure! Modularity, sure! Implementation inheritance, ooh, sounds interesting[2].
The only problem with that sales pitch is that you don't actually have to combine all of them into a single concept ("OOP"). They are pretty much all orthogonal.
[1] That's was actually called Abstraction before "OOP" was invented as "a thing" in the mainstream. Well, it still is, but it's just that it applies beyond "public/private/package" scope (and the like). For example, O'Caml has "modules" which give you abstraction at what would be equivalent to Java's package scope. Amazing, I know. /s
[2] To be fair, I was absolutely entranced by the promise of implementation interitance[3]: What can I say, I was young and naive, and knew only Turbo Pascal and Delphi. With considerably more experience I consider it a fundamental mistake to include such a construct in your language.
[3] As was the rest of the industry, at least I had the excuse of inexperience. Such mistakes we've (collectively) made! :)
I'm not a big fan of Java or C++, but they have been used to write tons of code running software that's complex and in wide use.
Maybe a functional, non-mutable approach is better, but until it has a similar widespread use and enough time for people to complain about it and suggest new superior paradigms, I'm not sold on the truth of these claims.
It sounds more like preference and opinion than fact. Also, I can't help but wonder if it's the C++/Java model of OOP that's more than issue than OOP itself. Would the same complaints be made of Smalltalk? Personally, I prefer the OOP of Ruby than that of Java, and don't really see a problem with using 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.
That's it. Rigid ideology is the real problem. In software engineering and other areas too, eg politics.
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. :)
Note that it has never been "proved" that OOP is more productive than anything else either.
There are plenty of highly useful techniques and tools, including OOP, but you have to do the work, you have to apply the techniques skillfully and conscientiously. You have to know when you're just adding complexity with your design and when you're managing it well.
Well, let's unpack this a bit. No Silver Bullet – Essence and Accident in Software Engineering[1] was written in 1986 by Turing Award winner and author of The Mythical Man Month Fred Brooks.
His thesis was that there was no single technology or technique which by itself promises even one order of magnitude of improvement within a decade.
However, he did write this of OOP:
"Object-oriented programming. Many students of the art hold out more hope for object oriented programming than for any of the other technical fads of the day. I am among them" [2]
In addition to OOP, the biggy he identified was reuse, mostly in COTS.
"A disciplined, consistent effort to develop, propagate, and exploit these innovations should indeed yield an order-of-magnitude improvement. There is no royal road, but there is a road."
20 years after the original essay, there was a retrospective at OOPSLA. Here is what Brooks had to say[3]:
"Of the candidates enumerated in 'NSB', object-oriented programming has made the biggest change, and it is a real attack on the inherent complexity itself. The most promising attack continues to be re-use, and re-use of COTS programs in particular. "
And of course he is absolutely right. OOP has delivered massive increases in productivity, we are successfully tackling problems of far bigger complexity than we did back then. Just as a small example, the WWW was invented by a single person in a couple of months in his spare time! On NeXTStep a highly OO platform. Replicating that with lesser tech took a team a year, and they had to leave out editing, which was in the original.
And of course we reuse OO libraries/frameworks all the time, and really don't take notice of this anymore. Write an application on iOS or Android, and you are reusing vast amounts of OO code.
So the idea that OO is a failed "silver bullet" is nothing short of ridiculous. It has succeeded, and in succeeding has pushed us against new frontiers of our ignorance.
[1] https://en.wikipedia.org/wiki/No_Silver_Bullet
[2] http://worrydream.com/refs/Brooks-NoSilverBullet.pdf
[3] http://dl.acm.org/citation.cfm?id=1297973
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.
Of course, things like libpng and libjpeg are for fairly small and more importantly well-contained functionality, so simpler reuse mechanisms are sufficient.
Anyway, you are entitled to your opinion, however at odds it is with reality.
Here is how I can read the last few decades - software started becoming more and more popular, and in the beginning of the 90s people jumped on the OO hype/bandwagon (and haven't let go ever since). Now, OOP done wrong was worse than procedural done wrong, but since the hype and koolaid were so strong, and the fast-growing market really needed the software, programmers have just plowed through, DESPITE OOP. Classic Starcraft story, jump to "Game engine architecture" - http://www.codeofhonor.com/blog/tough-times-on-the-road-to-s... . My point being, you can release software even when you get held back by OOP.
Another thing that you failed to do is comprehend my message. Of course we have a lot of OO frameworks, since OOP is the most popular programming paradigm. If functional were the most popular then you would have a lot of FP frameworks. You're using argumentum ad populum, basically.
Without controlled experiments we cannot "establish" causation. However, citing things that work with OOP certainly disproves that OOP doesn't work. You can then fall back to the weaker position of "OOP doesn't matter", but it certainly does work.
Anyway, I certainly did a LOT more to make my case than you did, because all you did was make ever wilder claim, even claiming hypotheticals as absolute truth with ZERO backup whatsoever.
I gave the example of the WWW App. Written on NeXTStep/Objective-C, which is the closest the Smalltalk-like OOP and frameworks you could get at the time. One guy, a couple of months in his spare time. Editing included (largely because he was reusing an existing class library). 5KLOC. From scratch. Inventing.
NCSA Mosaic was created on top of non OO X-Windows and later Windows and Mac. 5 people, a year, 100KLOC, just copying something that already existed. No editing. So arguably lesser functionality, 20x the code, 10x or more the development effort.
So if your point is that OO doesn't work, you have utterly and completely failed to make that point. In fact, you just list projects that succeeded with OOP and then claim without any evidence whatsoever that they succeeded "despite" OOP.
A: "Rockets don't work".
B: "Here are some rockets launching satellites into space"
A: "But you don't understand, these satellite launched despite the rockets"
B: <stepping away slowly> "OK, whatever makes you happy."
Oh, and here are productivity numbers:
http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm
And you are reversing cause and effect. How do you think OOP became popular? Because it allowed us to tackle larger projects more easily.
Try to back off the religion a little and look at actual evidence.
Does that mean OOP is the be-all and end-all of Software Development? Nope. At least I think not and I certainly hope not. Because it is deeply flawed, just like all of our current paradigms are deeply flawed (and IMHO FP is flawed even more, but that's another discussion). However, it was a lot less flawed than what preceded it, and therefore allowed us to get a lot more done. Or maybe not even less flawed, but had more useful points that compensated.
Exactly my point.
> However, citing things that work with OOP certainly disproves that OOP doesn't work.
Spaghetti code works too, you can make anything work. Question is if it works better.
> all you did was make ever wilder claim
I mean, do I really need to repeat what people have been saying for decades? http://harmful.cat-v.org/software/OO_programming/
> I gave the example of the WWW App.
And I gave you the example of Starcraft, where the use of OOP actually slowed them down. And it had ever so slightly more than 5KLOC, so it's probably a better way to illustrate OOP's pitfalls.
> NCSA Mosaic ... just copying something that already existed.
Not familiar with Mosaic's history, but what you appear to be describing is porting an OO codebase to a non-OO codebase, which is not an easy feat. I know some OO codebases that are so tangled in various layers of inheritance and composition that it is only natural to be a lot of effort involved. And generally, porting isn't always a clear-cut affair; for example, straight ports from PCs to consoles are rarely straight, unless you're using a generic engine that will do that for you.
> So if your point is that OO doesn't work, you have utterly and completely failed to make that point.
No, my point was your argument by popularity is flawed, and you don't seem to have graped it. Read my original comment.
> In fact, you just list projects that succeeded with OOP
Even the author of that piece describes "the horror of the class hierarchy" and how OOP gave them a hard time. You can travel between cities with the handbreak on, but that doesn't mean you should.
> "But you don't understand, these satellite launched despite the rockets"
This analogy is so flawed I'm not going to even bother dissecting it, that's just lazy on your part.
> here are productivity numbers:
From where I gather we should all be using Haskell or something.
> And you are reversing cause and effect. How do you think OOP became popular?
C++, Java, marketing, marketing, marketing.
> Try to back off the religion a little and look at actual evidence.
Quite so. Show me evidence that OOP is better than other programming paradigms.
Huh? Why should I? I was responding to someone who claimed that OO had "failed".
It hasn't, and for non-failure, existence is quite sufficient (and no, this is not the "proof by popularity" you keep talking about for no particular reason I can surmise). Fact is that we have been able to successfully tackle much larger projects (and finish them with less code) than previous paradigms.
In addition, the very person who wrote about "No Silver Bullets" predicted that OOP (which was new at the time) was one of closest things to a SB that he sees, and 20 years later confirmed that estimation. He took a little harder look than you did.
>> productivity numbers: http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm
> From where I gather we should all be using Haskell or something.
You should improve your reading skills. Haskell language level is 8.5, Objective-C is 12.0, Smalltalk is 15.0. Higher is better.
Once again, I wouldn't claim that OO is "best", though right now it is probably one of the least bad we have. However, the evidence is overwhelming that it hasn't "failed". (And no, single projects failing doesn't mean OO failed. And you are probably going to have more failed OO projects than other paradigms, simply because there are more OO projects).
> [NCSA Mosaic] Not familiar with Mosaic's history
Then how about you don't make specious claims about it??
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.
ORM frameworks in many languages such as Ruby, Python, Java, etc. have improved enormously since that time. I think they'll continue to improve as metaprogramming facilities improve, it is very feasible to convert an expression like 'x>2*y-7' from conventional programming languages to SQL and other query languages.
Also there is immense interest in document databases such as CouchDB, Marklogic, Elasticsearch, DynamoDB, etc. These solve some of the problems of object-relational mapping, and we will someday see new frameworks.
If your framework doesn't work first-and-foremost on immutable objects on which defined state transforms can be applied, you're putting your foot in a bucket that's very hard to extricate yourself from.
Data mappers are pretty much the only reasonable mode, it seems. And they kinda suck, but they suck much less.
For example, the article talks about object identity and equality. Nowadays, you would try and design your data so that object identity doesn't matter because that works better with the functional paradigm.
He also discusses how to map inheritance to database tables, but that is a moot point -- people don't use inheritance to model data anymore. The old "an Employee class is an instance of a Person class and has a reference to a Manager class which is also a Person-instance" thinking isn't used anymore.
I did end up getting sucked into reading a lot of history about the actual war, turns out TFA should probably be split into two, one about the tech aspect and one about the pure history. The history section was well written.
Same point, far less inflammatory.
My conclusion: The whole was a mess. Better just to leave the separate pieces separate.
One of the pieces was, sure, relational data base.
Then there was the international work on CMIS/P -- IIRC common management informaiton system/protocol. This work seemed to want to model the world and everything in it, but really the goal was how do define and specify data for real time computer and network system management.
This work was object oriented and, thereby, open to a lot of confusion: Really, what the work was talking about was just some data, say, describing a printer. So, there be fields with data -- character strings, numbers, arrays, etc. All it was was just data; that is, there was no associated code; no subroutines or functions to call; no applications programmer interfaces (API). The object part was that the definition of data from/for printer A could draw from, inherit from, the definition from printer B, etc.
The next part was something we called Resource Object Data Model (RODM). So, the idea was that in real time management of server farms and networks, there could be several different programs trying to manage different aspects of the work, communicating with the same computer or network node, and causing conflicts. So the idea was to have a system, RODM, to present to all the programs trying to manage a single view of the servers and networks to be managed, a single view that would handle locking, exclusive access, cache data from the servers and networks, etc. So, RODM was a hierarchy, say, something like a file system hierarchy. At the leaves were objects that described parts of the servers or networks. The objects were active in the sense that they could run their own, if you will threads of execution, set timers, respond to timers, send and receive messages with other objects, the servers, the networks, programs doing the management, etc. All the hierarchy and objects were dynamic in the sense, much like in a file system, they could be created, changed, and deleted all during real time operations. RODM had some curious, tricky stuff: Could reserve an address space just for data. An address space for code could jump into another address space for code and execute code there. Etc.
One role for RODM was for programs to do system management based on AI (expert systems) to have RODM to talk to as model of the servers and networks being managed.
It flopped.
I contributed a little: Part of such management is detecting and correcting problems in real time. Some of the problems are ones never seen before. So, I worked up how to detect those problems, with known, adjustable false alarm rate, etc. So, that was to be a much better approach to anomaly and early problem detection than we could expect just from the usually intended uses of expert systems.
But, really, as for the OP, it was all too complicated.
One such tactic the author fails to mention was the successful effort to undermine Johnson's peace negotations by doing illegal covert dealings with the South Vietnamese through Nixon's underlings. Nixon was undermining the negotiations between the U.S. executive branch and North/South Vietnam when Nixon was still a candidate, encouraging the South to hold out until after the election.
You can read about it and much more in Christopher Hitchens' "The Trial of Henry Kissinger." Regardless of one's opinion of Hitchens, he refers to unclassified documents and many other reputable sources in his section on this.
The only reason I mention it here is because the author has attempted to flesh out an analogy with what I must assume were supposed to be the salient details of each item being compared. To do that and leave out the fact that a presidential candidate undermined the acting president's effort to end the war is quite strange.
Also, I'd be interested to hear the author explain what "regular violations of nearby Laos and Cambodia" actually means.
"There were more than 580,000 bombing missions on Laos from 1964 to 1973 during the Vietnam War. That's equivalent to one bombing mission every eight minutes, 24 hours a day, for nine years. Over two million tons of ordnance was dropped on the country, with up to 30 per cent failing to explode as designed."
http://www.maginternational.org/the-problems/the-uxo-problem...
More than 40 years after the war, one-third of the country is still contaminated by unexploded ordnance — an ongoing cost of war that affects the Lao people daily.
video at http://abcnews.go.com/International/americas-secret-war-laos...
also a worthwhile visit http://www.cambodialandminemuseum.org/
There may be many other violations, but I think that's a credible start.
That doesn't appear to be about Laos though?
I'd be interested to hear the author explain what "regular violations of nearby Laos and Cambodia" actually means.
The same bombing campaign hit both countries similarly. Laos seems to have been slightly worse off, but the concept applies to both countries. The information at the museum in Cambodia will broadly inform the Laos situation. Besides if there is a similar resource in Laos I'm unaware of it.
> The landmines in Cambodia were placed by different governments and factions (including the Lon Nol, Khmer Rouge, the Heng Samrin and Hun Sen regimes, as well as the Coalition Government of Democratic Kampuchea who, with international support retained the UN seat throughout much of the 1980s) that clashed during the Civil War in Cambodia in the 1970s and 1980s
https://news.ycombinator.com/item?id=14873083
So it's not clear to me that has anything to do with the US presence in Vietnam.
My visit to this museum sticks with me to this day, and my desire to promote it is perhaps out of place on this specific topic.
I stand by all of my other links as being directly relevant.
keep us posted.
Sometimes we have RDBMS but more the times we have Redis and shit. You can't organize all sources of data under the same umbrella and it's painful.
From the Vietnamese viewpoint, the war could (for example) be seen as underdog patriots resisting waves of invaders possessing an overwhelming material and technical superiority and utterly defeating them through sheer willpower and sacrifice, thus gaining a nation of their own.
Which would make a paper titled "The Vietnam(War) of Computer Science" a description of some kind of breakthrough in CS, attained after a tremendous struggle.
So yes, dumb analogy. The paper would read as well without the bullshit title.
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,
The Vietnamese who cut my hair here in Silicon Valley possess nothing remotely resembling what you naively call "the Vietnamese viewpoint."
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.
> 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'.
Well stated, but in this case, a civil war with North Vietnamese on one side and South on the other, your statement does not read well:
> From the Vietnamese viewpoint, the war could (for example) be seen as underdog patriots resisting waves of invaders
Had you said, from the North Vietnamese viewpoint, fair enough.
Most pubsub frameworks fail to do any better. Mostly because people don't realize how useful Cursor is.