The Artima Developer Community
Sponsored Link

Weblogs Forum
Back at OOPSLA

48 replies on 4 pages. Most recent reply: Mar 29, 2007 12:25 PM by Isaac Gouy

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 48 replies on 4 pages [ « | 1 2 3 4 | » ]
James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Back at OOPSLA Posted: Oct 26, 2006 11:27 AM
Reply to this message Reply
Advertisement
> Now, sure you could design object types in a way that
> allows access to every piece of information, but this runs
> contrary to OO design principles. You wouldn't want to see
> accessor methods for each and every field of an object.
> And yes there are query interfaces on top of objects that
> allow for ad-hoc views. But they are not in widespread
> use, probably because it's hard to optimise a system when
> each object has its own hard coded access paths to its
> particular piece of data.

I think this depends on whose OO principles you are talking about. Most people (I believe) think of OO in an introspective (ala JavaBeans) way where the provider of the data specifies the abstraction. People who think of OO in these terms often are frustrated with languages like Java because the Objects are essentially static.

There is another OO model that works in quite the opposite way (when done properly). In this model, it's not the data provider that specifies the abstraction but the data receiver that specifies the interface. In this model, the receiver says this is what I need you to provide. I find this way of doing OO to have similarities to functional programming. Java works much better with this model than with the former for reasons already stated.

I'm not saying this works for everything or that it's appropriate for integration, even though I find it to be supoerior in many ways. It's just that the problem you describe assumes the first model. And in that first model, you are guaranteed to run into the issue you describe, especially in a 'rigid Object' language like Java.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Back at OOPSLA Posted: Oct 26, 2006 12:47 PM
Reply to this message Reply
> And then there is the issue of normalisation. A properly
> normalised data model is easier to understand than an
> object model because it is complete and free of
> redundancies. An object model is not supposed to be either
> complete or free of redundancies.

Says who?

> Most methods in an
> object model are useless or even dangerous when all you
> want to do is create new views and transformations for
> analysis/reporting purposes.

This depends on your level of abstraction. There is nothing wrong with modeling your data as collections of records in memory if that suits your purpose. There are libraries that simply implement relational calculus/in memory databases. If this suits your task, then go for it. You'll have objects that match the concepts of your problem domain providing operations that make sense like joins and such.

Cleo Saulnier

Posts: 77
Nickname: vorlath
Registered: Dec, 2005

Re: Back at OOPSLA Posted: Oct 26, 2006 5:07 PM
Reply to this message Reply
Everybody is missing the ball on this. Distributed computing involves a *network*. This means that an execution model that uses streams, pipes or similar queued transfers will work well with distributed computing. Objects don't use queues, they use a stack for messages. Stacks and queues are different models. Asking why stacks don't work well as queues is rather strange to me.

If objects would ditch the stack model for messages, then you could get somewhere, unfortunately you would need to ditch the idea of methods/functions.

Messages in OOP use a stack even in its abstracted form, and its effects are profoundly felt. To prove it, consider that you cannot send another OOP message before you get a response unless it's a nested message. This means that the first message I send is the last from which I will receive a response (from any active message). First in, last out. Exactly like a stack. Threading just creates more stacks. That solves nothing. And functional programming is stack based too, so although functions at the same level can occasionally execute at the same time, don't expect much help with functional programming either.

A network on the other hand is first in, first out. If I send a file over a network, the first byte that the destination will receive is the first byte that I sent. This is first in, first out. That's a queue.

Note that although half of an OOP message transaction can be queue based, the obligatory return path corrupts any distributed possibilities as well as any queue or streaming model, mostly because the sender must wait (something that is completely against concurrency). So OOP messages should work with simple things, but anything complicated will become a mess.

Note too that Map/Reduce are streaming constructs (first in, first out), not a functional one as most people incorrectly think. That (streaming) is why they're successful in distributed environments. Too bad this promotional argument of Map/Reduce that is often used in support of functional programming is actually a vote against it. Map/Reduce spits in the face of functional programming.

So your question becomes why doesn't a stack based data processing model fit a queue based data processing model? Well, that's rather obvious. I have no problem streaming Unix apps over a network. Anyone who's done video processing knows the streaming method well and uses many machines to get the final audio/video output with many of them working at the same time. You can even process multiple videos in a pipeline fashion where each device processes a different video. Strange that streaming works well over networks, but not stacks, eh? Strange that hardware with it's input/processing/output streaming mechanism works, but not objects, eh?

