Slashdot Mirror

Gutting programmer effectiveness and routing new programmers into BASIC by a factor of at least 10 while maintaining, and even slightly improving the GUI is a great example of "not getting it". You can say OOP would become important in a few years and I can say the windowing GUI would become important in a few years with or without Jobs. But the revolution had already occured at PARC (and if you're focused on the mouse environment -- even a decade earlier at SRI which is where PARC, and indeed PLATO with its touch panel, got their inspiration -- I remember sitting in meetings at CERL/PLATO viewing the films of SRI's research in 1974 as part of PLATO's computer-based conferencing project).

DOS applications were starting to pick up on it despite the horrid CGA they had to work with initially -- and it wasn't because Jobs did the Mac. The Windowing GUI was inevitable and obvious to people with money as well as most personal computer programmers, especially once Tesler had already popularized it with his 1981 Byte magazine article.

Dynamic, late-binding programming environments that highly leverage the sparse nerd matrix out there -- like Smalltalk, Python, etc. -- are, however _still_ struggling to make it past the concrete barriers Jobs poured into the OO culture with the Mac.

When Jobs passed up Smalltalk for Object Pascal, and then again, with Next, passed up Smalltalk for Objective C, he set a pattern that continues to this day when Sun passed up that sun-of-Smalltalk, Self and went with that son-of-Objective-C, Java.

Gutting the superstructure of technology while maintaining appearances isn't leadership.

You're not Steve Blackburn are you? If you are, I thought you were at ANU/Amherst...

In any case, I spent a couple of summers working for the Persistant Java team at Glasgow. You can still find info on the implementation at:

PJama.

1. Capabilities: A concept that is literally over a decade old in OS design as can be seen by the POSIX 1.E standard that never got drafted (although some people prefer to call what POSIX suggested "privileges" and the fact that many operating systems support "encoding clearance into the filesystem and OS" otherwise known as capailities including Spring, EROS, KeyKOS, and Mungi.
   
   
2. Access Control Lists: Again this is an ancient concept which has been implemented in quite a number of OSEs including some versions of Solaris, *BSD and Win2K.

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.

Self: a little outdated now but there are still some interesting ideas in it (many of them were used to develop Java). You can find it somewhere on sun's website.

SELF wasn't really a big new paradigm, though. It worked on a few interesting ideas: dynamic compilation (which became Java's JIT), prototype-based OO, and a new widget system (Morphic, which lives on in Squeak).

I think prototypes are an interesting alternative to classes for OO programming, and it's something that hasn't been very seriously pursued since then. It's a purification of OO in some ways, as too is SELF's insistence that all access to instance variables be through method calls.

Alan Kay, who coined "object oriented", said before that he really named it incorrectly, because he felt message passing was a more interesting and powerful concept. I think SELF moved more in that direction.
--

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.

While there's no denying that C++ is a steaming heap of offal, ST is not the last word in OO languages.

I'd rate Self, Dylan, Cecil, and Common Lisp as OO languages with better designs than Smalltalk.

This is not to say ST is bad; in fact it's wicked cool. It's just not the last word in OO.

1. "A JIT is rushed" - The first time bytecode is compiled to native code it must be done quickly to avoid delay. That code may be inefficient, true, but it can also be instrumented with profiler like information that can be used by later passes of the compiler. You see, what the author is describing is not a JIT system but a dynamic optimizing compiler which has the opportunity to study the program during execution and recompile parts or all of that program based on that information.
2. "no leeway for boundary conditions" - Well here again you seem a bit confused and your example is naive. The native representation of a type is not fixed in Java, only the conceptual representation. To be a compliant Java implementation all results generated using 'int' (to use your example) must be consistent with the conceptual representation of 'int' when using the various operations. If the optimizing compiler finds a way to represent an 'int' in a more optimal way it is free to do so as long as the results of the operation don't change.
3. "garbage collection is slower than hand coded memory management" - You really ought to read some of the latest garbage collection papers. This is no longer true even for collectors managing C or C++ allocation. When given an environment like Java which doesn't allow pointers and other antiquated memory techniques a good dynamic compiler with a modern garbage collector is both faster and more efficient than any hand coded attempt on all but the most simple of applications.
4. "OOP and dynamic dispatch are inefficient" - Again, I urge you to read the papers at the Self site listed above. The way the Self, and now HotSpot, compilers work eliminates this bottle neck. I'll admit in early implementations of Smalltalk and Objective-C dynamic dispatch did add a small amount of overhead. Take a look at the documents on the HotSpot here and then tell me that dynamic dispatch is a problem.

Actually, you're wrong on both counts.

A moderately skilled assembly programmer can still write code that's faster than the code a compiler will generate without too much difficulty. Granted, it's bit tougher than it used to be, but it's by no means impossible or even unusual.

Second, a just-in-time compiler can outperform one that does compilation as a separate, pre-runtime step. This is because the JIT has access to runtime profile information that the static compiler doesn't.

Look at the papers on the Self project website -- they took a ferociously dynamic OO language and got its performance within a factor of two of C. Because they a) they had the profile information of the application as it ran, and b) had the compiler run transparently at runtime, they could do things like use the profile information to do inlining and other interprocedural optimizations, without fear of code bloat.

