The Artima Developer Community
Sponsored Link

Weblogs Forum
Back at OOPSLA

48 replies on 4 pages. Most recent reply: Mar 29, 2007 9:25 AM 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 | » ]
Jim Waldo

Posts: 34
Nickname: waldo
Registered: Sep, 2002

Back at OOPSLA (View in Weblogs)
Posted: Oct 24, 2006 4:13 PM
Reply to this message Reply
Summary
For the first time since 1989, I'm attending OOPSLA. Some things have changed, others have not. Here are a couple of reflections...
Advertisement
I'm back at OOPSLA for the first time since 1989. I stopped going in 1989 because the conference had gotten too big; it has since expanded, contracted, and now seems to be growing again. It is somewhat larger than it was in 1989, but not unmanageably so.

The venue is Portland, a very nice city. We are in the Oregon conference center, which is a bit sterile for my tastes. When I come to a conference like this, I gain an additional appreciation for the Jini community's decision that we would not meet in "plastic" places. So Jini community meetings are in places like Brussels or downtown Chicago (at a hotel, not a conference center) or a brewery in London. One of the advantages of a smaller community.

I'm here to give a couple of talks. The one I gave today was part of the company talks track, which are half-hour sessions given to those companies that have given enough money to be conference sponsors. I guess that I was expected to give a sort of overview of the projects in Sun Labs, but neither I nor the director of the lab thought that would be a good idea. Instead, I took the opportunity to talk about something that has been bothering me for a long time.

I started off with the thought that object technology has been pretty successful. When I came to OOPSLA in 1989, the conference was partly a support group for those of us who thought that this object way of doing things might be useful. Now objects are just about everywhere-- designs are about objects; implementations are about objects; industry does objects; academics do objects. It has been a very successful idea.

What I find interesting is that the one place that objects don't seem to have taken hold is in distributed systems, where we still organize things around wire protocols. We've tried objects in everything from active networking to agent systems to Jini technology. Some people have found the use of objects in distributed systems persuasive, but the acceptance has been nowhere near that of objects within the address space. The challenge I presented to those in the OOPSLA audience was to either explain why objects weren't used in distributed computing, or what about distributed computing limited the applicability of the object paradigm.

I had my own theories. In part, I think this is because we have not freed objects from the expressions of those objects in a particular language-- even though we talk about objects in Java or Smalltalk or some other language, the notion of an object in each of these is significantly different. Smalltalk objects can't talk to Java objects, and vice versa. The Java type system and the ML type system are very different. So rather than unifying our notion of object, we have decided that we will translate into bits on the wire and let the two sides agree to disagree.

I then argued that part of the reason that we have agreed to disagree is that most of us in the object world don't actually believe what we say when we talk about objects. Oh, we are willing to talk about objects that are characterized by interfaces and which consist of the pairing of data and the code that manipulates that data. But deep down we know that code is code, and data is data, and that the two are really different. Objects are an interesting and convenient abstraction, but they aren't the real deep truth.

Of course, bytes aren't the real, deep truth either. But we have all agreed that bytes are the right level of abstraction, so we don't generally worry about going any lower. But we can't come to the same agreement about objects. Maybe this is something that will change when a new group of programmers and designers who have never known anything but object-oriented progamming takes over. I'd hate to think that it will take this long, but maybe that is the only way.

Or maybe there is a limit to the use of objects as a design principle. I actually think there might be, but I don't think it is the address space. But where the limits are is an interesting question, and I thought it would be interesting for someone to ask it.


Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Back at OOPSLA Posted: Oct 25, 2006 2:46 AM
Reply to this message Reply
> I then argued that part of the reason that we have agreed
> to disagree is that
> most of us in the object world don't actually believe what
> we say when we talk
> about objects. Oh, we are willing to talk about objects
> that are characterized
> by interfaces and which consist of the pairing of data and
> the code that
> manipulates that data. But deep down we know that code is
> code, and data is
> data, and that the two are really different. Objects are
> an interesting and
> convenient abstraction, but they aren't the real deep
> truth.
> [...]
> Or maybe there is a limit to the use of objects as a
> design principle. I
> actually think there might be, but I don't think it is the
> address space. But
> where the limits are is an interesting question, and I
> thought it would be
> interesting for someone to ask it.

