Prev: Asking advice
Next: Is your computer safe and secure!
From: sandeep6699 on 30 Mar 2008 09:40
There are a few protocols (both Application-level and Transport-level)
out there that claim to be geared towards dynamic interface discovery
(e.g. CORBA-DII). I have never been able to fathom the concept in its
entirety. To me it appears that there is really not much you can do
if you discover an interface about which you have no compile-time
semantical knowledge. Can someone kindly shed some light on this? I
mean, what exactly can we do if we discover an interface definition at
run-time? Wouldn't it require some level of human intervention to do
anything meaningful? I may be able to discover the names of
operations are supported, the names and types of parameters are need
to be passed, the data-type of the result that is returned etc., but
so what? Unless I know the behavior associated with each operation,
what good does it do me? And I can almost challenge that there is
absolutely no way in the world we can capture semantical details
associated with interfaces.

We got into this discussion at work while we were discussing this
problem on a smaller scale. Can we do anything about a blob of data
for which there is absolutely no compile time knowledge of its
underlying data structure but for which an XML description of the data
structure is provided at run-time? Again the same issue. Can we
really do anything meaningful with this data? I have given it some
thought and concluded that the only thing that can be done with this
blob of data is at the PRESENTATION LEVEL ONLY. Yeah, we might be
able to display the data correctly in some user interface, but that's
about it. Again I challenge that we can do nothing with this data
beyond the presentation level. One of my colleagues thinks that with
a run-time XML description of data we can populate the data in a
relational database and let some other application take it from
there. Now this may be possible, but aren't we merely shifting the
problem?

My philosophical argument is that any claim to do anything meaningful
with either interface or data for which there is absolutely no prior
knowledge, without human intervention, is complete humbug. To do
something meaningful we need to have shared semantics between the two
entities. In all the hype of dynamic interface discovery and self-
describing data, no one talks about the need for shared semantics.

I would like to know what the wider community of netizens, who are
infinitely wiser than me, think about this issue.

Regards,
Sandeep
From: Le Chaud Lapin on 30 Mar 2008 14:04
On Mar 30, 8:40 am, sandeep6...(a)yahoo.com wrote:
> There are a few protocols (both Application-level and Transport-level)
> out there that claim to be geared towards dynamic interface discovery
> (e.g. CORBA-DII).  I have never been able to fathom the concept in its
> entirety.  To me it appears that there is really not much you can do
> if you discover an interface about which you have no compile-time
> semantical knowledge.  Can someone kindly shed some light on this?

Yes: You're right, and the other people are wrong. :)

> mean, what exactly can we do if we discover an interface definition at
> run-time?  Wouldn't it require some level of human intervention to do
> anything meaningful?  

Yep.

> I may be able to discover the names of
> operations are supported, the names and types of parameters are need
> to be passed, the data-type of the result that is returned etc., but
> so what?  Unless I know the behavior associated with each operation,
> what good does it do me?  And I can almost challenge that there is
> absolutely no way in the world we can capture semantical details
> associated with interfaces.

And isn't it extremely irritating when the people you argue with imply
that it is possible by pursuing this fruitless path, but always seem
to "have to go to lunch" when you call them out on it?

> We got into this discussion at work while we were discussing this
> problem on a smaller scale.  Can we do anything about a blob of data
> for which there is absolutely no compile time knowledge of its
> underlying data structure but for which an XML description of the data
> structure is provided at run-time?  Again the same issue.  Can we
> really do anything meaningful with this data?  I have given it some
> thought and concluded that the only thing that can be done with this
> blob of data is at the PRESENTATION LEVEL ONLY.  Yeah, we might be
> able to display the data correctly in some user interface, but that's
> about it.  

These types of people are *the* most annoying kind of smart people.
They are the Hoare's (pun intended) of the software engineering
world. I would not be suprised if the person you were arguing with
also believes that there is some generalized lock-free mechanism with
no machine-specific synchronization support that we simply have not
discovered yet.

> Again I challenge that we can do nothing with this data
> beyond the presentation level.  One of my colleagues thinks that with
> a run-time XML description of data we can populate the data in a
> relational database and let some other application take it from
> there.  Now this may be possible, but aren't we merely shifting the
> problem?

Yep.

