[
Lists Home |
Date Index |
Thread Index
]
Burak Emir <Burak.Emir@epfl.ch> writes:
> Hunsberger, Peter wrote:
>
> >Elliotte Harold <elharo@metalab.unc.edu> writes:
> >
> >>Hunsberger, Peter wrote:
> >>
> >>>That's exactly my point, if we ever got to the point where we could
> >>>manage graphs (in general) I don't think you'd need to care about
> >>>trees anymore.
> >>>
> >>We can manage graphs just fine now,
> >>
> >I don't agree. Where are the graph serialization standards?
> Where are
> >the best practice algorithms for graph traversal? Where are the
> >standardized languages for graph transformation? Where are
> the "graph
> >databases"?
> >
> [Rick Marshall]: over a hundred years of mathematical
> theory..... (i'm
> getting old - might be two hundred years)
>
> Eliotte and Rick are right, there is so much graph theory and also
> attempts to apply graph theory to software.
>
> In math, a graph is just a pair of sets (V,E) vertices and edges, and
> you use indices v1,v2 ... to talk about nodes. Many theorems
> are quite
> accessible, elegant, beautiful and useful.
>
> Theory of graph transformations are already a much more diverse and
> nonstandard field.
Not sure what you mean here by "nonstandard" ?
> Programming language researchers were particularly interested
> in this,
> because you can implement call-by-need lambda calculus (and
> other Turing
> complete minimal functional programming language based on it) using
> (specific) graph reduction systems. This is a clear example
> of why the
> application area matters.
>
> Since all attempts to explicitly with graphs suffer from
> representation
> complexity, if you are invested in graphs, it pays off to use special
> purpose data representations, and not a generic one.
I think you've backed up my point: if you're explicitly working with
graphs you're not using standardized tools.
It wasn't that long ago when programmers working with trees used
specialized algorithms, tools and data representations for each set of
cases. I can't tell you the number of times in the past I've written a
bunch of binary tree manipulation code. Doesn't happen any more (though
I did have to write a Java preorder tree traversal algorithm to map
relational data to XML I had to do it only once)...
> For all other
> purposes (exchange of information, serialization, deserialization),
> using XML with ID,IDREF is of course a choice, but there is
> no big gain.
>
> The battle of representations for general-purpose programming is long
> over. Objects have won by-and-large. Object graphs, object
> repositories,
> object-oriented programming is here to stay.
Hmm, yes, but I wouldn't be all that surprised if model driven
development pushes OO into the background somewhat equivalent to where
assembler is today. Sure, there's more to come and the OO chapter isn't
finished yet. (Java gains AOP and everything looks more and more like
the Smalltalk I learned 15 years ago.) However, I don't think OO is the
final answer. There's always more and I think this thread touches on
some of the reasons why more is needed.
> <opinion>
> The next big thing will be a combination of XML transformations (say
> XQuery or XSLT) and object-oriented programming (like
> attaching methods
> to some XML). Compared to this, data binding techniques will finally
> look like a bad joke.
>
> And it will probably never be standardized, but several
> solutions will
> be heavily marketed, given the big players in software. </opinion>
Ok, but how does this differ from doing XSLT extension functions?
Sounds sort of like MIME attachments to XML that predefine your
extensions? Careful or you'll give the SOAP proponents some more
ammo...
|