I've given this some thought, as well. Recently, I've been revisiting assembly programming (having got an ARM-based computer, the Iyonix, with an instruction set that is so much nicer than x86), and at that level, code and data are really unified: A word may be interpreted as either an instruction, or as data. It doesn't matter to the processor.

It's similar with a high-level language like Lisp: Code and data are again unified: The program is just a list.

With OO, an object kind of unifies code and data... However, I don't really have any more comments on this part, so this posting was mostly to note these various approaches to code and data unification.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Back at OOPSLA Posted: Oct 25, 2006 5:39 AM
Reply to this message Reply
I'm not 100% sold either way but I'm kind of leaning towards OO not being compatible with distributed systems. I think perhaps it's related to the "Fallacies of Distrubuted Computing" - http://weblogs.java.net/jag/Fallacies.html.

OO makes abstracts things out to a high degree hiding all the gritty details of bits and bytes (ideally.) It may be that this is only tenable in an environment that very 'smooth' for the lack of a better word. When I create an Object in a Java program, it's not going to just disappear from memory for no apparent reason. If it did, my whole program will crash and that's OK because it shouldn't happen except in the most rare circumstances. In distributed programming, you can't make any such assumptions and it's no OK to crash just because something that was there a second ago is no longer there now.

Frank Silbermann

Posts: 40
Nickname: fsilber
Registered: Mar, 2006

Re: Back at OOPSLA Posted: Oct 25, 2006 11:40 AM
Reply to this message Reply
> one place that objects don't seem to have taken hold is in distributed systems,
> where we still organize things around wire protocols.
> ...
> In part, I think this is because we have not freed objects from
> the expressions of those objects in a particular language.

We have not freed objects from the _implementation_ of those objects in a particular language.

Objects are programming language constructs. The ability of a programming language construct to interact with another programming language construct is created by the compiler; therefore, the scope of an object is limited to the domain of its compiler, which in turn is limited by the compiler user's decision-making authority. That authority rarely extends beyond the individual system.


> So rather than unifying our notion of object, we ... translate into bits
> on the wire and let the two sides agree to disagree.
>
> Objects are an interesting and convenient abstraction, but they aren't
> the real deep truth. Of course, bytes aren't the real, deep truth either.
> But we have all agreed that bytes are the right level of abstraction,
> so we don't generally worry about going any lower.

It has nothing to do with what is "real" or what is the "right level" -- but rather with what diverse systems today have in common. We deal in bytes because virtually all systems today deal in bytes at some level internally --bytes are the greatest common denominator.

I don't know that the universal use of bytes as a low-level abstraction within individual systems was necessitated by the needs of computer users; it may be an accident of history -- perhaps useful computer architectures with no concept of bytes could have been developed. Had that happened, our communications protocols might now be based on bit streams.

So I guess the rule is to go to as low an abstraction level as necessary for commonality, but no lower.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Back at OOPSLA Posted: Oct 25, 2006 11:58 AM
Reply to this message Reply
There are technology issues. But another big issue is that these big distributed systems ultimately talk to Relational Databases. And, in my experience, good database programmers are lousy OO programmers. They think in terms of data and procedures, not objects.

Quoting Allen Holub, "It's rare that a good object model will make a good database schema (or vice versa)."

Andrew Chase

Posts: 5
Nickname: acechase
Registered: Jul, 2003

Re: Back at OOPSLA Posted: Oct 25, 2006 12:19 PM
Reply to this message Reply
You seem to be turning a blind eye to the other abstraction available for distrubuted computing, functional programming. With a functional paradigm you no longer have to worry about hidden state within objects and how that state may be mutated by some distributed process. Instead, there's a set of inputs to a function and a return value.

I've spent some time working with Jini and I've spent some time with Erlang, one of the functional approaches to distributed computing. And so far, I'd say things are much cleaner and easier to reason about using the functional approach.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Back at OOPSLA Posted: Oct 25, 2006 2:34 PM
Reply to this message Reply
I attended the dynamic languages symposium and the first talk by Ian Piumarta just blew me (and many others) away.

A link to a paper:
http://piumarta.com/papers/colas-whitepaper.pdf