The no silver bullet paper talks about comparisons between software and hardware. I can't talk about the conclusion, but I guarantee that the reasoning behind the "No Silver Bullet" paper are dead WRONG! Hardware uses streaming. Software uses stacks. Streams scale, stacks do not. End of story.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Back at OOPSLA Posted: Oct 26, 2006 6:05 PM
Reply to this message Reply
> > Jim, I remember you writing about this before and you
> > write about it as if it's impossible and as if it
> hasn't
> > been done.
> >
> > -> .NET <-
>
> How does .NET do this?


CLR.

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: Back at OOPSLA Posted: Oct 26, 2006 6:07 PM
Reply to this message Reply
> Messages in OOP use a stack even in its abstracted form,
> and its effects are profoundly felt. To prove it,
> consider that you cannot send another OOP message before
> you get a response unless it's a nested message.
,,,
> Note that although half of an OOP message transaction can
> be queue based, the obligatory return path corrupts any
> distributed possibilities as well as any queue or
> streaming model, mostly because the sender must wait

Either this is something really profound I need to understand or you have a very limited view of OO ;-)

What is this obligatory return path?

If you define OO as abstraction + encapsulation + polymorphism, nothing in there says anything about required sequencing or being unable to send multiple messages to an object.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Back at OOPSLA Posted: Oct 26, 2006 7:25 PM
Reply to this message Reply
Putting on my "Extreme OO" hat...

Faui writes:

"you cannot know what other people need to do with the information burried in your wonderfully designed API."

The theory of OOP is that other classes do nothing with your buried information. They ask you to do something with it. Like "give me that as a TableModel". Thats what James was getting at. And he's right that JavaBeans style "objects" lead many programmers astray. IMO, JavaBeans as normally implemented, which is data structures with getters and setters and no little or no intelligence, are a blight upon humanity. Between them and J2EE, Sun has set back programming by years and lost any credit from me for inventing Java.


"Separation of code and data is just good design"

Apparently, Richard Pawson is right. Despite claims to the contrary, OOP has clearly not won.

see http://nakedobjects.org/book/section4.html


Cleo has some excellent technical points and challenges. I'm not sure how strong OOP techniques can answer all of his concerns.

Faui Gerzigerk

Posts: 13
Nickname: faui
Registered: Oct, 2006

Re: Back at OOPSLA Posted: Oct 27, 2006 3:34 AM
Reply to this message Reply
> There is another OO model that works in quite the opposite
> way (when done properly). In this model, it's not the
> data provider that specifies the abstraction but the data
> receiver that specifies the interface. In this model, the
> receiver says this is what I need you to provide. I find
> this way of doing OO to have similarities to functional
> programming. Java works much better with this model than
> with the former for reasons already stated.

Yes, in a way object query languages like hibernate QL and formerly OQL do that, or is that not what you mean? The problem I have is that the query refers to some underlying model and this model is of course defined by a particular programming language, not by a general theory of knowledge representation. So this is once again linked very closely to the code. The same query would not mean the same on top of an object model defined in Java as it would in C++ or Ruby.

The set of available operations is not fixed either. Each method called during the query is a small black-box that does whatever it likes. There is no way to logically infer what it will do, which also means that the optimiser has no way of figuring out better access paths based on statistics it has about the data as there is not way to define equivalence of two access paths.

And finally, there is nothing like the principle of closure that you have in relational systems, where a query on relations always gives you another relation that has the same properties and lets you once again apply the same operators. That's a very useful quality in many ways. What is the result of an object query? It's either whole objects or, if you define your own view, it's tuples of data items that are extracted from their object and thus lose their operations, which is quite logical, but also defeats the purpose of an object model. In OO systems, data items only make sense in the context of the class they were defined in. You can't apply any of the original methods as soon as you have extracted fields from an object. So the person who defines the class is effectively the only one who defines the valid views on objects of that class.

And don't get me wrong, I'm not saying that these properties of OO are generally a bad thing. Defining black boxes, hiding how some data is pulled together, whether it is redundant, persistent, derived, local or remote, etc, is a very important thing for managing dependencies. It just doesn't go together well with data analysis where you need logical inference, optimisability and the closure principle so you can dynamically apply a series of transformations without losing some of the original context (which is the class and its operations in OO).

