This is sort of a wacky line of thought, so it's a pure ThreadMode page.

But anyways:

SunirShah's interested in UbiquitousComputing?, and I just had a thought: "We are approaching UbiquitousComputing? for Computers!"

Now, I admit that that sounds sort of crazy. I mean, of course computers have computing power, right?

But hang with me for a moment.

Our ability to write programs that communicate with other programs seems to be increasing dramatically.

Now, we've had UNIX pipes for a long time, and there has been an Internet for a long time, and all these things.

But I'll be damned: Even if you could, it sure seems a lot easier to establish a connection and start talking now, than it ever was before.

Whether I was programming in BASIC, Logo, Pascal, C, C++, whatever- it was hard. And for a while, even Python communicating with other programs was hard.

But it's so simple now.

And the communication is rich. It's not just "here's a stream of bytes." No, it's like: "Here, here's a list of dictionaries with mixed numbers and streams inside. Just came in. From across the world."

Whether we're talking to distant servers on the other side of the planet, or talking with topically un-related processes, it's getting easier (it seems) to exchange meaningful data.

And I see plenty of room for it to get easier.

For example, in Linux, there's a new thing called the "D-Bus" that's going to get implemented. It's like IPC on crack. It's going to make it easy for processes to broadcast information for anything that's interested, and for processes to start talking with each other. If you can establish a line communication, you should be able to use XML-RPC to exchange data- most XML-RPC library systems allow you to pack to and from strings, after all.

And there are more and more virtual machines, and they're getting sophisticated sandboxing as well.

So it'll be trivial, I imagine, in the future, to add a virtual machine to "Hello, World." You should be able to create at least one virtual machine, bind local functions to it, and then tell it to start running programs from a directory, from across the web, or from another process, or whatever. It'll be like the computing "porch."

Sort of like we have a "mental porch." People can force you to think thoughts, by just saying words at you, or writing them up on signs. But we hold them in a porch of sorts in our mind, where we can reject the thoughts that are given to us. (Of course, some stick…) So we have these data and algorithmic porches in our programs.

Let's say I'm writing a computer game. I want it to be easy to script the computer game. Well, you just put a virtual machine. Right now, that's just about what every computer game does. But it's hard. You have to research and stuff, run a few side-things, do all this stuff to get your virtual machine connected.

But the trend seems to be that this kind of thing gets easier and easier.

We already have .net and the Java runtime. Parrot's in the pipes- it works, it's just a matter of getting languages writing to it, and fleshing out some final stuff. But it's clearly on it's way. And I already feel the rumblings of still more advanced and securable systems on the way.

This is "UbiquitousComputing? for Computers." If UbiquitousComputing? for humans means everyone having a cell phone, or phone numbers ringing wherever you happen to be, then UbiquitousComputing? for computers is every single programming having at least one virtual machine of its own, and all of them being able to call ring buzz each other however they like and know how.

I was working on a program with another person. Her code relied on an XML-RPC call to a server I had. "Oh, what if someone doesn't have XML-RPC installed in their PHP setup, though? Because not all PHP systems are built with XML support built in…" And then I realized: "Wait, we can do this totally low tech. The person probably has Python installed. You can check if they have Python installed, serialize out the request in a format Python understands, fork a Python process, perform the XML-RPC request, serialize the results back out, and then read the results in." Perhaps not the best way to do it, but it'd b easy, and it was easy to think up. We have so many communicative options now.

As we approach SemanticWeb stuff like RDF graphs, I can easily imagine things like:

  1. You need an algorithm in some language.
  2. You search an RDF database for the algorithm.
  3. You find the algorithm, and the RDF description of your language.
  4. You tell a computer on the Internet to turn the algorithm into a representation of the algorithm in your language.
  5. It hands you back the needed code, and pleasant bindings to use the code.

Or perhaps even crazier:

  1. You need an algorithm in some language.
  2. You find the algorithm in another language.
  3. You tell a computer on the Internet to find the path from the algorithm in the other language, into your desired language.
  4. It hands you back the needed code, and (possibly ugly) bindings to use the code.

Because there's just tremendous power in MetaData and in NetworkedData. It's just amazing.

It may even be able to do wacky things like: Give you a simulated threaded execution environment, if code requires it, but the root machinery doesn't support it.

Why can't we do this stuff now? I think because, traditionally, we didn't see the value in MetaData and NetworkedData?. We wrote "lossy." Our compilers dumped their internal tables. I mean- what would connect it with, right? There was nothing you wanted to hook up against. But now we're starting to go, "Wait- that stuff's useful."

We're going towards graphs as the universal data model. This is sort of like the "increasingly primitive data" model. Or "sophisticated," depending on how you look at it. We have cycles to toss, now, so we don't craft everything like a Swiss watch. So, who needs complicated 1st normal form rows and tables? Just use a graph. Just make a node. "This is Joe." See? Person → "name of" → Joe. Who cares that we are redundant and specify that every Person has a name. (And in fact, a lot of times, we have partial information, practically speaking. We can work with the idea of people for whome we don't know what their name is. Our systems can support flexibility now, rather than freak out because someone didn't have a name and you said that they would.) Oh no, we lost 1,000 bytes of RAM. Boo, hoo, I'm so sad; I've only got a friggin gigabyte of RAM left.

At any rate.

So I have said "We have Ubiquitous Computing for Computers on the way," and you probably know what I mean now.

