Slashdot Mirror

Make the engine, upon which the winning succinct byte code runs, a new W3C standard browser programming language (or at least virtual machine) and reduce the Microsoft OS CD to those components required to create a web-delivered application platform using the winning engine. Such an engine would, of course, have some features that dynamically encached expansions (and/or "memoizations") similar to the Hotspot optimization technology that originated with the Self programming language (and was later adopted by Sun's Java Virtual Machine). Hence it would make sense to have the OS CD contain a partially pre-expanded/optimized code base.

Then, for delivery of software services to pre-existing platforms, create a legacy port of the services code to pre-existing W3C standards like XForms implemented in a downloadable ECMAScript Client/SOA library in a manner similar to the way TIBET(tm) does. The idea is to go "Live", ie: web-delivered, with a fundamentally new W3C base (whatever engine won the prize) but support legacy W3C environments for migration.

Again, this prize-oriented strategy would, of course, require a rigorous specification of the software services so the testing could be largely automated.

This approach addresses Microsoft's 2 biggest problems deriving from the same fundamental reality: Everyone has needed their OS to interoperate with the bulk of the information industry.

The first problem is ethical and really goes beyond the scope of my professional opinions to my public opinions about the support of property rights. Suffice to say, I have no trouble with someone who goes after a natural monopoly position and succeeds. I have a problem with someone who then refuses to use that position of success to fix the bug in the society that made them inordinately rich and their technology inordinately influential.

The second problem is technical, which is what my argument here is really all about.

Basically Microsoft's code bloat problem derives from its monopoly position. This may seem like a truism since all of the software "profession" suffers from code bloat, but only Microsoft can take this to monopolistic proportions -- proportions that make Ma Bell's monopolistic complexities of yore look Spartan.

So Microsoft has this problem and it has many programmers (contributing to the code-bloat problem). It also has mountains of cash.

So how can Microsoft bust its own monopoly position turning its many programmers (many newly laid off!) and mountains of cash into succinct code?

Monetary Incentives for the Programmers. For example, the original idea for the Hutter Prize was:

S = size of uncompressed corpus
P = size of program outputting the uncompressed corpus
R = S/P (the compression ratio).

Award monies in a manner similar to the M-Prize:

Previous record ratio: R0
New record ratio: R1=R0+X

Fund contains: $Z at the time of the new record
Winner receives: $Z * (X/(R0+X))

Something similar can be done with the size of the binary that passes the entire suite of tests for Microsoft's software suite.

What happens very rapidly is the programmers first apply their skills to maximally refactoring. What falls out is a series of legacy API layers written atop a tight core.

They'd have to spend more money on code testing to verify the compressed code-bases of the competing teams actually worked to spec but the results should be quite gratifying.

Make the engine, upon which the winning succinct byte code runs, a new W3C standard browser programming language (or at least virtual machine) and reduce the Microsoft OS CD to those components required to create a web-delivered application platform using the winning engine. Such an engine would, of course, have some features that dynamically encached expansions, memoizations, tablings and/or materialized views similar to the Hotspot optimization technology that originated with the Self programming language (and was later adopted by Sun's Java Virtual Machine). Hence it would make sense to have the OS CD contain a partially pre-expanded hence time-optimized code base.

Then, for delivery of software services to pre-existing platforms, create a legacy port of the services code to pre-existing W3C standards like XForms implemented in a downloadable ECMAScript Client/SOA library in a manner similar to the way TIBET(tm) does. The idea is to go "Live", ie: web-delivered, with a fundamentally new W3C base (whatever engine won the prize) but support legacy W3C environments for migration.

Again, this prize-oriented strategy would, of course, require a rigorous specification of the software services so the testing could be largely automated.

This approach addresses Microsoft's 2 biggest problems deriving from the same fundamental reality: Everyone has needed their OS to interoperate with the bulk of the information industry.

The first problem is ethical and really goes beyond the scope of my professional opinions to my public opinions about the support of property rights. Suffice to say, I have no trouble with someone who goes after a natural monopoly position and succeeds. I have a problem with someone who then refuses to use that position of success to fix the bug in the society that made them inordinately rich and their technology inordinately influential.

The second problem is technical, which is what my argument here is really all about.

Basically Microsoft's code bloat problem derives from its monopoly position. This may seem like a truism since all of the software "profession" suffers from code bloat, but only Microsoft can take this to monopolistic proportions -- proportions that make Ma Bell's monopolistic complexities of yore look Spartan.

So Microsoft has this problem and it has many programmers (contributing to the code-bloat problem). It also has mountains of cash.

So how can Microsoft bust its own monopoly position turning its many programmers and mountains of cash into succinct code?

Monetary Incentives for the Programmers, ala the Hutter Prize:

S = size of uncompressed code-base
P = size of program outputting the uncompressed code-base
R = S/P (the compression ratio).

Award monies in a manner similar to the M-Prize:

Previous record ratio: R0
New record ratio: R1=R0+X

Fund contains: $Z at the time of the new record
Winner receives: $Z * (X/(R0+X))

It may turn out that due the incomputability of Kolmogorov complexity, the growth of reward may need ultimatelyto go exponential but the principle remains true.

What happens very rapidly is the programmers first apply their skills to maximally refactoring. What falls out is a series of legacy API layers written atop a tight core.

They'd have to spend more money on code testing to verify the compressed code-bases of the competing teams actually worked to spec but the results should be quite gratifying.

Here's what I wrote back when there was still hope for Microsoft:

If I were in Ray Ozzie's shoes I would apply something like the The Hutter Prize for Lossless Compression of Human Knowledge to the entirety of MS's software services suite. This, of course, requires making a rigorous spec for testing purposes.

Make the engine, upon which the winning succinct byte code runs, a new W3C standard browser programming language (or at least virtual machine) and reduce the Microsoft OS CD to those components required to create a web-delivered application platform using the winning engine. Such an engine would, of course, have some features that dynamically encached expansions (and/or "memoizations") similar to the Hotspot optimization technology that originated with the Self programming language (and was later adopted by Sun's Java Virtual Machine). Hence it would make sense to have the OS CD contain a partially pre-expanded/optimized code base.

Then, for delivery of software services to pre-existing platforms, create a legacy port of the services code to pre-existing W3C standards like XForms implemented in a downloadable ECMAScript Client/SOA library in a manner similar to the way TIBET(tm) does. The idea is to go "Live", ie: web-delivered, with a fundamentally new W3C base (whatever engine won the prize) but support legacy W3C environments for migration.

Again, this prize-oriented strategy would, of course, require a rigorous specification of the software services so the testing could be largely automated.

This approach addresses Microsoft's 2 biggest problems deriving from the same fundamental reality: Everyone has needed their OS to interoperate with the bulk of the information industry.

The first problem is ethical and really goes beyond the scope of my professional opinions to my public opinions about the support of property rights. Suffice to say, I have no trouble with someone who goes after a natural monopoly position and succeeds. I have a problem with someone who then refuses to use that position of success to fix the bug in the society that made them inordinately rich and their technology inordinately influential.

The second problem is technical, which is what my argument here is really all about.

Basically Microsoft's code bloat problem derives from its monopoly position. This may seem like a truism since all of the software "profession" suffers from code bloat, but only Microsoft can take this to monopolistic proportions -- proportions that make Ma Bell's monopolistic complexities of yore look Spartan.

So Microsoft has this problem and it has many programmers (contributing to the code-bloat problem). It also has mountains of cash.

So how can Microsoft bust its own monopoly position turning its many programmers and mountains of cash into succinct code?

Monetary Incentives for the Programmers, ala the Hutter Prize:

S = size of uncompressed code-base
P = size of program outputting the uncompressed code-base
R = S/P (the compression ratio).

Award monies in a manner similar to the M-Prize:

Previous record ratio: R0
New record ratio: R1=R0+X

Fund contains: $Z at the time of the new record
Winner receives: $Z * (X/(R0+X))

What happens very rapidly is the programmers first apply their skills to maximally refactoring

So you go up to the airport kiosk, install these platforms (which takes a few hours since you have to hack in first to get admin access and download speed is molasses slow). Then you're good to go. Easy.

Make the engine, upon which the winning succinct byte code runs, a new W3C standard browser programming language (or at least virtual machine) and reduce the Microsoft OS CD to those components required to create a web-delivered application platform using the winning engine. Such an engine would, of course, have some features that dynamically encached expansions (and/or "memoizations") similar to the Hotspot optimization technology that originated with the Self programming language (and was later adopted by Sun's Java Virtual Machine). Hence it would make sense to have the OS CD contain a partially pre-expanded/optimized code base.

Then, for delivery of software services to pre-existing platforms, create a legacy port of the services code to pre-existing W3C standards like XForms implemented in a downloadable ECMAScript Client/SOA library in a manner similar to the way TIBET(tm) does. The idea is to go "Live", ie: web-delivered, with a fundamentally new W3C base (whatever engine won the prize) but support legacy W3C environments for migration.

Again, this prize-oriented strategy would, of course, require a rigorous specification of the software services so the testing could be largely automated.

This approach addresses Microsoft's 2 biggest problems deriving from the same fundamental reality: Everyone has needed their OS to interoperate with the bulk of the information industry.

The first problem is ethical and really goes beyond the scope of my professional opinions to my public opinions about the support of property rights. Suffice to say, I have no trouble with someone who goes after a natural monopoly position and succeeds. I have a problem with someone who then refuses to use that position of success to fix the bug in the society that made them inordinately rich and their technology inordinately influential.

The second problem is technical, which is what my argument here is really all about.

Basically Microsoft's code bloat problem derives from its monopoly position. This may seem like a truism since all of the software "profession" suffers from code bloat, but only Microsoft can take this to monopolistic proportions -- proportions that make Ma Bell's monopolistic complexities of yore look Spartan.

So Microsoft has this problem and it has many programmers (contributing to the code-bloat problem). It also has mountains of cash.

So how can Microsoft bust its own monopoly position turning its many programmers and mountains of cash into succinct code?

Monetary Incentives for the Programmers, ala the Hutter Prize:

S = size of uncompressed code-base
P = size of program outputting the uncompressed code-base
R = S/P (the compression ratio).

Award monies in a manner similar to the M-Prize:

Previous record ratio: R0
New record ratio: R1=R0+X

Fund contains: $Z at the time of the new record
Winner receives: $Z * (X/(R0+X))

What happens very rapidly is the programmers first apply their skills to maximally refactoring. What falls out is a series of legacy API layers written atop a tight core.

They'd have to spend more money on code testing to verify the compressed code-bases of the competing teams actually worked to spec but the results should be quite gratifying.

With purchase of Tibet at regular price.

(As an aside, I was hoping this was an article mentioning my friend's enterprise AJAX platform: TIBET.)

Microsoft has at least 2 really big problems deriving from the same fundamental reality: Everyone needs their OS to interoperate with the bulk of the information industry.

The first problem is ethical and really goes beyond the scope of my professional opinions to my public opinions about the support of property rights. Suffice to say, I have no trouble with someone who goes after a natural monopoly position and succeeds. I have a problem with someone who then refuses to use that position of success to fix the bug in the society that made them inordinately rich and their technology inordinately influential.

The second problem is technical, which is what my argument here is really all about.

Basically Microsoft's code bloat problem derives from its monopoly position. This may seem like a truism since all of the software "profession" suffers from code bloat, but only Microsoft can take this to monopolistic proportions -- proportions that make Ma Bell's monopolistic complexities of yore look Spartan.

So Microsoft has this problem and it has many programmers (contributing to the code-bloat problem). It also has mountains of cash.

So how can Microsoft bust its own monopoly position turning its many programmers and mountains of cash into succinct code?

Monetary Incentives for the Programmers, ala the C-Prize:

S = size of uncompressed code-base
P = size of program outputting the uncompressed code-base
R = S/P (the compression ratio).

Award monies in a manner similar to the M-Prize:

Previous record ratio: R0
New record ratio: R1=R0+X

Fund contains: $Z at noon GMT on day of new record
Winner receives: $Z * (X/(R0+X))

What happens very rapidly is the programmers first apply their skills to maximally refactoring the code. What falls out is a series of legacy API layers written atop a tight core.

They'd have to spend more money on code testing to verify the compressed code-bases of the competing teams actually worked to spec but the results should be quite gratifying.

Microsoft has at least 2 really big problems deriving from the same fundamental reality: Everyone needs their OS to interoperate with the bulk of the information industry.

The first problem is ethical and really goes beyond the scope of my professional opinions to my public opinions about the support of property rights. Suffice to say, I have no trouble with someone who goes after a natural monopoly position and succeeds. I have a problem with someone who then refuses to use that position of success to fix the bug in the society that made them inordinantly rich and their technology inordinantly influential.

The second problem is technical, which is what my argument here is really all about.

Basically Microsoft's code bloat problem derives from its monopoly position. This may seem like a truism since all of the software "profession" suffers from code bloat, but only Microsoft can take this to monopolistic proportions -- proportions that make Ma Bell's monopolistic complexities of yor look Spartan.

So Microsoft has this problem and it has many programmers (contributing to the code-bloat problem). It also has mountains of cash.

So how can Microsoft bust its own monopoly poisition turning its many programmers and mountains of cash into succinct code?

Monetary Incentives for the Programmers, ala the C-Prize:

S = size of uncompressed code-base
P = size of program outputting the uncompressed code-base
R = S/P (the compression ratio).

Award monies in a manner similar to the M-Prize:

Previous record ratio: R0
New record ratio: R1=R0+X

Fund contains: $Z at noon GMT on day of new record
Winner receives: $Z * (X/(R0+X))

What happens very rapidly is the programmers first apply their skills to maximally refactoring the code. What falls out is a series of legacy API layers written atop a tight core.

They'd have to spend more money on code testing to verify the compressed code-bases of the competing teams actually worked to spec but the results should be quite gratifying.

Too many of the JS/DHTML toolkits have the "you must use our APIs for everything, including how you manipulate strings" disease. Some are cool, for example TIBET, which looks a lot like Smalltalk.

From Harry Feucks' blog:

As far as I know, Tibet is the only Open Source project today which would be capable of making this happen

Too many of the JS/DHTML toolkits have the "you must use our APIs for everything, including how you manipulate strings" disease. Some are cool, for example TIBET, which looks a lot like Smalltalk.

From Harry Feucks' blog:

As far as I know, Tibet is the only Open Source project today which would be capable of making this happen

Ironically, the real value in XMLHTTPRequest isn't that communication can be asynchronous. Form submissions, the previous way of handling server communication, were and still are asynchronous. XMLHTTPRequest actually makes it possible to support _synchronous_ calls and provides a single unified way to make either type of call.

Most writings on AJAX would have you believe that's enough -- make an asynchronous call, get an AJAX application. Unfortunately, as anyone who's done much programming with asychronous calls (aka threads) can tell you, making the call is the easy part -- it's coordinating the results that's hard. A simple real world example highlights "the sync problem".

The Sync Problem

Its a common client-side requirement to fetch a template containing static data along with dynamic data from a web service call, blend them into a single UI element, and then display that element in a portion of the user's currently displayed page. In this common case you've got two separate data sources meaning you have two separate calls whose results have to be blended only after both complete. When confronted with this reality most developers switch to making synchronous calls (taking advantage of XMLHTTPRequest's truly new feature to "cheat"). If you decide to hang in there and stay with the asynchronous call format that's great, but we've yet to see a single AJAX toolkit that offers you any kind of multiple-request coordination -- so you'll end up writing the synchronization logic yourself.

If you use TIBET its simple:

// set up two requests to make the async calls (you can have more if you like)
request1 = ServiceRequest.create(dc('async',true,'other','par ameters'));
request2 = ServiceRequest.create(dc('async',true,'some','para meters'));

// create a function to observe the completion signal we'll be sending below
response = function(aSignal) { alert('The requests are done'); };

// create an "And Join" saying both need to complete (TIBET also supports "Or Joins")
join = TPAndJoin.create('AllDone');
join.addObservation(request1);
join.addObservation(request2);

// tell our response function to observe the signal our join will send
response.observe(join, 'AllDone')

// activate the requests...TIBET handles the rest
request1.activate();
request2.activate();

If job security for existing MS programmers is an issue, just given them all a yearly decreasing proportion of their current salaries for the next 5 years: 100%, 80%, 60%, 40%, 20% -- and during that time let them find financing to compete.

Perhaps MS is realising that the WinTel combo -- a software platform based on the 8086 family -- is threatened by a new foundation to which applications can be written: the "virtual machine" of Javascript/DHTML with XSLT (and other XML processing) based in the browser.

That was certainly the vision for TIBET(tm) when conceived 5 years ago.

PS: Yes -- Java applets have been out there all the time and failed for the very good reason that they aren't an integral part of the presentation engine of the browsers.

The authors of Perl and TIBET(tm) are all over 40. The authors of Rails are largely under 30 but they aren't stuck on Java's marching moronism.

All of them do almost all their work in open source environments.

TIBET(tm) (a Javascript library that's up there with CPAN in terms of comprehensiveness) has the muscle to do this sort of thing: Client-side expansion of custom tags, webservices, local file access, fully reflective.... I wonder why they didn't use it. Or did they?

I previous poster made legitimate points that Java brought garbage collection, reflection and runtime safety into the popular eye. However, there are other widely used, well-standardized languages with those same features, namely Javascript.

C# may be better in key respects than Java, but I have trouble conceiving of C# as a really open standard. The ECMA standard for Javascript is already supported by a variety of companies(i.e. IBM, Lotus, Microsoft, AOL/Time/Warner/Netscape) in a variety of products.

The folks at have shown that they can extend Javascript quite a bit-even in browser implementations.For all of the talk of C#, one thing that is interesting about .Net IMHO is the they've provided an interesting platform for server side Javascript. If mono takes off at all on Linux, I'd expect we'd see a growth in the server-side Javascript community and the promised that were made for Java early on would start to be delivered through a different language.

I'm a DBA and Perl/Python programmer. I've used Java for class projects at CMU. Java and C# both strike me as overly complicate for most of the work I do on a day by day basis. Javscript isn't there yet-but I can see that it might get there. There is a real niche for a well standardized, universally available scripting language that just hasn't been filled yet. If a small fraction of the engineering effort applied to Java were applied in this direction, I'd expect big benefits.

I previous poster made legitimate points that Java brought garbage collection, reflection and runtime safety into the popular eye. However, there are other widely used, well-standardized languages with those same features, namely Javascript.

C# may be better in key respects than Java, but I have trouble conceiving of C# as a really open standard. The ECMA standard for Javascript is already supported by a variety of companies(i.e. IBM, Lotus, Microsoft, AOL/Time/Warner/Netscape) in a variety of products.

The folks at have shown that they can extend Javascript quite a bit-even in browser implementations.For all of the talk of C#, one thing that is interesting about .Net IMHO is the they've provided an interesting platform for server side Javascript. If mono takes off at all on Linux, I'd expect we'd see a growth in the server-side Javascript community and the promised that were made for Java early on would start to be delivered through a different language.

I'm a DBA and Perl/Python programmer. I've used Java for class projects at CMU. Java and C# both strike me as overly complicate for most of the work I do on a day by day basis. Javscript isn't there yet-but I can see that it might get there. There is a real niche for a well standardized, universally available scripting language that just hasn't been filled yet. If a small fraction of the engineering effort applied to Java were applied in this direction, I'd expect big benefits.

Those technologies offer a standards based means of doing UI's. The web isn't going away, and gradually browsers are getting closer to what we can do on the desktop. There are folks having some luck extending Javascript with Smalltalk features.
There already exist well supported compilers for Javascript-and those could be highly optimized with the right effort.

Javscript is _already_ well supported by Microsoft(they are supporting it as one of the major languages for the Windows Scripting Host). IMHO VBScript is just plain too buggy and ugly.

IMHO languages like Python/Perl/Ruby the best mainstream tools for Server Side Development(though Mozart-Oz has some interesting features). Client side? The browser appears to be the client of the future--and folks doing desktop stuff had best figure out how to deal with that.

TIBET(tm) 2.0 is being released with the moral equivalent of CPAN compressed into around 200k of gzipped ECMAScript. It's pure ECMAScript -- and includs client-side tag expansion to active client pages, as well as support for web services, Jabber, etc.

The OSI approved SleepyCat license is used with a number of software projects including XAO Apache Web Services and the very widely used dual licensed Berkeley DB software products. The WayBackMachine has a WinterSpeak interview from 2001 with Sleepycat President & CEO, Michael Olson on How to make money with the GPL ...

Berkeley DB is embedded in network infrastructure products like routers and switches, DNS and Web content caches, email servers and clients, ... Companies like Cisco, Sun, HP, IONA, Amazon and Sendmail use Berkeley DB. Open source projects like Cyrus, Squid, RPM, Postfix, and MySQL include it.

The OSI approved Reciprocal Public License (RPL) while used infrequently is reportedly more viral than GPL, actually extremely viral per Technical Pursuit which dual licenses Tibet potentially requiring payment under TPL Biz licensing when not in compliance with RPL.

Are there other projects, licensing & circumstances of note that might be similarly surprising or problematic to OSS/FS users ???

The OSI approved SleepyCat license is used with a number of software projects including XAO Apache Web Services and the very widely used dual licensed Berkeley DB software products. The WayBackMachine has a WinterSpeak interview from 2001 with Sleepycat President & CEO, Michael Olson on How to make money with the GPL ...

Berkeley DB is embedded in network infrastructure products like routers and switches, DNS and Web content caches, email servers and clients, ... Companies like Cisco, Sun, HP, IONA, Amazon and Sendmail use Berkeley DB. Open source projects like Cyrus, Squid, RPM, Postfix, and MySQL include it.

The OSI approved Reciprocal Public License (RPL) while used infrequently is reportedly more viral than GPL, actually extremely viral per Technical Pursuit which dual licenses Tibet potentially requiring payment under TPL Biz licensing when not in compliance with RPL.

Are there other projects, licensing & circumstances of note that might be similarly surprising or problematic to OSS/FS users ???

I didn't write the RPL(it was written by Scott Shattuck at Technical Pursuit--but I helped with some of the legal research and also helped walk the license through the OSI approval process.

I'm also glad to see folks doing more with the capabilities within a browser. The folks that are taking this the furthest that I've seen are the folks at Technical Pursuit.

It must also be recognised that while the technology to build really powerful web application is there in IE, Mozilla, Opera and al, there are very few really interactive applications using those technologies, simply because there is not enough compatibility between the various standard implementations, and to work around those is too costly and difficult to manage well.

Check out TIBET from Technical Pursuit. It's a full browser application environment, built using JavaScript. They decided on JavaScript, because it's the only language guaranteed to be on the client side. When they were building out the libraries, they found that it was more powerful than they expected. They've actually extended the language, using only the language itself.

Applications have to pull down a large (1 MB plus) set of JavaScript libraries. So this isn't for web applets, or even server-based web applications. (Although it's easy for the code to communicate with the server.) It's meant for full-blown applications that will run completely in the browser.

They also include some application development tools. (I haven't taken a look at those yet.) The whole thing is available under an Open Source license or under a proprietary license if you prefer.

Why doesn't anyone discuss the RPL (Reciprocal Public License)?

RECIPROCAL PUBLIC LICENSE
Version 1.0, December 21, 2001

Copyright (C) 2001-2002
Technical Pursuit Inc.,
All Rights Reserved.

PREAMBLE

This Preamble is intended to describe, in plain English, the nature,
intent, and scope of this License. However, this Preamble is not a part
of this License. The legal effect of this License is dependent only upon
the terms of the License and not this Preamble.

This License is based on the concept of reciprocity. In exchange for
being granted certain rights under the terms of this License to
Licensor's Software, whose Source Code You have access to, You are
required to reciprocate by providing equal access and rights to all
third parties to the Source Code of any Modifications, Derivitive Works,
and Required Components for execution of same (collectively defined as
Extensions) that You Deploy by Deploying Your Extensions under the terms
of this License. In this fashion the available Source Code related to
the Licensed Software is enlarged for the benefit of everyone.

Under the terms of this License You may:

a. Distribute the Licensed Software exactly as You received it under the
terms of this License either alone or as a component of an aggregate
software distribution containing programs from several different
sources without payment of a royalty or other fee.

b. Use the Licensed Software for any purpose consistent with the rights
granted by this License, but the Licensor is not providing You any
warranty whatsoever, nor is the Licensor accepting any liability in
the event that the Licensed Software doesn't work properly or causes
You any injury or damages.

[snip]

Why doesn't anyone discuss the RPL (Reciprocal Public License)?

RECIPROCAL PUBLIC LICENSE
Version 1.0, December 21, 2001

Copyright (C) 2001-2002
Technical Pursuit Inc.,
All Rights Reserved.

PREAMBLE

This Preamble is intended to describe, in plain English, the nature,
intent, and scope of this License. However, this Preamble is not a part
of this License. The legal effect of this License is dependent only upon
the terms of the License and not this Preamble.

This License is based on the concept of reciprocity. In exchange for
being granted certain rights under the terms of this License to
Licensor's Software, whose Source Code You have access to, You are
required to reciprocate by providing equal access and rights to all
third parties to the Source Code of any Modifications, Derivitive Works,
and Required Components for execution of same (collectively defined as
Extensions) that You Deploy by Deploying Your Extensions under the terms
of this License. In this fashion the available Source Code related to
the Licensed Software is enlarged for the benefit of everyone.

Under the terms of this License You may:

a. Distribute the Licensed Software exactly as You received it under the
terms of this License either alone or as a component of an aggregate
software distribution containing programs from several different
sources without payment of a royalty or other fee.

b. Use the Licensed Software for any purpose consistent with the rights
granted by this License, but the Licensor is not providing You any
warranty whatsoever, nor is the Licensor accepting any liability in
the event that the Licensed Software doesn't work properly or causes
You any injury or damages.

[snip]

We had a guy speak to our users group about their Open Source product called TIBET that takes JavaScript to its limits. They've implemented language constructs that the JavaScript designers were surprised by. Things like closures, a type system, multiple inheritence, and meta-classes. The whole system (about 1MB) is downloaded to the client system, and everything runs on the client system without having to pull down anything but data from the server. Very impressive.

For #1 you might see if TIBET fits your needs. Its got a huge library written in JavaScript and is complementary to SVG's widgetry.

For #1 you might see if TIBET fits your needs. Its got a huge library written in JavaScript and is complementary to SVG's widgetry.

For #1 you might see if TIBET fits your needs. Its got a huge library written in JavaScript and is complementary to SVG's widgetry.

I resemble that remark not to mention some other guys I know (search for "javasoft" for some humorous anecdotes).

Our heroic New Yorker author, with a single leap, bounded right over duos like the Wright Brothers and Atanasoff and Berry as well as small hunting packs like Id Software and small tribal clans like the Seymour Cray 34.

The Hiermenus are not "simple DHTML menus". They are extremely capable menus that work with an unprecedented set of browsers and capabilities, with good ease of use.

And if you want more than just capable menus, check out Tibet, a full client-server architecture for the web. These guys started by using JavaScript to fix the bugs in various browser JavaScript implementations, and then proceeded to build class libraries, debugging tools, client-side page templates, and a full IDE. All in JavaScript. And I'm not making an April Fools joke.

Also, the code is dual-licensed, commercial and open source.

The code is beta at the moment, and there is much work to do, but this is a seriously ambitious undertaking.

And no, I don't work for them or otherwise benefit from this heading-towards-off-topic post.

The most widely deployed Turing Complete machine/language is a close race beteween Javascript and the Wintel machine code, with Java a distant 3rd. Since there is a problem with reliance on machine code for dynamic installation of software over the network, that leaves Javascript the most obvious candidate in which to write other languages. Most people never thought of Javascript as anything but an afterthought to HTML so they might have their eyes opened a bit to the power of Turing Completeness by seeing the TIBET virtual machine written in about a 100K Javascript embeded in a web site's (gzipped) HTML. It gets away with this by dynamically patching (Perl-config style) Javascript incompatibilities and building out from the set of features thereby supported cross-browser.

As I've written elsewhere, this isn't the ultimate language by any means -- but it is a critically needed repair to the foundation of the web that can be followed by more advanced VM's later on.

Apparently, page 144 of Flanagan's otherwise Definitive Guide to JavaScript concerning inheritance in that language misled many to believe that multi-level inheritance would not be possible in JavaScript. As it turns out, not only is multi-level inheritance possible, but so are class methods/attributes, meta-classes and even multiple inheritance and fun stuff like instance level programming ala Self. Apparently JavaScript is a lot more capable than most people, even some of the better experts in it, give it credit for being.

It would be great if TIBET got released at the WWW10 conference, but I think registration deadlines for vendors has passed.

The future of the Internet is in what I call "rational programming" derived from a revival of Bertrand Russell's Relation Arithmetic. Rational programming is a classically applicable branch of relation arithmetic's sub theory of quantum software (as opposed to the hardware-oriented technology of quantum computing). By classically applicable I mean it is applies to conventional computing systems -- not just quantum information systems. Rational programming will subsume what Tim Berners Lee calls the semantic web. The basic problem Tim (and just about everyone back through Bertrand Russell) fails to perceive is that logic is irrational. John McCarthy's signature line says it all about this kind of approach: "He who refuses to do arithmetic is doomed to talk nonsense." More on this a bit later, but first some history, because he who fails to learn from history is doomed to repeat its nonsense:

When I invented the precursor to Postscript (an audacious claim that I can back up -- it started as a replacement for NAPLPS which I proposed while Manager of Interactive Architectures for Viewdata Corp of America back in November of 1981 -- the Xerox PARC guys found my approach of what they called a "tokenized Forth" communication protocol to be an intriguing way to encode text and graphics), I was interested in having a Forth virtual machine migrate into silicon (ala Novix) so it could evolve from mere graphics rendering into a distributed Smalltalk VM environment (ala Squeak) as videotex terminal/personal computer capacities increased. But I was _not_ interested in object-oriented programming as the long-term semantics of distributed programming environments. (I still have some of the hardcopy of the communiques with Xerox PARC and others from this period.)

Rather, relational semantics were what I saw as the ultimate direction for distributed programming. I had a bit of a go at Tony Hoare's "communicating sequential processes" paradigm and its Transputer realization because he was, at least, starting with the hard problem of parallelism rather than making like the drunk looking for his keys under the light post the way everyone else seemed to be doing (and still are, save for Mozart, since threads, etc. are always an afterthought). But, because there were other hard problems like abstraction, transactions and persistence that he ignored, I christened his approach "Occam's Chainsaw Massacre" in my communiques (in honor of his distributed programming language "Occam") and dropped it in favor of relational programming, which has inherent parallelism resulting from both dependency and indeterminacy. (BTW: Dr. Hoare seems to have finally come to his senses about this issue.)

Unfortunately, the only researcher doing hardcore work on relational programming (meaning, getting to the root of relational semantics in a way that Codd had failed to do) at the time was Bruce MacLennan, then, of The Naval Postgraduate School, and he just didn't have the glamour of Alan Kay at places like Xerox PARC to attract the attention of guys like Steve Jobs. Bruce had a bit of a blind-spot, too, when it came to transactions and persistence, which I attempted to remedy by bringing David P. Reed's work on distributed transactions for the ARPAnet to him, but although he wrote a white paper on a predicate calculus (close to a relational) implementation of Reed's thesis (MIT/LCS/TR-205), he didn't really "get it", IMHO. Reed and MacLennan abandoned their work for other pursuits (ironically, Reed was chief scientist at Lotus while Notes was being developed but did not contribute his ideas on distributed synchronization to that development despite the fact that we had a mutual acquaintance from my Plato days by the name of Ray Ozzie -- so, I share some of the blame for this failure) even as Steve Jobs botched the embryonic object oriented world by abandoning Smalltalk and giving us, instead, a lineage consisting of Object Pascal on the Lisa/Mac which begat Objective C on Jobs's NeXT which begat Java at Sun via Naughton and Gosling's experience with NeXT.

This brings us to the present -- a world in which Javascript-based technologies like Tibet promise to not only salvage the object oriented aspect of the Internet from the birth defects of Jobs's spawn, but actually provide an advance over Smalltalk in the same lineage as CLOS and Self. But it is also a world in which there is growing confusion over the proper role of "metadata" in the form of XML -- particularly when it comes to speech acts and distributed inference. I would call Tibet "the next major Internet advance" except for the fact that the basic idea for a Tibet-like system has been around and well understood since the early 1980's. When it is finally released, Tibet (or a system like it) will put the Internet back on track. I call that a "recovery", not an "advance".

We are now poised to move forward with type inference based on full blown inference engines, thereby dispensing with the nonterminating arguments over statically vs dynamically typed languages that allowed Steve Jobs's spawn to get its nose in the tent. If you want to declare a "type" in a declarative language, just make another declaration and let the inference engine figure out what it can do with that information prior to run time. See how easy that was? Well, there is more to it than that, but not that much: Assertions have implications and assertions made prior to run time have implications prior to run time. Live with it and don't repeat the mistakes of the past.

The confusion over semantic webs, and the reason Berners Lee et al will fail, is essentially the same as the confusion that has beleaguered all inferential systems such as logic programming and "artificial intelligence" over the years: logic is irrational and the real world demands rationality -- otherwise nothing makes sense. By "rationality" I mean that reasoning must literally incorporate "ratios" -- or, as John McCarthy would put it, doing arithmetic so things make sense. By making sense, I mean there is a sense in which one interprets the sea of assertions that clearly dominates for a particular purpose. With logic not only are you limited to 0 and 1 as effective quantities; you have no adequate theoretic basis from which to derive more accurate quantities with which to make sense by taking ratios and determining which inferences are dominant.

Fuzzy logic and expert systems incorporating probabilities have typically failed because they are not based in the first principles of probability and statistics. As Gauss, the premiere probability theorist put it, "Mathematics is the study of relations." He didn't say, "Mathematics is the study of multisets." There are good reasons that relational databases, and not set manipulation languages, have come to dominate business applications -- and Gauss was aware of these differences when he began to derive his laws of probability. Subsequent axiomatizations of mathematics based on set theory were similarly misguided and have led to the idea that "fuzzy sets" are the way to introduce rationality into programming. Rather than sets, relations are the foundation, not just of mathematics but of rationality in the same sense that Gauss realized when he derived his theory of probability from the study of relations.

Rationality allows for judgment which is recognized as inherently fallible -- but which allows one to procede without exponentiating all possible paths of inference. Judgment also allows various identities to limit sharing of information to that needed -- thereby creating speech acts and a basis for rational measures of credibility associated with those identities. Since credit-rating is a degeneration of credibility, it should come as no shock that the invention of negative numbers, originating as they did with the Arabic invention of double entry account keeping, has its analog in something that might be called "logical debt" with which negative probabilities are associated.

And now we have come to the "quantum" aspect of rational programming. It is precisely the "credibility debt" aspect of rational programming that corresponds, in mathematical detail, to the various equations of quantum mechanics and their negative probability amplitudes. (Von Neumann's quantum logic failed to properly incorporate logical debt which has led to much confusion.) Logical debt is important to distributed programming for the same reason debt is important to financial networks. Logical debt is a way of handling poor synchronization of information flow in the same way that financial debt is a way of handling poor synchronization of cash flow. As in any rational system, there are both limits to credit and limits to credibilty that influence one's judgments and actions, including speech acts.

The object oriented folks may, in a sense, have the last laugh here because when we divide up inference into identities that engage in speech acts, we are reintroducing the notion of objects that hide information via exchange of speech act messages that can be thought of as "setters" (assertions) and "getters" (queries). However, I believe it is only fair to recognize that the excellent intuitions of Johan Dahl and Kristen Nygaard did need the added insights and rigor of philosophers like J. L. Austin and T. Etter.

What are the chances that TIBET will ship?

If these guys want to have a serious impact on the platforms in use, they will either have to surf the existing platforms with something like TIBET(tm) or they will have to create a radically new platform that is so much better than anything else that it will seed a new regime of technology. For that, IMNSHO they should team up with the optical associative processing guys at Colorado State, the Mozart guys in Europe and the Postgresql guys before taking off to do yet another BeOS.

When I invented the precursor to Postscript (an audacious claim that I can back up -- it started as a replacement for NAPLPS which I proposed while Manager of Interactive Architectures for Viewdata Corp of America back in November of 1981 -- the Xerox PARC guys found my approach of what they called a "tokenized Forth" communication protocol to be an intriguing way to encode text and graphics), I was interested in having a Forth virtual machine migrate into silicon (ala Novix) so it could evolve from mere graphics rendering into a distributed Smalltalk VM environment (ala Squeak) as videotex terminal/personal computer capacities increased. But I was _not_ interested in object-oriented programming as the long-term semantics of distributed programming environments. (I still have some of the hardcopy of the communiques with Xerox PARC and others from this period.)

Rather, relational semantics were what I saw as the ultimate direction for distributed programming. I had a bit of a go at Tony Hoare's "communicating sequential processes" paradigm and its Transputer realization because he was, at least, starting with the hard problem of parallelism rather than making like the drunk looking for his keys under the light post the way everyone else seemed to be doing (and still are, save for Mozart, since threads, etc. are always an afterthought). But, because there were other hard problems like abstraction, transactions and persistence that he ignored, I christened his approach "Occam's Chainsaw Massacre" in my communiques (in honor of his distributed programming language "Occam") and dropped it in favor of relational programming, which has inherent parallelism resulting from both dependency and indeterminacy. (BTW: Dr. Hoare seems to have finally come to his senses about this issue.)

Unfortunately, the only researcher doing hardcore work on relational programming (meaning, getting to the root of relational semantics in a way that Codd had failed to do) at the time was Bruce MacLennan, then, of The Naval Postgraduate School, and he just didn't have the glamour of Alan Kay at places like Xerox PARC to attract the attention of guys like Steve Jobs. Bruce had a bit of a blind-spot, too, when it came to transactions and persistence, which I attempted to remedy by bringing David P. Reed's work on distributed transactions for the ARPAnet to him, but although he wrote a white paper on a predicate calculus (close to a relational) implementation of Reed's thesis (MIT/LCS/TR-205), he didn't really "get it", IMHO. Reed and MacLennan abandoned their work for other pursuits (ironically, Reed was chief scientist at Lotus while Notes was being developed but did not contribute his ideas on distributed synchronization to that development despite the fact that we had a mutual acquaintance from my Plato days by the name of Ray Ozzie -- so, I share some of the blame for this failure) even as Steve Jobs botched the embryonic object oriented world by abandoning Smalltalk and giving us, instead, a lineage consisting of Object Pascal on the Lisa/Mac which begat Objective C on Jobs's NeXT which begat Java at Sun via Naughton and Gosling's experience with NeXT.

This brings us to the present -- a world in which Javascript-based technologies like Tibet promise to not only salvage the object oriented aspect of the Internet from the birth defects of Jobs's spawn, but actually provide an advance over Smalltalk in the same lineage as CLOS and Self. But it is also a world in which there is growing confusion over the proper role of "metadata" in the form of XML -- particularly when it comes to speech acts and distributed inference. I would call Tibet "the next major Internet advance" except for the fact that the basic idea for a Tibet-like system has been around and well understood since the early 1980's. When it is finally released, Tibet (or a system like it) will put the Internet back on track. I call that a "recovery", not an "advance".

We are now poised to move forward with type inference based on full blown inference engines, thereby dispensing with the nonterminating arguments over statically vs dynamically typed languages that allowed Steve Jobs's spawn to get its nose in the tent. If you want to declare a "type" in a declarative language, just make another declaration and let the inference engine figure out what it can do with that information prior to run time. See how easy that was? Well, there is more to it than that, but not that much: Assertions have implications and assertions made prior to run time have implications prior to run time. Live with it and don't repeat the mistakes of the past.

The confusion over semantic webs, and the reason Berners Lee et al will fail, is essentially the same as the confusion that has beleaguered all inferential systems such as logic programming and "artificial intelligence" over the years: logic is irrational and the real world demands rationality -- otherwise nothing makes sense. By "rationality" I mean that reasoning must literally incorporate "ratios" -- or, as John McCarthy would put it, doing arithmetic so things make sense. By making sense, I mean there is a sense in which one interprets the sea of assertions that clearly dominates for a particular purpose. With logic not only are you limited to 0 and 1 as effective quantities; you have no adequate theoretic basis from which to derive more accurate quantities with which to make sense by taking ratios and determining which inferences are dominant.

Fuzzy logic and expert systems incorporating probabilities have typically failed because they are not based in the first principles of probability and statistics. As Gauss, the premiere probability theorist put it, "Mathematics is the study of relations." He didn't say, "Mathematics is the study of multisets." There are good reasons that relational databases, and not set manipulation languages, have come to dominate business applications -- and Gauss was aware of these differences when he began to derive his laws of probability. Subsequent axiomatizations of mathematics based on set theory were similarly misguided and have led to the idea that "fuzzy sets" are the way to introduce rationality into programming. Rather than sets, relations are the foundation, not just of mathematics but of rationality in the same sense that Gauss realized when he derived his theory of probability from the study of relations.

Rationality allows for judgment which is recognized as inherently fallible -- but which allows one to procede without exponentiating all possible paths of inference. Judgment also allows various identities to limit sharing of information to that needed -- thereby creating speech acts and a basis for rational measures of credibility associated with those identities. Since credit-rating is a degeneration of credibility, it should come as no shock that the invention of negative numbers, originating as they did with the Arabic invention of double entry account keeping, has its analog in something that might be called "logical debt" with which negative probabilities are associated.

And now we have come to the "quantum" aspect of rational programming. It is precisely the "credibility debt" aspect of rational programming that corresponds, in mathematical detail, to the various equations of quantum mechanics and their negative probability amplitudes. (Von Neumann's quantum logic failed to properly incorporate logical debt which has led to much confusion.) Logical debt is important to distributed programming for the same reason debt is important to financial networks. Logical debt is a way of handling poor synchronization of information flow in the same way that financial debt is a way of handling poor synchronization of cash flow. As in any rational system, there are both limits to credit and limits to credibilty that influence one's judgments and actions, including speech acts.

The object oriented folks may, in a sense, have the last laugh here because when we divide up inference into identities that engage in speech acts, we are reintroducing the notion of objects that hide information via exchange of speech act messages that can be thought of as "setters" (assertions) and "getters" (queries). However, I believe it is only fair to recognize that the excellent intuitions of Johan Dahl and Kristen Nygaard did need the added insights and rigor of philosophers like J. L. Austin and T. Etter.

As someone who has fielded around 100,000 lines of Perl, among the many "Real Soon Now" options for cross-platform web software development, I side with the strategy exemplified by Tibet 's approach to cross-browser compatiblity.

The difficulty of writing an application that will run on a variety of web browsers is already a primary challenge of software development. Adding more languages to the mix will only make things worse. Adding the relatively static Java to the dynamic Self-like Javascript was one of the biggest mistakes in the short history of the web (one for which Steve Jobs must accept a lot of the blame, but that is another story). By biasing toward installed language multiplicity rather than downloaded compatability-layer consistency, Komodo is in danger of becoming another, albiet lesser, mistake. IE isn't going to relinquish its dominance for a long time to come, not even with the US Federal Goverment fighting it.

IMNSHO, on the strength of environments like Tibet, demand for programmers of Javascript will beat Java "real soon now".

Watch this site for developments.

We were having difficulty with the standards committee controlling the North American Presentation Level Protocol Syntax -- the graphics protocol upon which the Viewtron videotex terminals built by Western Electric were based. Specifically, there wasn't enough programmability. The Western Electric terminal was so limited in capacity that we had to fit the graphics interpreter into a very few number of bytes, and could afford only a few thousand bytes of dynamically downloadable store. I had been enamored with Forth ever since the Byte magazine article about it about a year or so earlier (my first digital purchase was an HP35 so reverse polish didn't bother me perhaps as much as it should have). Even so, I was hunting around for options. Jim Thompson, another senior staff member with the Viewtron project, was also interested in Forth -- enough so that he had subscribed to the Forth newsletter, which he shared with me. Jim was supposed to develop a menu system to run on the central system. I had specifically asked that his menu system never achieve Turing Machine equivalence, because I knew what sort of horrors lay in wait for us if it did. Nevertheless, Jim eventually implemented GOLFBAL "Game Oriented Language for Business And Leisure" -- and it was a Forth derivative. I had rejected Forth as anything but the low level protocol and engine for the telesoftware graphics system and was fairly horrified to discover what he had done. In any case, it was this immersion in Forth we brought with us to our meeting with the Xerox PARC folks.

Now, I swear on a stack of bibles that after I met with the PARC folks and discussed the problems of graphics communications, I had no idea the industry could end up being stuck with Postscript as a type-setting standard. I can say this for a certainty because:

I wanted to see a Novix-style reduction-to-hardware of the Forth virtual machine so that Forth would become the macro assembly language. Then we could use the Forth silicon machine to start running dynamically downloaded Smalltalk -- or some similar high level language -- compiled for the Forth stack machine which would provide much more powerful graphics specifications than Forth itself.

I never imagined the Smalltalk guys would actually depart from Smalltalk itself as a graphical specification language.

By the time the PARC guys spun off Adobe with Postscript and its Forth-like engine, I had become more interested in constraint/relational programming semantics than object oriented semantics because it more naturally fits graphics description, distribution, nondeterminism and parallelism not to mention databases.

It was summer of 1982 when I met with Tesler for the last time -- and he had just left PARC to go work on Lisa. We were sitting in the empty Astrodome, I think it was, next to the convention center where the Commodore 64 was being introduced to the world market as part of the precursor to Comdex. 64K of memory! At any rate, Tesler and I discussed the reason he had abandoned Smalltalk for the Lisa. I had thought that type inference coupled with artful use of assembly language libraries would be sufficient on the Motorola 68000 family, but Tesler was insistent that Object Pascal was necessary for adequate speed. Frankly, I was apalled that Tesler had so easily abandoned Smalltalk with type inference since he had made specific mention of it as an optimization technique in his Byte article. But in a recent email exchange about this history, he told me type inference was never of much interest to him -- that others at Apple were hooked on Object Pascal.

The horrifying thing about all this is that when Steve Jobs took off from Apple to found NeXT, instead of correcting the nonsense with Postscript and going straight for Smalltalk with type inference, he repeated the mistake, only this time with Objective-C. Then, as I understand it, Objective-C was the precursor to Java with its reliance on declaration rather than inference for type checking. This despite the fact that Sun already had the Self programming language in house with type inference and dynamic optimization technologies that realized the potential of Smalltalk at along last. Unfortunately the only technology to make it bigtime from Sun's Self project was the Hotspot JVM.

Although these aren't exactly the same mistakes over and over, we're still struggling to get a decent, widely-used dynamically typed language "for everyone" that includes a pure OO library for graphics. Python isn't easily deployable and although I'm a Perl bigot, even I realize we're unlikely to get Perlscript installed in every browser anytime soon. Anyway I'm partial to prototype languages like Self when it comes to Smalltalk offspring. I do have hopes for TIBET as a way of turning Javascript into a powerful programming system across many platforms -- as outrageous as that sounds. I know Bill Edney and Scott Shattuck were some of the first NeXT hackers, but we can all pray for a swift recovery. This isn't an official announcement or anything -- but Bill and Scott did do a presentation at Hackers so I figure I can mention it in the mode of a "hot rumor".

As I said, I'm more into constraint/relational stuff these days myself, but it sure would be nice if someone brought the power originally in Smalltalk the ubiquity it deserved almost 20 years ago.