Faui Gerzigerk

Posts: 13
Nickname: faui
Registered: Oct, 2006

Re: Back at OOPSLA Posted: Oct 27, 2006 3:48 AM
Reply to this message Reply
> > And then there is the issue of normalisation. A
> properly
> > normalised data model is easier to understand than an
> > object model because it is complete and free of
> > redundancies. An object model is not supposed to be
> either
> > complete or free of redundancies.
>
> Says who?

That's what I gather from 15 years of reading books about OOA/OOD, looking at respectable people's code and designing a rather large number of object models myself. But I don't have the time to go hunt for particular quotes. You could convince me otherwise by pointing at some object models that are indeed complete and free of redundancies or quotes that say they should be.

> > Most methods in an
> > object model are useless or even dangerous when all you
> > want to do is create new views and transformations for
> > analysis/reporting purposes.
>
> This depends on your level of abstraction. There is
> nothing wrong with modeling your data as collections of
> records in memory if that suits your purpose. There are
> libraries that simply implement relational calculus/in
> memory databases.

Yes, of course there is nothing that keeps me from designing a relational DBMS in an OO language. So what? Does that mean relational modelling is the same as OOD?

Faui Gerzigerk

Posts: 13
Nickname: faui
Registered: Oct, 2006

Re: Back at OOPSLA Posted: Oct 27, 2006 4:31 AM
Reply to this message Reply
> Putting on my "Extreme OO" hat...
>
> Faui writes:
>
> "you cannot know what other people need to do with the
> information burried in your wonderfully designed API."
>
> The theory of OOP is that other classes do nothing
> with your buried information. They ask you to do
> something with it. Like "give me that as a TableModel".
> Thats what James was getting at. And he's right that
> t JavaBeans style "objects" lead many programmers astray.
> IMO, JavaBeans as normally implemented, which is data
> a structures with getters and setters and no little or no
> intelligence, are a blight upon humanity.

And I fully agree with that.

> "Separation of code and data is just good design"
>
> Apparently, Richard Pawson is right. Despite claims to
> the contrary, OOP has clearly not won.

No, it has not, because there are obvious issues that make OO unsuitable for some data analysis tasks. One of it being that there is no formal OO theory. And thus OO lacks the possibilities that all data representations that are based on formal logics have. You cannot do inferencing. You cannot infer equivalence of two expressions, there are no complexity garantees, etc. So the possiblities for optimisation and automatic transformation steps are very limited. You have to code everything explicitly.

The lack of a formal theory also means that there is no logical separation between implementation language and the abstract model. With relational systems you can have an absract relational schema and a translation to one particular DBMS. Two such translations must be logically equivalent in terms of their results.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Back at OOPSLA Posted: Oct 27, 2006 9:40 AM
Reply to this message Reply
> Yes, in a way object query languages like hibernate QL and
> formerly OQL do that, or is that not what you mean?

I think Conrad made a good explanation but I'll take another crack at it.

In the OO paradigm you are describing, the provider of the data starts by looking at the DB and writing some classes to expose the data he/she believes to be needed. Then the receiver looks at those classes and tries to cobble together the data in the needed structure. The result is invariably exactly like what you have described, especially when third party APIs are involved.

In the way that I design OO, I work the other way. I write the receiver first. The receiver specifies what is needed. Then I go back and figure out how to provide that data in the structures specified by the receiver. This has a few main benfits: I'm not guessing what data is needed from the DB, I don't break encapsulation, and I don't couple the receiver to the DB structure.

My first (and probably largest scope) Java project was designed this way. Based on some bad advice, we started by essentially mirroring the db tables as Java Objects. This was a ton of work that really took us backwards in terms of getting the application working. We still had to pull the data together into useable structures which is a lot harder in Java than in SQL. It also (as I see it) was the root cause of the project nearly failing.

Like Conrad said above, the getter and setter culture that was lead by the JavaBeans spec is a cancer on Java. I think it's the main reason that so many developers decide that OOP doesn't work.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Back at OOPSLA Posted: Oct 27, 2006 9:44 AM
Reply to this message Reply
> Everybody is missing the ball on this. Distributed
> computing involves a *network*. This means that an
> execution model that uses streams, pipes or similar queued
> transfers will work well with distributed computing.
> Objects don't use queues, they use a stack for messages.
> . Stacks and queues are different models. Asking why
> stacks don't work well as queues is rather strange to me.