> My philosophical argument is that any claim to do anything meaningful
> with either interface or data for which there is absolutely no prior
> knowledge, without human intervention, is complete humbug.  To do
> something meaningful we need to have shared semantics between the two
> entities.  In all the hype of dynamic interface discovery and self-
> describing data, no one talks about the need for shared semantics.

Because they cannot.

> I would like to know what the wider community of netizens, who are
> infinitely wiser than me, think about this issue.

I certainly agree. See post #4 of this thread:

http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/cd3ceb807bf9f3ac

About the person you were arguing with:

You probably already know that you and he will never see eye-to-eye on
this matter. His perspective on design is a manifestation of
fundamental differences in the neural-interconnects between your
respective minds.

One way to weed out people like this during an interview is to take a
stack of 100 sheets of blank paper, lock him in a room, and tell him
to architect, in excruitating detail (with code), before leaving the
room, a system of moderate to great complexity, making sure you
impress upon him the need to be specific [red-black tree for set vs
straight binary tree, etc.]

If he starts sweating, he might not be what you are looking for,
because people who think in that manner often find displined
forethought toxic, a quality that just happens to be a prerequisite
for being a good engineer. Another dead give-away is if the person
insist on interacting with you or other members of the interviewing
team while doing the design.

Incidentally, the whole notion of .COM and interfaces (and some
aspects of .NET) foll into this category of meandering modes of
thought.

-Le Chaud Lapin-
From: Patricia Shanahan on 30 Mar 2008 16:36
sandeep6699(a)yahoo.com wrote:
....
> We got into this discussion at work while we were discussing this
> problem on a smaller scale. Can we do anything about a blob of data
> for which there is absolutely no compile time knowledge of its
> underlying data structure but for which an XML description of the data
> structure is provided at run-time? Again the same issue. Can we
> really do anything meaningful with this data? I have given it some
> thought and concluded that the only thing that can be done with this
> blob of data is at the PRESENTATION LEVEL ONLY. Yeah, we might be
> able to display the data correctly in some user interface, but that's
> about it. Again I challenge that we can do nothing with this data
> beyond the presentation level. One of my colleagues thinks that with
> a run-time XML description of data we can populate the data in a
> relational database and let some other application take it from
> there. Now this may be possible, but aren't we merely shifting the
> problem?
....

I think you can go quite a way beyond display, especially if you can
convert your data to a relational database.

Each relational database manager I've used has come with an interactive
utility that does various forms of inport and export, as well as
executing any valid SQL operation on the database. That allows changes,
as well as display. I've used one of those programs to do non-trivial
work on a database that did not exist when the program was compiled.

Of course, that does combine the program's user's knowledge of data
semantics with the program's knowledge of the nuts and bolts of
operating on a database.

Patricia


From: Logan Shaw on 31 Mar 2008 23:28
sandeep6699(a)yahoo.com wrote:
> There are a few protocols (both Application-level and Transport-level)
> out there that claim to be geared towards dynamic interface discovery
> (e.g. CORBA-DII). I have never been able to fathom the concept in its
> entirety. To me it appears that there is really not much you can do
> if you discover an interface about which you have no compile-time
> semantical knowledge. Can someone kindly shed some light on this? I
> mean, what exactly can we do if we discover an interface definition at
> run-time? Wouldn't it require some level of human intervention to do
> anything meaningful? I may be able to discover the names of
> operations are supported, the names and types of parameters are need
> to be passed, the data-type of the result that is returned etc., but
> so what? Unless I know the behavior associated with each operation,
> what good does it do me? And I can almost challenge that there is
> absolutely no way in the world we can capture semantical details
> associated with interfaces.
>
> We got into this discussion at work while we were discussing this
> problem on a smaller scale. Can we do anything about a blob of data
> for which there is absolutely no compile time knowledge of its
> underlying data structure but for which an XML description of the data
> structure is provided at run-time? Again the same issue. Can we
> really do anything meaningful with this data? I have given it some
> thought and concluded that the only thing that can be done with this
> blob of data is at the PRESENTATION LEVEL ONLY. Yeah, we might be
> able to display the data correctly in some user interface, but that's
> about it.

I think I agree with where you're going with this in general, but I
don't think it's quite as limited as that.