If you tried to precompile Self code, then your performance would be abysmal -- it would run at the speed of something like Python or Perl. This is because there are very few static invariants that a compiler can use to optimize the program.

DOS applications were starting to pick up on it despite the horrid CGA they had to work with initially -- and it wasn't because Jobs did the Mac. The Windowing GUI was inevitable and obvious to people with money as well as most personal computer programmers, especially once Tesler had already popularized it with his 1981 Byte magazine article.

Dynamic, late-binding programming environments that highly leverage the sparse nerd matrix out there -- like Smalltalk, Python, etc. -- are, however _still_ struggling to make it past the concrete barriers Jobs poured into the OO culture with the Mac.

When Jobs passed up Smalltalk for Object Pascal, and then again, with Next, passed up Smalltalk for Objective C, he set a pattern that continues to this day when Sun passed up that sun-of-Smalltalk, Self and went with that son-of-Objective-C, Java.

Gutting the superstructure of technology while maintaining appearances isn't leadership.

And where are the breakthru languages?

You just aren't looking.

• Cecil

• Dylan

• Haskell

• Objective CAML

• Sather

• Self

That is a very interesting report. But I'm not clear why you think XML will be a magic bullet, especially vis a vis IIOP. The central thesis of this article is that distributed computing is fundamentally harder than local computing in light of partial system failures and more difficult concurrency issues. They think this means we shouldn't even try to ever hide the locality of an object.

In the few years since they wrote that article, distributed systems really have taken off in a big way; especially with the web. And unless you are running in the process space of the database, distribution of transactions is your problem. So many of the problems they see with distributed systems are things you have to deal with to some extent anyway (concurrency and partial failures not least).

What has XML got to do with any of this? Its a resurgence of the message passing paradigm from a couple of shifts back. Maybe messages are better than objects--- so what. Its easy to map from one to the other so it can't be a big win. All the real issues are the same: settling on a happy DTD/IDL that people can live with, dealing with unstable servers, corrupted messages and partitioning the functionality among locations/ machines. In real life, they are both happier with one stateful server and a pile of (nearly) stateless clients.

In none of these things is it obvious to me how XML is better than IIOP (unless you are using a OO database). CORBA of today seems to be doing a reasonable thing--- making it possible to do distributed objects across interfaces which you know might be remote.

you can also find more into by going to here..and where you see "What are you looking for? Database description: Search of General Content including Research content ....type in 'spotless'.

here's a link for downloads :)

you can also find more into by going to here..and where you see "What are you looking for?
Database description: Search of General Content including Research content
....type in 'spotless'.

news does travel slow on slashdot these days. I remember submiting this article from palmstation.com a couple of months ago... and the link to the spotless system - experimental Java[TM]* system for the Palm Connected Organizer ...no doubt the fore-runner sun r&d project to the public news release.