The answer is a lot less complex than you would think.

I realized that if I could make it look like Python was running inside of Radio, it wouldn't really matter if it was or not. The impression was all that mattered. And if I'd tried to reimplement Python in Usertalk, I was going to be forever chasing the Python developers as they added feature upon feature to the language. Plus, implementing an interpreted language in a language that is itself interpreted was going to be a losing proposition performance-wise.

So how did I do it?

I visualized Radio as a tool to "render" Python source code. The outline is not necessarily the direct source code, it is something that represents the source code. When I write it out to disk, I render the outline as Python. It doesn't matter that the resulting code doesn't look the same as the Python source you are editing in the outline -- that code is getting stored in the Radio database. But by adding that little transformation step, I could do things like redirect standard output to an object that bundled up the output and sent it back to Radio using XML-RPC. That's how the output window worked.

The transformation step also allowed me to add artificial control structures to Python. Usertalk has a "bundle" command that is very handy when you are programming in an outline. When I write code, I use whitespace to break the code into functional pieces (at least those pieces that don't cry out for their own functions). In an outliner, it would be nice to put those bits in their own nodes. In Usertalk, you can stick that code under a bundle, and then just collapse the node so that you can concentrate on other parts of the code. Limited visibility is the biggest benefit of programming in an outliner. Just like the Smalltalk code browser. Limited visibility is your friend.

I wanted to add a "bundle:" control structure to Python. So I wrote the Python renderer to transform any "bundle:" control structures into functional equivalents in Python.

It's a very powerful concept.

In the end I was discouraged because I couldn't easily do things like syntax highlighting. Syntax highlighting is so common to even the simplest Python IDE's that I felt like if I couldn't do that, there wasn't much point in the rest. Maybe I'm wrong. Maybe there are things that could be done. I can visualize how a debugger would work. I can still visualize the web services framework that I thought would be a good idea.

To circle back to the original idea behind this post (see title), sometimes the things that look amazing are simpler than you expect. There is really only one amazing idea in the Python IDE, and most people miss it completely -- the idea that I render Python to the filesystem. The rest of it is just XMLRPC and the UI that Radio provides. Oh, and the conceit that I could get it to work in the first place.

3:39:42 PM    comments ()  trackback []  

But damn, it's a nice day in Seattle.

And when it's a nice day in Seattle, it's really a nice day. It's the contrasts that make it work. There's still enough chill in the air that it doesn't really matter if you are wearing a jacket or a sweater, or just a t-shirt (as I wore today). The sky is a wonderful shade of blue, the air is clear, the noise of the city doesn't seem to be that annoying, and I've got a damn fine cup of coffee.

Life is good.

3:20:22 PM    comments ()  trackback []