But what you don't address directly is why stacks don't fit in a distributed model. And I think that goes back to my first post on this thread. The network is not reliable.

Faui Gerzigerk

Posts: 13
Nickname: faui
Registered: Oct, 2006

Re: Back at OOPSLA Posted: Oct 27, 2006 11:36 AM
Reply to this message Reply
> In the OO paradigm you are describing, the provider of the
> data starts by looking at the DB and writing some classes
> to expose the data he/she believes to be needed. Then the
> receiver looks at those classes and tries to cobble
> together the data in the needed structure. The result is
> invariably exactly like what you have described,
> especially when third party APIs are involved.
>
> In the way that I design OO, I work the other way. I
> write the receiver first. The receiver specifies what is
> needed. Then I go back and figure out how to provide that
> data in the structures specified by the receiver. This
> has a few main benfits: I'm not guessing what data is
> needed from the DB, I don't break encapsulation, and I
> don't couple the receiver to the DB structure.
>
> My first (and probably largest scope) Java project was
> designed this way. Based on some bad advice, we started
> by essentially mirroring the db tables as Java Objects.
> This was a ton of work that really took us backwards in
> n terms of getting the application working. We still had
> to pull the data together into useable structures which is
> a lot harder in Java than in SQL. It also (as I see it)
> was the root cause of the project nearly failing.
>
> Like Conrad said above, the getter and setter culture that
> was lead by the JavaBeans spec is a cancer on Java. I
> think it's the main reason that so many developers decide
> that OOP doesn't work.

Yes, I think we can all agree on that. Maybe I haven't made myself clear enough, though, because what you say is exactly my point. Good OO design is not about just opening up all data, free of redundancies and in a normalised way. Just mirroring the DB model is not a good idea.

But in BI we need exactly that. We need access to all the data and to as much metadata we can get hold of. Access paths are sometimes unpredictable and still need to be optimised. It wouldn't be a good idea for an OO designer to anticipate all uses of data that analysts might need one day. So a relational model simply has a different purpose than an OO model and that's why the two are both needed but should be kept separate.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Back at OOPSLA Posted: Oct 27, 2006 1:43 PM
Reply to this message Reply
> But in BI we need exactly that. We need access to all the
> data and to as much metadata we can get hold of. Access
> paths are sometimes unpredictable and still need to be
> optimised. It wouldn't be a good idea for an OO designer
> to anticipate all uses of data that analysts might need
> one day. So a relational model simply has a different
> purpose than an OO model and that's why the two are both
> needed but should be kept separate.

I'm only just being introduced to BI but I'm tending to agree with you that at strict OO approach does not make a lot of sense. You could use OO tools, but it appears data must be provided in a non-compile time checked manner. For example, I could use a Map class to pass data and allow for filters to be applied in an OO manner but the data is still going to be pretty much free to contain anything and therefore not really OO.

In short I think we are in agreement. I would just say that we need to be careful about the term 'OO' because it's a very broad concept that means a lot of different things to different people. I take a very pragmatic view of OO where the level of abstraction can float even inside a single application. This is definitely not how a lot of people think of it. Many people follow a dogmatic view of OO which I think is what you are railing against. It seems to me that the dogmatic OO followers tend to be ineffective and/or become disillusioned with OO. I say use it where it works. I use OO when it's a good tool. I don't use it (ideally) when it is not. I use a screwdriver to drive screws and not to open a tin-cans.

Faui Gerzigerk

Posts: 13
Nickname: faui
Registered: Oct, 2006

Re: Back at OOPSLA Posted: Oct 27, 2006 3:15 PM
Reply to this message Reply
I fully agree with you. Thanks for the debate.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Back at OOPSLA Posted: Oct 27, 2006 7:29 PM
Reply to this message Reply
> Good OO design is not about just opening
> up all data, free of redundancies and in a normalised way.
> Just mirroring the DB model is not a good idea.
>
> But in BI we need exactly that. We need access to all the
> data and to as much metadata we can get hold of.

Well, yes I'm aware of that. That's why I wrote ObjectiveCLIPS. It does a good job of unifying OO and BI/BR. That is its entire point. It is possible to get huge synergies this way.

http://ObjectiveCLIPS.com

Flat View: This topic has 48 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: Back at OOPSLA Previous Topic   Next Topic Topic: What's on Your Java Learning List?


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us