Yes, you can do something meaningful with the interface discovered at
runtime. This is trivial to show: you just define an interpreted
language, write an interpreter for it, and allow it to access the
discovered interface. To do anything useful requires someone to
provide you with a program written in the interpreted language, but
the question (as you phrased it) was whether it was possible to do
anything useful other than present the data, and the answer to that
is clearly that it is possible, although it may not be anyone's
preferred way of doing it.

Also, I suppose you could apply any sort of set of semantics that
takes the interface as a parameter. You mentioned transliterating
the values so that the user can interact with them on a very literal
level[1]. That is one example of a set of semantics that is
parameterized by the interface. Another example might be some
sort of service availability test for people who monitor a
critical application at a data center: code could discover an
interface, then a user could select which method looks harmless
to call as a test of the application's availability. The code
could then make the call repeatedly and sound an alert if the
call takes longer to complete than N standard deviations above
the mean, or just more than some number of milliseconds, specified
by the user. Yet another example would be to compare two interfaces
to see if they are syntactically equivalent; this could be useful
for managing software or porting software between one system and
another.

The point here is that while interface discovery doesn't do anything
magic, maybe there are useful things that can be done by composing
together an existing, static algorithm with an interface. The software
is not going to magically sprout the ability to "understand" the
interface, but maybe it's not necessary to understand the interface
in order to do something useful that you couldn't do before you had
the ability to dynamically discover interfaces.

- Logan

[1] Incidentally, the Eclipse IDE for Java has a plugin for SOAP
calls that does this. That is, it connects to a SOAP server
and reads a WSDL (which is an interface definition), and
allows you to make remote method calls by typing values into
text fields. It's a trivial and very literal transformation,
but it also happens to be a very handy interactive tool for
trying things out quickly.
From: Le Chaud Lapin on 1 Apr 2008 00:02
On Mar 31, 10:28 pm, Logan Shaw <lshaw-use...(a)austin.rr.com> wrote:
[snippage]
> The point here is that while interface discovery doesn't do anything
> magic, maybe there are useful things that can be done by composing
> together an existing, static algorithm with an interface.  The software
> is not going to magically sprout the ability to "understand" the
> interface, but maybe it's not necessary to understand the interface
> in order to do something useful that you couldn't do before you had
> the ability to dynamically discover interfaces.
>
>    - Logan
>
> [1]  Incidentally, the Eclipse IDE for Java has a plugin for SOAP
>       calls that does this.  That is, it connects to a SOAP server
>       and reads a WSDL (which is an interface definition), and
>       allows you to make remote method calls by typing values into
>       text fields.  It's a trivial and very literal transformation,
>       but it also happens to be a very handy interactive tool for
>       trying things out quickly.- Hide quoted text -

First of all, in case it isn't obvious, I am firmly on Sandeeps side
in discussion. :)

I use the word "side" to emphasize that there are two distinct,
diametrically opposed views on this matter. IMO, it is extremely
important to recognize this distinction:

In one case, a human is allowed to be present, and in the other, a
human is *not* allowed to be present.

In all of the examples you gave above, a human arrives on the scene,
after the fact. What Sandeep has said, and I agree with, is that it
has always been possible for a human to induce a machine to behave the
way the human wants it too.

That is not what the interface "Hoare's" are talking about.

What they are talking about is creating a framework where code can
interact with other code with the same or similiar magic that is
realized when a human [a person with brain and blood vessels]
interacts with a machine, and this is what we are saying is not
possible. Any process that gives the appearance thereof is, by
manifest definition, meaningless, because code cannot think. It only
does what it has been told to do, and for that, you need a human. In
other words, the code is not going to code itself, no matter how many
layers of interpretation you add.

Along a similar line of thought...

There are researchers all over the world seeking to devise tools for
proving the correctness of code, hoping to earn a Turing Award from
their work, but I suspect they know in the back of their minds that
such effort is almost useless, as whatever they devise will, in each
individual case, have to be programmed by a human who has sufficient
depth of knowledge and adherence to discipline that such qualities
might as well have been appplied to the original problem itself, thus
obviating the tool.

-Le Chaud Lapin-
 |  Next  |  Last
Pages: 1 2
Prev: Asking advice
Next: Is your computer safe and secure!