Your computer program will have a cell phone of it's own, wherever it goes, and it'll talk intelligently with it's other friend programs, even those friends that it didn't know that it had. Software is biologic now.

Totally wacky stuff.

I saw a URL once, this URL invoked a process on an embedded URL. And that URL invoked ANOTHER process on an embedded URL. This wasn't just a URL- it was a freaking pipeline- a program. The innermost URL was a web page. The middle URL called a web service to perform an XSLT transformation on the innermost URL. And then the outermost URL called another XSLT transformation on the middle URL. Totally cool.

You could make a program that took a URL, and did something with it. And you would feed it that URL, and a zillion processes would be off on the Internet as you invoked that program.

Have you seen THIS? This is totally insane: This is an event routing system, by JavaScript. That's right- you don't need Java at all to run this: You just go to the web page, and if you support JavaScript, this will just work. I have no idea how it works. Something about keeping the HTTP connection open on the server end, and then training JavaScript to slip messages in into the continual request, and receiving messages in the open connection. Or some crazy shit like that. Totally amazing. I'm seriously wondering if you could write something like SubEthaEdit, that relies solely on having JavaScript in your browser. It shouldn't be too difficult, if I understand this architecture right. It's just a matter of decoding that paper on how SubEthaEdit works, and then sending your messages by the magic JavaScript session, letting the server sort it all out, and then interpreting the messages from the server. (I believe that JavaScript is capable of all the UI manipulations you would need. Specifically, inserting and deleting text.)


Our power as programmers is just totally opening up. But that wasn't the point.

The point is that our computers now have computers, things that had a hard time talking before are now talking with ease, and even our data is talking with other data, and there is an easy and forseeable path for those things to continue on in the future. If hardware advancements completely stopped now, the cross-software communication trajectory alone would be completely amazing.

That's all. {: )}=

Yeah, it's gonna be great!

I tend to think of most of this more as "interoperability" or maybe "web services" or "RPC stuff", rather than "computers for computers".

But I guess the other important point that you have is virtual machines. I still haven't fully grasped the importance of virtual machines, but I'm working on it.

"Wait, we can do this totally low tech. The person probably has Python installed. You can check if they have Python installed, serialize out the request in a format Python understands, fork a Python process, perform the XML-RPC request, serialize the results back out, and then read the results in."

There was a catchy name for a programming style that mixes and matches code from various languages with ease (i.e. the vision is to interface different programming languages so well that eventually you could write each bit of code in the language which is best for that bit, and then have mechanisms to tie it together cleanly), but I forgot it… anyone remember? (I guess you could just call it "component programming" but I was thinking of some other name)

Re: searching an RDF database for some algorithm:

yes!! I totally agree. In fact, this is on my list of "far future projects" (i.e. way after grad school). (in addition, there's a related A.I. research programme: I think a good approach to AI is to create programs which can write/refactor/understand the code of other programs (and, later, their own code). Very few people are working on this. See AiWiki:AiProgrammer.)

You might also be interested in

GenerativeProgramming wiki.

If I ever get back into CS I'm going to get into that stuff a bit.

The really cool thing, for myself at least, about virtual machines, is that you can program them with any language you like. (Or, well- any language that will compile down to the virtual machine.)

Let's say that we had a computer game, say, Escape of the Unicorn. You have to write a scripting language for the video game. It's written in C++, it needs some scripting capabilities, yadda yadda yadda. You don't want people to have to compile, you want people to be able to just write some code describing what happens in a level, how complex AI's work, yadda yadda yadda. "If the player touches this square, make a monster appear over there." But you also want to be able to make really complex codes, yes?

So- What you presently have to do, is either make your own scripting language, or pull in a single language that was made explicitely for this purpose. Maybe Guile, maybe Lua, whatever.

What we'd like to do, though, is just make a virtual machine and say, "You know what? Whatever your favorite programming language is, you can use it with this."

I suppose that we could have a parallel process, communicating by some IPC, or something like that. But that may be too much IPC for the video game (I would think,) and there'd be a lot of control code ("Are you ready to take a request yet? Are you done with that last function call? Oh good- what was the response? Okay, let me route that to whoever needed that value… Okay, are you ready now? You are? Okay, perform this call… Okay, we're waiting for you over here… Oh wait, you need to ask me something? Let me go make a function call… Oh, sorry I missed your call…"). That's all a huge barrier to doing this kind of thing.

Also, I mean- Bayle- you and I- We work on code in Perl, or in Python. But we can't work on the same code-base like this. We have to connect over XML-RPC, or something like that, or IPC or something like that. All of which add a layer of programming between us. It'd be best if I could just call your Perl functions directly, and use the results, and if you could just call my Python functions directly, and use the results, within the same exact program.

It's really powerful for things like plug-in architectures: People can write plug-ins in their own language. They don't have to learn some foreign language to do so. At that point, people cease to care about what language a black-box is written in.

So, those are some of the cool things about virtual machines.

:I tend to think of most of this more as "interoperability" or maybe "web services" or "RPC stuff", rather than "computers for computers".

Hep. "Computers for computers" just puts it into PlainTalk, for myself. Virtual machines are sort of like computer programs having their own computers that they can interact with, and being able to talk with anything is sort of like having a cell phone. So I find it easier to understand that way, instead of thinking about "interoperability" and "web services" and "RPC" and all that other complicated sounding stuff that's pretty specific. :)

Define external redirect: NetworkedData UbiquitousComputing

EditNearLinks: SunirShah