Cart
[Home] [By Thread] [By Date] [Recent Entries]
Computer Science 101... This of course is nonsense. I proposed this at UNSW in the late 1970's and was soundly hounded down because at the end of the day everything can be turned into a Turing machine to do it's work and ergo the algorithm is predetermined. With all due respect to Alan - it ain't. It was the start of the relational religion as a mainstream religion and provable algorithms as the holy grail. In a handwaving way here is the 'proof' that reflection is just old fashioned optimisation in disguise if you leave out explaining itself: The basic idea of optimisation is that if you know some mathematical property of an operation you might be able to make a decision NOT to do something provided it is significantly (order of magnitude?) more expensive to do the something than not to do it. eg. x * 0 = 0 in all circumstances. So determining that x == 0 or 0 == 0 and therefore the result is 0 can be done very quickly (assuming comparison is quick and multiplication is slow). Fully compiled code does this sort of thing all the time - so contrary to the claims of the Wikipedia entry, it can be reflective. The compiler code has meta information about calculations and optimises them. I'll reflect ;) on the explanation bit later. Then came SQL. Solving big queries but often slowly. The optimiser people at Oracle and IBM (principally in the early days) realised that they had a lot of information about the tables and queries and built large optimisation machines to use this knowledge to speed up the calculation of SQL statements. Absolutely reflective. I'll reflect ;) on the explanation bit later. UNIBASE uses more meta data about table relationships and equations to drive a runtime engine that constantly looks at what it is doing, what it knows and what it doesn't know to work out what to do next. Very reflective. I'll reflect ;) on the explanation bit later. I haven't looked at the guts of the XSLT stuff but it seems reasonable to me that it does similar things. There's an evolution there. Now how do we get these things to explain what they're doing? That's the problem. We can't and shouldn't really try. (That was the crux of my conflict in the 1970's). Even modern optimised code can't adequately explain why. And there's a reason. We give the compiler/interpreter a set of rules and then allow it to apply them. From the outside we observe results and when it's not what we want we modify the rules. Now where have I seen that before? Oh yes... raising children. They can't always explain their behaviour, but we can usually tell when and what we have wrong with the rules we gave them and how well they follow them. I've also seen it late at night in my favourite bar, but maybe that's for a later discussion... The situation gets significantly worse when the interpreters can work with calculus rather than algebra. Neural networks are possible the ultimate example of self modifying (trainable?) structures that can't explain themselves. Reflection is just the runtime (and essential) part of optimisation. Rick Tei wrote: > > > On 8/16/07, *Sylvain LOISEAU* <sylvain.loiseau@w... > <mailto:sylvain.loiseau@w...>> wrote: > > Can I say that? > > > Reflection for SQL? > http://en.wikipedia.org/wiki/Reflection_(computer_science) > <http://en.wikipedia.org/wiki/Reflection_%28computer_science%29> > > SQL is a query language, is designed to describe a information > request, you have a prior knowledge about structure. > You will ask about "SELECT Name FROM Horses WHERE Type=1", because you > know the structure. > > SQL has not been designed for reflection, but there are extensions, so > you can do that. But will feel like OOP with C, the languaje support > for it will [expletive deleted]. > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