My takeaway after reviewing most of the topics is that most of languages are simply implemented at the wrong levels of abstraction. Truly powerful languages are implemented in terms of themselves. This class of languages is profound. Witness the success of Squeak's self implemented VM and copycat projects like PyPy and RubyInRuby. Everything is data - even code. Manipulatable, discoverable, debuggable in terms of themselves. There is vast power here and COLA takes that kind of self referential power even further.

Meanwhile, languages like Java and C# are not implemented in terms of themselves, but are implemented in a relatively large number of inflexible and coarse abstractions that impair their flexibility and evolution. They are dead tongues handed down from alien gods. They are not profound.

They are sterile simulations of OO. Animatronic facsimiles of living systems with all of the limitations that implies.

The real OOPSLA where the big ideas were shared and explored was at the DSL and the tables near the E meeting rooms. It wasn't in the big halls.

Faui Gerzigerk

Posts: 13
Nickname: faui
Registered: Oct, 2006

Re: Back at OOPSLA Posted: Oct 26, 2006 1:36 AM
Reply to this message Reply
> There are technology issues. But another big issue is
> that these big distributed systems ultimately talk to
> Relational Databases. And, in my experience, good
> database programmers are lousy OO programmers. They think
> in terms of data and procedures, not objects.
>
> Quoting Allen Holub, "It's rare that a good object model
> will make a good database schema (or vice versa)."

I think this is totally wrong and it is quite obvious for anyone who ever had to deal with information integration issues.

Distributed systems are not just physically distributed over a network of nodes. Distribution also means distribution of responsibility, distribution of control, distribution of goals and purpose, etc. Distributed systems are very often distributed not for scalability reasons but simply because different people/organisations want to do different things in a different organisational context with that same information.

The principle of encapsulation and data hiding is useful if the context can be clearly defined. You design an interface by thinking about what the purpose of a particular type is, how it interacts with other types of objects, etc. You ask, what do I want to do with that kind of thing? But that is in stark contrast to the requirements posed by distributed systems as described above, because you cannot know what other people need to do with the information burried in your wonderfully designed API.

Objects have a dual role. They are gate keepers that define how data can be modified. But they also define a view on that data. And that's the problem. It makes sense in many cases to centralise write access to data, but it doesn't make sense to centralise the definition of views on data. Objects claim that there is exactly one useful view on a particular type of object and that is simply a flawed concept.

So at this point encapsulation and data hiding start to break down. Sure you can use any of the available externalisation/serialisation patterns. But to avoid leakage of the inner structure of the object, the designer of the type itself has to define what is externalised, so it's once again a centralisation of view definition. There is no right way to tell what information is part of one particular object because objects are almost always part of an object graph. So what do you externalise? You make a decision based on the contexts you know, and I can tell you from experience, it's not the incompetence of OO programmers that makes it so hard to use OO APIs for integration purposes, it's the logical impossibility to anticipate all contexts of use. With a RDBMS, the user defines the views, not the designer of the base tables, and that is a logical requirement, not some kind of technical limitation or feature.

OO is strong where the purpose is to define the interactions between a closely knit graph of objects, but it's naive to assume that any kind of design effort will be able to anticipate all contexts of information use. And that's why the data has to be set free. People who work in the field of information integration, application integration, data warehousing, etc are highly paid to fight the kinds of silos that object APIs are. What we really need is unrestricted access to a rich represantation of data and metadata independent of all APIs.

OO people have to accept that not every system is an OLTP system where it's important to restrict access methods. In decision support and BI, we need to analyse data in unanticipated ways and we need a lot of metadata to do that. If that metadata is burried in procedural code, it is of no use. It has to be duplicated elsewhere and that's a lot of effort.

I consider the inextricable mangling of code and data an anti-pattern comparable to the mingling of user interface and business logic.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Back at OOPSLA Posted: Oct 26, 2006 2:14 AM
Reply to this message Reply
> With a RDBMS, the user
> defines the views, not the designer of the base tables,
> and that is a logical requirement, not some kind of
> technical limitation or feature.
>

The designer of the base tables still has to anticipate the views that may be required. Otherwise you can end up with a fantastically normalised database, but user will struggle and perhaps fail to create the views that they want.
You may resolve this by transforming the source data to another form which is easier to query or by redesigning the base tables.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

OOP is overrated. Posted: Oct 26, 2006 3:11 AM
Reply to this message Reply
Since each programming language provides different levels of abstraction, each object implementation is different: C++ objects are nothing more than hardcoded records of data and pointers , whereas Ruby objects are maps of fields and methods which is changeable at run-time; there can never be a co-operation between those objects in a distributed environment beyond data exchange, because the purpose of each language is different.

