Neuromancer: Then back to biznazz

So I always wanted to have this like space man David Bowie like band, in the neuromancer genre. Sensors on the brain, real sci-fi rock. Sci-fi rock is some of the best, Jimi Hendrix is always characterized as the pinnacle of a hippie, when in reality he was at heart, and by his own admission, a science fiction nerd...But in a time when an African American scifi nerd had a hard time fitting in as such, so he fit in where he could, playing the the part of the tripped out alien to adoring hippie audiences. I wonder if he would have aspired to be more like Charles Bolden, were he born a few decades later.

We are all products of our time, and there is always compromise in that.

After my Carrie Bradshaw mind control zombie magic post last night, I think I need to get back to the purpose and focus of my blog: Recording my odd thoughts on computer science.

So having digressed so far, what does the prototype of the Query/programming language look like? Well, some common sense factors.

1) Recursion: Its inherit to programming languages, but it has to be unified with queries. For example, suppose you have a table with cols "mother", "father", "child". You need to have a query that pulls all the ancestors for "John", which is by nature a recursive query. This has to be fused seemlessly with the programmatic concept of recursion.

2) You have to recognize what can't be done, what relationships (functions) can't be inverted. This introduces a new concept to databases, the table where you simply can't access the contents of col A given a value in col B, but you CAN access the value in col B given the value in col A. And like I've said, this can be good. You can pull customer address given SS number, but not SS number given address.

3) The syntax for "function" definition and "table" definition should both be intuitive and easy. For the definition of a relation, you want it to be able to look like this:

rel employee (int id, string name, int boss) {

(0, "alice", 2),

(1, "bob", 2),

(2, "charlie", NULL)

}

As easy as an SQL insert statement, but you also want program definitions:

rel product (int x, int y, int z) {

z = x*y

> y = z/x

x = z/y

}

Notice what a gross over simplification that last one was. Each line assumes two of the variables are given. Suppose x=3 and z=7 are given. y was defined as an int, so the answer of 7/3 is out of the range. So it really must look like

rel product (int x, int y, int z) {

z = x*y

if (z%x) = 0 { y = z/x } else y = NULL...(or {}, empty set)

And that doesn't even take into account the real database like behavior we want. We want to be able to provide just x = 5, and get in response a new relation, having two columns y and z, looking like this:

rel product_x_5(int y, z) {

z = y*5

y = z/5 (if mod bla bla)

Notice we can enumerate the values in this relation by enumerating integers, like a real database table. But also need to be able to do the same for product(z = 8473928) This is a more complex relation. The way I see it, in order to be able to enumerate its contents, you must factor 8473928, then take all the possible pairs of factors, the factors being (2*2*2*149*7109) for this number. That's just ugly, computationally complex. However, its interesting to note that if you are willing to make a relationship who's contents can't be enumerated, it becomes trivial:

rel product_z_8473928(int x, int y) {

y = 8473928/x

x = 8473928/y

By adding in the "NULL if not mod x == 0" functionality from above, we have a very expensive way to factor 8473928 by enumerating all int values of X, but that's not what I am talking about. I am talking about blocking the ability of certain tables to have their contents enumerated.

The thing is that a useful programming language must not make new demands on the programmer. She should be able to translate everything that has already be learned instantly into the new paradigm. But once that requirement has been satisfied, a new paradigm should let them do things that they were unable to do before. This paradigm should let them basically write

rel product (int x, int y, int z) {

z = x*y

}

just like they would write in any other programming language, where z is defined given x and y. But it should also give them the power to add in the other functionality, either explicitly or through the aid of a compiler/interpreter applying algebraic theorems and axioms to calculate inversions for them, and this new functionality should open up new worlds, like composing functions in a massively parallel fashion through something as easy as an SQL JOIN statement. ITs about letting the old bridge with the new seemlessly.