Look back at the early / mid 1990's and if there was one paradigm that would rule the world after that, it was the everything would Object Oriented after that. I was pro-OO as a general idea also, and still am, but I believe that there are still stuff to solve. But hey, that wasn't the early 1990's, everything OO was supposedly good. SQL with OO extensions (remember the ORDBMS ideas? I still have Stonebreakers book, and it's worth reading, but nothing much came out of it).
I think there are a whole bunch of reasons why OO didn't end up being as important as it was foreseen to be back then (it's still important and widely used, I know that, but if you were there in the early 1990's OO rage, you could even go to the bathroom or have a beer without creating an object, and as we realize, after a few of those "Beer objects" it turns more and more difficult to create them), and you could go to a bar and chat a lady up without getting involved with polymorphism (and that is NOT a "bad" disease, and if you are not into OO, it's supposed to be a good thing. But ladies in bars rarely understand that).
Anyway, back to the original discussion. What killed the all encompassing OO world was, among other things, the web. Once WWW was stamped in every ones heads, all such theoretical stuff as OO was pushed to the side, and more traditional, but simple, efficient and workable solutions such as PHP and MySQL came around, none of them terribly OO.
So assuming that OO didn't die, but became less important (as did those consultants of those days that didn't write single line of code, or set up a single server in the world or anything, but despite this was the highest paid in the industry, because they were "OO consultants". Writing diagrams, and charts and going to meeting, expecting that awful code to write itself, so they didn't have to. Once that era was over, some of their firms got prestigious jobs at solid and reliable companies such as Enron). That was a long parenthesis, by the way, I'm getting good at that.
Whoa, will I ever get to the point? Yeah, yeah, I'm getting there. One thing on everybodies mind at the time was 32 bit computing and the next Windows release, Windows 95! Windows 95 used the "new" Windows 32-bit API Win32 (Hey, Microsoft marking had a long thought about THAT name), to replace Windows 3.11 and predecessors 16-bit... (You get a hug from me if you can guess the answer) Win16.
So one might think that Microsoft would be smart now. Win32 was a good API, tried in Windows NT and was solid and reliable. And a solid 32 bit API it was and is (I was programming in Win16 way back in 1992 or so). So the new cool GUI features of Windows 95 that would revolutionize the world and create world peace (except possibly for parts of the middle east, they had to wait til Windows 98) would just be added to the, now rather massive, Windows 32 API. That was easy to use as it was now clean 32-bit (Win16 was a mix, at beat) and doing it in C would make it easy to add any cool OO technologies on top of that. That's the good thing with C, you can interface just about anything to it. So this was NOT what Microsoft did.
No, the power of OO was still in effect during the time when Windows 95 was developed. OK, of the main applications languages on Windows at the time, few, among them C, Visual Basic and them some weirdo scripting stuff like "Hypercard" (Oh please, let's forget that. Don't bring that up again!). No, Microsoft invented COM. Which is a pure OO layer. And OO is the future!
Well, there is an issue there. Doing full OO on top of non-OO is pretty easy, the other way around not. So COM turned out to be much less complex than expected, as it had to interface with VB and stuff like (people had large stopped caring for C now, it wasn't OO you know. But VB was easy to "use" (which means that anyone can write useless and bad code in no time at all) so that was OK. And in the process, Microsoft wanted to convert the C people into C++ developers, so here came MFC.
Now, the world of OO wasn't as simple as that, not even for dear old Microsoft. Even though stuff like Informix had an OO SQL, and C++ was OO as was Smalltalk and a bunch of other languages, and some had had OO "extensions" added to them (the technical terms for OO features in a non-OO language is "lipstick on a pig"), this was not as bright and shiny. C was known for being reasonably portable and simple to access, but that was because the concepts of C are based on something fundamental, which is how a computer works. And int datatype is what the CPU sees as an integer. A pointer is a CPU reference. Easy to understand and use, once you get the idea.
The would of OO though was based firmly in a swamp of OO consultants driving the world of OO and IT and world peace (see above) by shouting at each other and when that didn't help, writing long book, documents and drawings, that they threw at each other. Results was not world peace, surprisingly, but that we ended up with OO that was there and that worked, but that was different all over the place. Some had multiple inheritance, others didn't. Some were basically non-OO and had had some OO lipstick painted on them by some high-ranking OO consultant, and some were so OO that basically the only keyword in the language used was object. And some had interfaces and others didn't. And some implementations of some OO stuff had templates, others didn't (you know who you are, but I am not naming names here). And they were all objects, and they were all incompatible, to to the rescue came, not the good lord, but the web. And all this OO stuff was left as it is, and forgotten about.
So here I am, finally getting to the point. I am working on my MyQuery MySQL Query Tool version 3.1 now, and most of it is done. It's pretty packed with cool features for a DBA and all that. Since version 3.0 I have also had dictionary views. These were useful, and you could double-click on, say, a table in one of them, and it would be pasted to the editor window. Useful, yes, but the way to do such an operation, i.e. copying data from one window to another, should be done with Drag-and-Drop. And Drag-and-Drop first appeared in Windows 95, and it does require some OO language, actually. It is very OO. Gosh! I have a text here, I take it with the mouse, drag it to another window, and release the mouse button, why can't I do that I do any other things? Like interacting with the mouse? You need to know when the mouse comes to a window? Handle a message! When it leaves a Window? Handle a message! When a button is clicked? Well, fact is, you handle a message! UNLESS! You are entering the window whilst dragging something! Then you need to create a whole bunch of COM objects! Why in heavens name is this necessary?
Well, that last question I can't answer, but I have been digging into this now on and off for a few weeks, and I know now that COM isn't as bad as it looked from the start. COM really is implemented in C anyway, it's just the Microsoft has done a crap job out of telling you how this works and has only provided a select number of interface, where they tell how the interfaces works from the user of the interface POV, such as a VB developer gets to know how to do this or that, but not how it gets from an OO COM object into a distinct non-OO VB application.
Well, that was the case until now. Eat my dust, Billy Gates! In the course of creating Drag-and-Drop for MyQuery, I felt this such a useful effort for someone else (and myself in future projects), that I implemented a generic C layer on top of stupid COM. I looked at what it takes to do a simple Drag-and-Drop with COM in VB and with MFC Com objects. Tell you what, my approach means less code. It really does. I only expose very few functions, and once that is done, to drag: Call two functions (both in my library), simple. And then to register for a Drag operation (this is not the kind of "Drag operation" that you can get by a shady doctor in San Francisco though) is two simple calls. And when an object is called, what happens? You have two choices: A callback function is called, or, hold your breath: A message is received. With all the data you need!
The library will be on Sourceforge, or possibly somewhere else, shortly.
And just to be clear. I don't mind OO. But I donät think OO as a generic concept was never done right! Which is why the importance of OO has diminished, in my mind. Java is OO alright, but this is more a convenience than a fundamental driving factor behind it, it just makes developers job easier, hopefully, which of course isn't bad per se, but we hoped for more, much more. And we did NOT look forward to, 15 years later, spending two weeks of dragging the non-objects out of COM, just to support bl**dy Drag-and-Drop!
/Karlsson
Not being 100% objective here
5 comments:
Heh, I bet you knew I'd bite :-)
COM/DCOM was Microsoft's answer to IBM's SOM/DSOM and the world of CORBA and ORBs.
Where SOM had multiple inheritance and polymorphism. COM had interfaces. By that aspect, some pundits would say that COM was "Object-based" and not "Object orientated".
I don't know if any other CORBA ORB's objects had the kind of extensibility which SOM had.
Onwards to drag-and-drop. For Windows 3.1, DDE was used, which essentially were a bunch of window events and shared memory. IBM then used DDE to implement drag-and-drop on OS/2 ... and because IBM held the patents to that and OLE, Microsoft had to do something else. Enter the COM objects. Tada! No need to wrangle with IBM over the patents, especially as IBM was PO over the OS/2 NT 3 contract fiasco.
A lot of things which Microsoft did not have a license to use was stripped out of the OS/2 NT 3 codebase before Microsoft sold it under a different product name. Incidentally, the sword cuts both ways - HPFS was among Microsoft's intellectual property which is why OS/2 had an antiquated 16-bit IFS driver even though Microsoft already had a 32-bit port.
Hi Anders,
hehe, had a few good laughs over your post. But I don't agree though :)
I agree the oo hype is over. But I think you do underestimate the importance of OO at least somewhat. Many languages and frameworks suport "just enough" OO so you can use it when you need it.
Some quotes and opinions:
"What killed the all encompassing OO world was, among other things, the web."
Killed? Hardly. In fact, modern javascript frameworks are based almost entirely on object oriented javascript. Perhaps the term "the web" is too general for these claims. I do believe the majority of the server side is not object oriented, but I see more an more of it at the client side.
"the technical terms for OO features in a non-OO language is "lipstick on a pig"
What do you mean exactly with "non-OO language"? A language that allows programming without using an OO paradigm, the OO-languages being the ones that don't allow programming outside such a paradigm? If that is the case, then I disagree. For example I very much like PHP5 because it allows OO programming, but doesn't require it. Its OO features are functional and can help productivity a lot but don't bite a classical non-oo programming style.
"...to to the rescue came, not the good lord, but the web. And all this OO stuff was left as it is, and forgotten about."
If you don't count the huge number of installations of Java application servers that are used mostly for intranet applications and middleware.
Roland!
Your points are taken, but what I am discussion that was in the 1990 was not how OO exists today. Look at things like ORB and DCOM that would rule the world. OO was infrastructure. Gone were databases and stuff like that, instead we would have high-level objects composed of other objects, and working and developing here was to be just a question of "combining" objects.
OO is there today, absolutely. But OO today is more a convenience to a developer and the team that builds the solution (which is, by the way, how I would have liked it in the first place).
JS has OO features, as has VB, C++ and Java. But if you try to interface those with eachother, you will have a problem. You cannot take a Java object, and access that, with all it's interfaces, methods, members, templates, inheritance and what have you not, from, say C#. But that was exactly how a lot of people were looking at the world back then. Objects were the rule, and their attributes and how the were designed. The immplementation was a distant second.
This is what I maen what I say the Web killed OO. It didn't kill OO as a productivity tool for us developers. But it DID kill OO as that grand solution to everything, where programming consisted of dragging objects over eachother.
As for a non-OO language that is "sort-of" OO, I wasn't referring to, say, PHP (but I and not keen on the OO features of PHP either. But they are how I like them to be, a convenience, which you also point out). I was more thinking along the lines of COM objects accessible from VB, which was a result of just those grand ideas of that era, which ended up nowhere.
And you have to admit that the amount of code you have to write in VB, CV++ or whatever when using COM is rediculous. I just want to drag a piece of text for heavens sake! Look at how COM tries to porce you to do cut and paste the same way. It's useless, and actually a big non-convenience, it makes the OO guys job look nice, with state diagrams, and stuff, but the develops job SOO much more difficult, close to impossible.
For reference of OO gone really bad, lok at this: http://www.grahamwideman.com/gw/tech/Delphi/dragdrop/DragDropTheory.htm
And this is what you, supposedly, should have to deal with to drag the text "foo" from one Window to the other. Just silly.
Use OO for developer and infrastructure convenience, and where it makes sense, yepp, I agree, that is where I want it.
And to finish up, among other bad things of COM is DCOM, which is there, bydefault, to share components among Windows computers. Good idea back then, and it is still there. Problem is that some of those distributed components are viruses...
But all in all, I take your points and agree with what you say, maybe I was in a not-so-good mood. But spending 2 weeks for a bl**dy drag-and-drop makes things like that to me.
/Karlsson
Anthony!
Thanx for replying. You filled in a few gaps in my knowledge of COM history (I sure HOP it is history!). As for Object Oriented vs. Object Based, I had actually forgotten that debate! Ha ha ha! Seenomg those non-code-writing consultants getting red in their faces in a debate over VB not being OO but OB! And the poor VB guy who had to solce a problem and, and, and this is the bad, bad part, actually write code! Stop writing code, for heavens sake, you are supposed to write state diagrams and drag objects!
I think it was a surprise to those OO guys with their nice blue-ish constumes that computers actuallt execute CODE not state diagrams or dragged objects. But even if it wasn't a surprise, I'm sure they felt it wasn't THEIR task to fix that.
/Karlsson
Hi Anders,
thanks for clarifying. When I started in the industry, I remember people musing about this:
"instead we would have high-level objects composed of other objects, and working and developing here was to be just a question of "combining" objects."
too, but I think they called it: "component based development" (and indeed, these were almost always and exclusively COM objects).
Indeed, with this context:
"This is what I maen what I say the Web killed OO. It didn't kill OO as a productivity tool for us developers. But it DID kill OO as that grand solution to everything, where programming consisted of dragging objects over eachother."
I agree with you: webservices is the preferred glue to tie systems together.
The UML sequence diagrams for the drag drop interactions are hilarious! Imagine hashing out the design for an entire application like that...
Anyway, thanks for explaining :)Turns out we don't disagree at all.
Post a Comment