Object-oriented programming is overrated. OOP is nothing more than pattern matching on the type of data: "if the data type is this, then do this, else if the data type is that, then do that, etc". OOP is still procedural programming, and OOP projects exhibit the same problems as non-OOP projects. Real progress will come when languages can manipulate themselves, i.e. where code is data. LISP was a good idea made bad due to its lack of syntax, weird terminology and complex non-standard libraries...but Ruby proves that, when done correctly, the treatment of code as data is invaluable.

Faui Gerzigerk

Posts: 13
Nickname: faui
Registered: Oct, 2006

Re: Back at OOPSLA Posted: Oct 26, 2006 4:27 AM
Reply to this message Reply
> > With a RDBMS, the user
> > defines the views, not the designer of the base tables,
> > and that is a logical requirement, not some kind of
> > technical limitation or feature.
> >
>
> The designer of the base tables still has to anticipate
> the views that may be required. Otherwise you can end up
> with a fantastically normalised database, but user will
> struggle and perhaps fail to create the views that they
> want.
> You may resolve this by transforming the source data to
> another form which is easier to query or by redesigning
> the base tables.

Sure, but this is really just a matter of expertise. The provider of the base tables can provide views of his own to simplify certain recurring needs, but that doesn't make it impossible for the user to access the base tables. At the end of the day, with a data representation (not necessarily relational) you get all the information that exists, with APIs you get only what the API designer anticipated you might need.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Back at OOPSLA Posted: Oct 26, 2006 5:19 AM
Reply to this message Reply
> I had my own theories. In part, I think this is because we
> have not freed
> objects from the expressions of those objects in a
> particular language-- even
> though we talk about objects in Java or Smalltalk or some
> other language, the
> notion of an object in each of these is significantly
> different. Smalltalk
> objects can't talk to Java objects, and vice versa.

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 <-

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Back at OOPSLA Posted: Oct 26, 2006 6:21 AM
Reply to this message Reply
> Sure, but this is really just a matter of expertise. The
> provider of the base tables can provide views of his own
> to simplify certain recurring needs, but that doesn't make
> it impossible for the user to access the base tables. At
> the end of the day, with a data representation (not
> necessarily relational) you get all the information that
> exists, with APIs you get only what the API designer
> anticipated you might need.

And when you have data in the table that must be modified in very specific ways or should not be depended upon for any reason, how do you handle that?

You write about this as if there is no downside to many independent parties having unfettered access to a systems data.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Back at OOPSLA Posted: Oct 26, 2006 6:22 AM
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?

Faui Gerzigerk

Posts: 13
Nickname: faui
Registered: Oct, 2006

Re: Back at OOPSLA Posted: Oct 26, 2006 8:00 AM
Reply to this message Reply
> > Sure, but this is really just a matter of expertise.
> The
> > provider of the base tables can provide views of his
> own
> > to simplify certain recurring needs, but that doesn't
> make
> > it impossible for the user to access the base tables.
> At
> > the end of the day, with a data representation (not
> > necessarily relational) you get all the information
> that
> > exists, with APIs you get only what the API designer
> > anticipated you might need.
>
> And when you have data in the table that must be modified
> in very specific ways or should not be depended upon for
> any reason, how do you handle that?
>
> You write about this as if there is no downside to many
> independent parties having unfettered access to a systems
> data.

No, not at all. Of course there is a downside. I said in my first post that centralisation of write access is useful and I think OO is very suitable for that. I take issue with not having a representation of data and metadata that is separate from the operations that work on the data.

Of course there are situations where read access may have to be restricted as well (security,...) but the point is that it should be a deliberate decision to restrict access, not a consequence of bad design. Separation of code and data is just good design, because it allows for both restricted write access AND flexible definitions of new views by the user. Read access cannot be fully anticipated because there are many useful views depending on the context. Write access has to be anticipated because otherwise you get data corruption.

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.

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. 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.

OO APIs are nice for manipulating data, i.e OLTP, but they are a pain for data integration and BI. And since most growth in the software industry is on the BI side of things, API silos are being teared down or expressed in a data oriented way like with SOAP or REST.

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-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use