Monday, September 19, 2005

The middle ground.

I've noticed a lot of comments about Google and what they're doing next. One popular idea I've heard suggested is that they're going to try to deploy something to replace (1) Microsoft Office, or other office suites or (2) Microsoft Windows itself, or other operating systems. I won't comment on (2) because it's still a bit too far away. However, I think (1) is possible, but it'll take some work.

The problem is simple: to have an office suite (or any other program), you have to send a lot of program information. Even worse, you have to send fairly complicated information if you want interactivity. I have an exceptionally difficult time imagining someone implementing an office suite using HTML--the pages are inherently static, and you'd have to embed JavaScript to have any level of interactivity. Presumably, this is one of the nice things about Java. "Write once, run anywhere." You could write an office app in Java, send it out, and voila, problem solved. But not quite. Once someone has that office app, then they have it forever, short of deprecation and DRM-like restrictions that get in the way. What they'd want is to provide a service, so no, that isn't it either.

How about X-Windows? That's the ticket! Just host connections to their servers and run the office app from there, problem solved. But we now have new problems. Not everyone runs X-Windows...if you use Linux or Unix, no problem. If you use Windows, then you can either buy XWin32 or download and configure a XWindows program using Cygwin or something. (Note: this isn't so trivial as it sounds...I tried once, but I just gave up and installed Linux for the first time, which ended up being a much simpler solution). Now, they could release a free (cross platform?) XWindows program for people to run their office apps, but that has it's problems too...primarily that it's SOOO slow and unresponsive. I tried to run a visual ANSYS environment connected to a university computer, and the graphics refresh rate was incredibly slow.

So now we're close to a solution, but we're still not there. We need a middle ground. Something more flexible than html, but less flexible than XWindows, and won't run without an internet connection. (Yeah, that last bit might seem restrictive, but since Google's prime choice is web services, it wouldn't make sense to provide services that don't require the web.)

Let's see now...we all use html, and a web browser to view it. The computer doesn't have to transmit the shape of each letter, it just says "this letter in this font and this size" and the browser takes care of the rest. Why not have another markup language for applications, and use a different kind of browser to view things with it. The browser would be responsible for "common" features like menus & menu bars, child windows, standard icons, panes, messageboxes, and even common controls like sliders, buttons, treeviews, etc.--the basic stuff that we expect a variety of programs to have. However, the business logic is all done by the server. When the Application Browser connects to a remote application file (.raf), the browser receives enough information to populates its menus, bring up the default screen (maybe with a logon request?), and establish a working (non-static) connection with the server. When a menu is opened, it responds immediately (because menu processing happens on the local computer), but when a menu item is selected, a corresponding request is sent to the server (except for, say, menu/toolbar customization request). The processing is handled remotely, and the screen is updated appropriately. The only significant source of lag is if an image or graph is being displayed, like when someone performs panning on a map or zooms in on a chart.

The nice part of all this is that a minimum amount of information is sent to the users computer. Just a little text here and there, and the Application Browser knows how to do its thing. I must admit, one of the best things about this approach is that since the information is reduced to only its critical text-based components (except in image loading), the use of Lisp is greatly rewarded. I'm familiar with what Paul Graham did with Viaweb over or about 10 years ago--he basically used Lisp to not only serve up web pages but also allow the easy creation of said web pages. I've found that the reason he could do it was because he was working with a small, well-defined output format: HTML. It was static, simple, and no one expected much of it. This was before Ruby on Rails, flash, and (I could be wrong about this one) JavaScript. Interactive web pages were not required. Because he had a limited playing field, he could easily manipulate it as he needed using ONLY text files. Now, technically, someone could come along and write something in Lisp that outputs JavaScript and html, but seriously...using a programming language to write code for another programming language? That's kinda crazy--it's way more sane to write an programming language that produces output in a certain standard protocol. What we need is an Application Protocol. Something that allows us to express (in text) the basic interactions of software between the server and the user, without being bogged down in details (like getting the menus wide enough to accommodate all their entries).

Also, because the developer is hosting the program, access to the program is under control of developer, as well as updates and bug fixes.

Bottom line, html has outgrown its shell. These things like JavaScript are patches that emulate interactive web pages, but the bottom line is, they're still web pages. Web programs, on the other hand, seem to have a future. Unfortunately, it doesn't look like there are many (any?) protocols in place to handle this. I could be wrong...I still have to look at J2EE closer, and maybe CORBA ORBs. They might provide an answer, but I'm still learning.


Blogger gernika said...

I'm not sure that using one language to output another language is entirely crazy -- that is what C, C++, and Java do (respectively they translate to machine language and byte code). I would say it's OK as long as you are going from a higher level language to a lower level language.

9/19/2005 4:53 AM  Edit
Blogger infinityis said...

Good point. But there's one problem with that. With each level of abstraction, so many new features are added that it's difficult to make full use of the lower-level language, so a higher-level language will be inherently more inefficient (much like adding layers of management may make a business more organized, but it costs time and money to do so). I'd say that in addition to going from a higher level language to a lower level language, there must also be the condition that the two levels are substantially far apart. Not many sane people would choose to write programs in assembly or Java bytecodes. But people can (and often do) choose to write in C, C++, and Java. Maybe as languages evolve, we'll even see something that makes it look positively disgusting to write in anything less. Is Lisp that language? Paul Graham sure thinks so. As for me...I don't know...I like to think it is, but I have my doubts that Lisp in it's current form will do it. My reason: Lisp was king when everything was text-based. Text is the machine's version of language, good for command prompts and modern programming languages. I'd put my money more on something with a graphical interface (with optional text interface). I'd suggest something akin to Simulink (where each icon is an object), but maybe something like a flowchart. There's still a "programming knowledge required" chasm between people with ideas and computer programming. I know it's a tall order, but if someone comes along with the ability to do something like that...well, who knows, I can barely imagine a programming environment that can successfully do that in a easily-understood cross-discipline way. I suppose that's why it's all the better that Lisp is based on mathematical principles.

At any rate, I had two follow-up thoughts today from the original post. First, the method of using html pages may be bad for developing an online program, but they'll work just fine for "wizard-style" applications. Second, as you pointed out, there is a program standard (somewhat) that can be coded to--Java bytecodes. I don't know if that can be leveraged enough to create an online lisp-based JVM-run program, but it's an interesting idea...

Also, thanks for stopping by, you're the first known visitor I've had! :) Just out of curiosity, how did you come across it?

9/20/2005 7:09 PM  Edit
Blogger gernika said...


I found your blog through a search on Technorati for "Paul Graham" :)

Send me an email sometime at adam dot thorsen at geemail dot com (spelling is phonetic).

About your last post, i re-read it and what you are describing sounds a lot like Ajax...

9/20/2005 8:37 PM  Edit

Post a Comment

<< Home