Slashdot Mirror

Oh yeah, Emacs, not Eclipse. *facepalm* My bad. I just remember it was an IDE that I couldn't get working at the time, and had to dig through docs for literally days to figure out how to compile from the command line.

At least in the subject line of my original comment, # is just an infix representation for a tuple. From the Oz Tutorial:

"A common infix tuple-operator used in Oz is #. So, 1#2 is a tuple of two elements, and observe that 1#2#3 is a single tuple of three elements: '#'(1 2 3) and not the pair 1#(2#3). With the # operator, you cannot directly write an empty or a single element tuple. Instead, you must fall back on the usual prefix record syntax: the empty tuple must be written '#'() or just '#', and a single element tuple '#'(X).

I can't give opinions on all of these (and some are still in development at this time anyway), but here's a list of some languages with paralellism designed in:

• Erlang -- Very popular message passing/actor model based language.
• Scala -- A functional language with actor model concurrency for the JVM.
• Oz -- An exceptionally multiparadigm language.
• Occam-pi -- The modern version of the old occam for transputers; CSP style concurrency (I believe).
• Chapel -- Cray's parallel programming language for supercompters. Cray's entry into DARPA's HPCS programming language competition.
• X10
• Fortress -- Sun's language for serious scientific computing. It was Sun's entry into DARPA's HPCS programming language competition, but lost and is now open sourced.
• Eiffel SCOOP -- An effort to take a CSP model and make it elegantly compatible with object oriented programming

Lemme preface that I am not an expert at logic programming but it is what intrigues me at the moment. I'll try and explain why it intrigues me, and why I want to learn more. I'm not saying the following is true, but I will try to convey why I am curious about it.

Web services are potentially distributed over many places. The coolest stuff I've seen with regards to distributed programming is with logic programming languages.

Forget openness for a minute and read this: http://www.mozart-oz.org/documentation/dstutorial/node2.html#chapter.distmodel

Isn't this how you want to program and understand your web services, opening up a public interface, and wrapping interfaces to other's open services via wrappers when needed using this paradigm?

Logic programming handles dependencies well. I need a, b and c to do x maps to x :- a, b, c . A language like Mozart/OZ that lets you customize the search strategy and handles concurrency should allow you to deal with getting a, b and c from web services around the internet. Most of the time you aren't going to infinite loop, and especially in the areas where SQL is used, you aren't because your data is finite. And calling a REST web service that can be cached and has stateless connection semantics means you should be able to attempt to unify with it ( or its wrapper ) efficiently.

Most software from desktop software to server software will probably just be databases of data forward chained to other things like what is displayed on the screen in a concurrent manner. All software is going to be database software. And prolog et al are better than the current language of choice SQL. And with all the dependencies in software, isn't it nice that :- means 'depends on'? Maybe life is just one big makefile... ;-P

And though I don't pretend to understand linear logic, it is the logic of resources. So while you can use the fact that 1 = 3 - 2 as many times as you want in a proof, you can't spend the dollar you have in your pocket more than once to attain a goal. You can have a dollar and can use it to buy a pepsi and you can use it to buy a coke, but you can't use it to buy a pepsi and a coke. Doesn't this seem like it would map well to payment for web services? Or to novel search strategies? I dunno. Also if you read the Pi/Calculus/nomadic pict/join calculus (that last one is cool) pages somewhere it says that there is a correspondence between these and linear logic, though I forgot what it was supposed to be...

Side note: I want to experiment also with implementing protocols such as HTTP with DCGs or something like it. I want to be able to hook into every possible place without replacing any code. I think logic programming can do everything aspect oriented programming can but better and more understandably. Maybe this is a bad idea but maybe not.

I think the lazy/eager divide is not so important. You can make a lazy language perform an eager calculation or an eager language compute something lazily. It's merely a question of what is the default behavior.

If I had to bet on a weird new language taking the world by storm it would have to be OZ.

http://www.mozart-oz.org/

I'll just cite another "competitor":

"The Mozart Programming System is an advanced development platform for intelligent, distributed applications. The system is the result of a decade of research in programming language design and implementation, constraint-based inference, distributed computing, and human-computer interfaces. As a result, Mozart is unequalled in expressive power and functionality. Mozart has an interactive incremental development environment and a production-quality implementation for Unix and Windows platforms. Mozart is the fruit of an ongoing research collaboration by the Mozart Consortium.

Mozart is based on the Oz language, which supports declarative programming, object-oriented programming, constraint programming, and concurrency as part of a coherent whole. For distribution, Mozart provides a true network transparent implementation with support for network awareness, openness, and fault tolerance. Mozart supports multi-core programming with its network transparent distribution and is an ideal platform for both general-purpose distributed applications as well as for hard problems requiring sophisticated optimization and inferencing abilities. We have developed many applications including sophisticated collaborative tools, multi-agent systems, and digital assistants, as well as applications in natural language understanding and knowledge representation, in scheduling and time-tabling, and in placement and configuration."

The language you're describing has been around for a long time, under various names. I recommend you look into either erlang or mozart-oz.

We need a nice, clean, simple, powerful teaching language to replace C and Java.

There needs to be some kind of readily available interpretive programming language that allows people to start out programming in linear fashion, and later eases them into object-oriented coding.

Others have suggested Python. REBOL also is, IMO, a good choice.

Way outside the box, Oz almost basically meets the description (though compiled, it has an immediate environment, can be programmed basically linearly for very basic uses, and supports scaling up into more advanced models: OO, sure, but not just the OO model, also functional, logic/constraint programming, concurrent programming, distributed programming, etc.) OTOH, teaching kids Mozart might be challenging, but maybe not: it might be easier to grok without having a lot of programming preconceptions to break down.

You want to know the latest trends for Java-based web development? Fewer and fewer people are going to be doing Java-based web development in the future.

Fuck trends. They're wrong. Every day the industry continues to stay with its current ridiculous technologies when vastly superior ones were invented decades ago infuriates me further. If it doesn't infuriate you, you're not paying close enough attention.

My advice: read Lambda the Ultimate and Steve Yegge's blog. Endeavor to learn what the lambda calculus and referential transparency are. If you are sincerely interested in bettering yourself as a programmer and don't go find out who Alonzo Church was then so help me God I will kick you in the balls. Learn about SML and type inference. Learn about Haskell and monads. Learn about process calculi and Erlang. Learn about Lisp and code generation and domain-specific languages. Learn about Scheme and lexical closures and continuations. Learn about Smalltalk and what OO was really supposed to be. Learn about type theory and formalism and the Curry-Howard correspondence. Learn about Forth and Joy and how you can have a powerful, expressive language without even so much as a grammar. Learn about Intercal and Befunge and just how badly your choice of programming language can torture you. Learn about UML and Ruby on Rails and Seaside and agile programming and Java generics and Python generators. Learn about aspect-oriented programming, context-oriented programming and concept programming. Learn about multi-paradigm languages like OCaml or Oz. Learn about weird Lisp dialects with syntax like Rebol or Dylan.

Realize that library design is language design. Realize that asynchronous programming with callbacks and explicit state in a world where lightweight coroutines were around in the days of fucking Simula in the 60s for Christ's sake is cruel and unusual torture. (Sorry, pet programming construct.) Realize that the programming language research community, while considering systems programming a solved problem and generally not interested in talking about human factors, is doing some genuinely promising work. Did you know that there are conc

You're right! It would be better to get a technology designed for multi-threaded programming. But then you go on to push Java? I'm confused.

Now, granted, Java does provide builtin support for concurrency. Although that support is an implementation of the 30-year old monitor concurrency primitive, which even one of its principal inventors (Tony Hoare) long ago abandoned in favor of better things. Not to mention that Java's implementation of monitors is known to be broken (or at least was - maybe they've fixed it now?).

Doug Lea's util.concurrent package (now part of Java 1.5) certainly helps things on the Java front, but it's hardly a panacaea. Depending on the application, you may want to take a look at JCSP instead - it provides for an almost direct translation of ideas from Tony Hoare's CSP into Java. For languages with good concurrency support out of the box, you might try Erlang, Ada, Mozart/Oz, E, or Eiffel.

That would be Oz. In Oz you have dataflow variables on which you can synchronize without having to use explicit locks: if the value of an unbound variable is needed in some thread, it is blocked until some other thread binds it.
Run a procedure P in a new thread? thread {P ...} end.

Oz support for Haskell: fun lazy {F ...} ... end. Functions without "lazy" are strict as in Scheme and SML. Oz support for Erlang: {NewPort Stream Port}, {Send Port ...}. Oz support for Prolog: choice Alt1 [] Alt2 [] ... end, {Search.base.all Query}. Oz support for Java: class ... end. Oz also has support for finite domain constraints (X::4#7 meaning variable X must be between 4 and 7), etc, etc.

http://www.mozart-oz.org/

Ruby has made some important OO design contributions

It has ?! Like what ?! What's in Ruby that wasn't in other languages ?!!

For patience's sake, this is the problem...All I see are ideas that were in other languages, thrown together in a learn-as-you-go experiment. People think continuations are cool? Then look at Scheme and look at Smalltalk. You can't compare years of development to that experiment. Ruby is rubbish. Compare it to any Smalltalk implementation. Download a Common Lisp IDE (LispWorks, Franz) and tell me how cool Ruby is...When people diss Java, remember to also diss HotSpot. Can your little language optimize code statistically like that? I thought not...

You want new stuff? Look at Factor, Joy, the Mozart/Oz system, or Slate.
Wanna compile at gcc performance? Try Scheme with the Bigloo implementation, or Objective Caml. Bechmarks for Ocaml here (and for SML with MLTon compiler here.- The bechmarks for Bigloo were reomved some time ago).

I'll just post the buzzwords for Factor:

Continuations, exception handling.
Powerful and logical meta-programming facilities. Introspection, code generation and extension of both syntax and semantics is very easy.
Higher-order programming allows code blocks to be treated as data and used as parameters.
Highly minimalist, very consistent design. No layers upon layers of indirection, no confusing corner-cases, no poorly-thought-out features.
Postfix syntax with an extensible parser; values are passed on the stack.
Higher-order programming allows code blocks to be treated as data and used as parameters.
A powerful and very generic collections library allows many algorithms to be expressed in terms of bulk operations without micro-management of elements, recursion, or loops.
A very consistent object model based on generic predicate dispatch.
Arithmetic operations that closely model mathematical concepts, rather than just being a thin abstraction over underlying machine arithmetic. All integer operations are done in arbitrary precision, and exact fractions are supported. Complex numbers and complex-valued elementary functions are integrated.
Damn, that Slava Pestov is one smart dude.

When you see those languages, you kinda get sad that Ruby is such an attention-grabber, but I can see clearly that this is just because of disinformation. With the exception of Joy and Slate (for now, I hope), all the others I cited have pretty workable environments.

And by the way, you don't write LISP anymore, it's Lisp.

And they're explicitly working on making it work well with plain old C code. (I'm still wondering, though, if it might be advantageous to use languages with explicit dataflow support, like Oz.)

I wonder if this would handle concurrent programming and constraint-based inference Mozart far better than existing chip architectures.

What a mouthful huh?

We have secure, distributed programming languages, and we have multi-paradigm, distributed programming languages.

Next stop: secure, multi-paradigm, distributed programming [1],[2].

[1] The Oz-E project
[2] SCOLL: A Language for Safe Capability Based Collaboration

What a mouthful huh?

We have secure, distributed programming languages, and we have multi-paradigm, distributed programming languages.

Next stop: secure, multi-paradigm, distributed programming [1],[2].

[1] The Oz-E project
[2] SCOLL: A Language for Safe Capability Based Collaboration

Take a look at Oz if you want a modern well-designed language that actually understands concurrency.

I don't know alot about this but my understanding is that languages such as Mozart-oz which support constraint programming are ideal for this sort of thing. There's a demo here.
A company called Friartuck makes commercial scheduling software using Mozart.

I don't know alot about this but my understanding is that languages such as Mozart-oz which support constraint programming are ideal for this sort of thing. There's a demo here.
A company called Friartuck makes commercial scheduling software using Mozart.

I don't know alot about this but my understanding is that languages such as Mozart-oz which support constraint programming are ideal for this sort of thing. There's a demo here.
A company called Friartuck makes commercial scheduling software using Mozart.

At The Royal institute of technology here in Sweden it's mostly Java, but also Mozart Oz in some courses. I quite like it. Some things we learned would be very hard to get a feel for with other languages. You can easily get under the hood of Mozart Oz, although it's a very high level language.

In this recent book, I learned a really clean and elegant multi-paradigm programming language, and bottom-up method for constructing programs with the mozart facility. The language itself (Oz) is constructed and expanded along the book. It is really different from anything I read before. Although the book goes sometimes deep in the theory, you should be fine with lots of examples because of the simplicity and the power of Oz (yes, it's magic).
And your mom should not be reluctant to math, but you knew it already.
(A preview of the book was discussed on slashdot before its publication in March, so the pdf is no more available)

A nice thing to have: a computer program that knows many important theorems I1, I2, I3, ... so that the user can specify "apply I12" followed by an application of I19 and then I6 and so on. The program doesn't have to understand the theorems, just use them in a sequence of deductions, as directed by a mathematician.

Yeah, it's amazing nobody ever thought of that.

By far the neatest debugging possibilities I've seen is part of the Oz development suite... It can do things like: Lazy Display (your debugger won't get stuck long times on long lists, but you can unfold the whole list if you want), Thread Display, handling values still to be calculated, it even displays the evolution of any statement... Its a really powerful toy.

And, no, Java did not invent stack Traces (or Exceptions). Really.

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.

Get the book free while you can; it's gotten high praise, a real treat for getting a wide view of different styles of computer programming. It compares favorably with SICS.

Mozart & Oz are well-developed and worth a look--
your programming may improve because of them.

Cheers, Joel

p.s. here are quick excerpts:

The Mozart Programming System is an advanced development platform for intelligent, distributed applications. The system is the result of a decade of research in programming language design and implementation, constraint-based inference, distributed computing, and human-computer interfaces...

Mozart is based on the Oz language, which supports declarative programming, object-oriented programming, constraint programming, and concurrency as part of a coherent whole...

We have developed many applications including sophisticated collaborative tools, multi-agent systems, and digital assistants, as well as applications in natural language understanding and knowledge representation, in scheduling and time-tabling, and in placement and configuration.

Mozart-Oz is an example of a language that goes way beyond a simple OO paradign(and incorporates features of Functional, Logic and Constraint programming. The thing that most language designers (including the Mozart-Oz folks) miss is that much of business programming is built around _relational_ semantics(i.e. the basis of SQL).

Lisp has one of the best object-oriented paradigm implementation, Meta-Object Protocol among languages with both scripting and bytecompiling capabilities.

Scheme has been proved as a good language for GUI and configuration: GIMP, Sawfish, TeXmacs.

OCaml has all the power as Lips, just in syntax conviniect for many Java/C-poisoned brains to read faster. No wonder there are many real-world applications on it.

Haskell... I just love how it demonstrates that OOP is not everything (and even not enough) :)

Sun works for telecom industry - why not consider Erlang?

And don't ignore Mozart - it's multi-paradigm pradigm might be just what we all will thing as the best in 3-5 years.

The list is not complete, of course. And it's inspired by Functional Programming.

My main point here is: each of above languages, would it be in hands of Sun marketed instead of Java (with all that money invested to), would have quality of implementation much better than Java.

In fact, I am impressed how such poorly designed language as Java succeed so far on the market. It wouldn't without so much money behind. And without so many classes written by Sun to compensate the poor design of the core language itself.

Would Sun invest so much efforts and money to FP language then the result would be much better. Because quality is why FP matters.

The preformance of the FPL programmers working with very extremely complex requirements will always outrun the performance of C programmers. And that is more important than the runtime performance (remember Javaistic argumets about cheap and fast hardware resources?). There are many cases when run-time performance of FP programs will be better than C one, as most of low level details are already optimized and hidden in libraries and interpreters, while C programmers are still moving through lots of errors and mistakes in their reinventing the wheel projects.

The only problem is that all stupid managers, after reading commercials, don't want anythng else, but only C, Java and VB. I heard about projects where people use XML syntax for interpreted Lisp or Scheme code because they can tell the boss: "look, boss, it's not Lisp, it's just XML". Managers today just love XML and usually buy the trick. No wonder there is an official project of "flat" and XML notations for Curry, the language with Haskell and Prolog ideas.

Reading around his site I think I'm impressed by the volume of work put in, and (if it is indeed as he claims), the quality of e.g. complex number manipulation.

Mozart is a poor choice of name, unless it is very very very old - because it is already taken by a programming system (see the Oz language).

Also, check out Pliant which is (relatively) mature, and does most of what is discussed on the site and a whole lot more.

The first book try to condense modern computer science into a few hundred pages written for a layman (much like "A brief history of time" does it for physics). The second combines everything interesting (Art, music, mathematics, philosophy, literature, genetics, etc), with programming, and is among the most interesting books I've ever read.

The foundations of programming in Scheme is covered quite well in "Abelson & Sussman: Structured Interpretation of Computer Programs". But this is only one view. You may also want to read "Bertrand Meyer: Object-oriented software construction" for a relatively different view (more mainstream). Of course, when it comes to programming, there are no hard facts, and people tend to have a lot of differing opinions.

Functional programming and logic programming arose out of a need to make programming more like that of writing specifications, to make it easier to construct mathematical proofs. It would be a good idea to look into that as well. I can recommend "L. C. Paulson: ML for the working programmer" as a good introduction to functional programming. There are also a number of good books on Haskell, please pick one. When it comes to logic programming, things are unfortunately a bit more messy. The main logic programming language, "Prolog", is all but logical. Also, most research these days seems to focus on constraint programming, which is a generalization of logic programming. For a good online introduction, check out Oz Mozart.

The foundations of mathematics (logic, set-theory, category-theory, etc) are all important in computer science. And of course also more mundane subjects such as combinatorics, calculus, etc...

Logic relates to programming, as mathematics do to engineering. While formal methods have not had much practical value so far, it's an important part of computer science, and undoubtedly something that should become important sometime in the future, once we find a practical way to do it. The best place to get the basic ideas are still "Edsger Dijkstra: A discipline of programming". It's more than likely that you local CS department offers some courses.

Since your view is from philosophy, I guess you are more interested in the important insights of computer science, rather than the boring details. In that case, I can also recommend: "Papadimitrou: Computational Complexity" which covers more or less the same stuff as Harel's book, but in a bit more in depth. It would be good to have read a basic book on algorithms first (basically any will do, but I can recommend the books by Sedgewick, or Cormen, Leiserson & Rivest). By this time, you should be able to find your own references in computational complexity and algorithm analysis.

Could you (or the community) provide examples of areas of applicability where
1) Object oriented languages are clearly better than functional?
2) the opposite of 1)
?
On my opinion, transport problem or problem of getting the optimal equipment for character in MUD problem is clearly the example of
(2), while accounting for a large factory is probably the example of (1).
An example of language that contains a good mix of functional and object-oriented paradigms is Oz but cumbersome and strange syntax of that language is a real problem at least for me to start using it...

I'm one of the authors and of course I'm enthusiastic about the book, so don't take my word for it. My coauthor and I have been working on it for two years and we've taught courses from it. It distills ten years experience building the Mozart system.

Peter

I'm one of the authors, so don't take my word for it. We've been working on it for two years and we've taught from it. It distills ten years experience building the Mozart system.

For problems like that, I tend to work with languages that have good support for multiple programming paradigms, or, to use fewer buzzwords, languages that let me easily abstract the problem in various ways. Some ways of abstraction will map more easily onto certain parts of large problems - logic programming, functional programming, OOP, straight old procedural thought, or concurrent programming might be the best fit for a section of a problem.

Trying to stick a large, multifaceted problem into (for example) the OOP mode of thought is an exercise in pain.

Languages such as those in the Lisp family (Common Lisp, Scheme, Dylan..) or my current project, Oz, all easily support various means of abstraction.

The phrase 'easily support' is important though. It's *possible* to do functional programming in Java, but I sure as hell don't want to.

The most complete realization of the goals of the MS white paper, currently in existence, is Mozart.

If he would invent something really new I would not argue. What he offers is another facelift to C++ which was extention of C. He offers it in a way very similar to Java.

For fresh approach to OO languages take a look at
OZ. I wish I had more time to play with it. Looks quite interesting.

I really get disappointed when people invent pet language for their project when there are thousands of other lanugages which you could use. For my projects I am using
GUILE.

When I first saw the story, I thought of another (and IMO more innovative) programming language/system called Mozart. Would it really hurt to at least check Google for "Mozart programming language" before you name your new project? Not that the original is very original either... If you decide to change the project name, may I suggest not to use Beethoven?

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.

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.

• OCaml is multithreaded (linuxthreads was born as a way to get it to work on linux), although a single program won't take advantage of a multiprocessor. Core dump is impossible using its static strong typing, and the optimizing native-code compiler provides with great performance.
• JOCaml is an extension of OCaml based on the Join-Calculus, the latest and greatest paradigm for distributed programming (can be seen as actor-based programming done right, as based on a well-understood algebra). Can take advantage not only of multiprocessors, but of processor farms, or any distributed architecture, even heterogeneous architectures. Only bytecode can migrate, native code modules and primitives must be compiled into the servers.
• Erlang is based on a paradigm quite similar to jocaml, but is designed for industrial applicability rather than hacker coolness; it has dynamic typing, a pure functional core (despite the logic programming syntax, it only has matching, not unification), enriched with explicit asynchronous communication primitives, and an implementation that every phone call you make depends on, if you use British Telecom. If you need tens of thousands of threads and/or lots of nodes, this is what you need.
• There is also Mozart, an distributed implementation of Oz, a real logic programming language (has unification).
• Haskell and Mercury also have extensions for concurrent and distributed programming in the works, but I admit I don't know how usable they are for real programming.

-- Faré @ TUNES.org

Then you haven't seen Mozart

Java code 168 lines
Mozart code 30 lines

There are some theoretically sound alternatives to Java on the Server side that have more profound advantages to languages like Perl than Java offers. IMHO, the leading one here(introduced to me by a friend of mine who is a network architect): Mozart-OZ. Mozart has solves dome of the basic issues of object oriented programing that annoy Smalltalk programmers that are forced by the market to move to Java. At the same time, Mozart goes far beyond the networking capability of Java. The Mozart VM is more integrated with a network later, making it possible to write distributed applications where the network is rather transparent--this solves a lot of problems like session management problems that plague Java and Perl hackers. They have some benchmarks that show Mozart kicking Java's ass. On top of this, the Mozart folks have done a rather nice job with integrating multiple programing paradigms: they nicely handle functional programming, logic programing, constraint programming in one nice neat package. The only real hole here:Integration with databases/relational programming isn't handled as seemlessly here. Take a look at it. I think that my friend was correct when we said if this isn't the future, it is going to be something much like it or better. RJB

DESCRIPTION

The Mozart threading model uses logic variables to create synchronization between threads. This can be viewed as automatic construction of dataflow dependency graphs, or as what logic programming calls "AND-parallelism". Either way, synchronization falls out of functional or relational dependency inherent in the semantics of the program rather than being an additional thing for the application programmer have to write and therefore possibly write wrong. Constraints may be added to logic variables consistent with prior constraints but they may not be deconstrained once successfully constrained.

Comparing Java to Mozart, a simple consumer-producer multithreaded application running within:

The same processor:
Java execution time 17.6 seconds
Mozart execution time 3.9 seconds
Java code 108 lines
Mozart code 28 lines

Distributed processors:
Java execution time 1 hour
Mozart execution time 8.0 seconds
Java code 220 lines
Mozart code 32 lines

(See ref 1.)

IMPLEMENTATION

Mozart's threading model has been implemented for other languages (see ref 2). Central to this model is Mozart's "computation space" construct. Computation spaces are heirarchical collections of threads and logic variables. Each thread and each logic variable belongs to exactly one computation space. When a logic variable is introduced that is "local" to a thread, it spawns a new computation space. "local" as used herein has the same scoping as the Perl "local" keyword: upward visibilty and downward invisibility. When a thread attempts to add a binding (constraint) on a logic variable that is inconsistent with prior bindings, the thread fails thus raising the associated exception. (See ref 3)

For simplicity of initial implementation, constraints could be limited to simple single-assignment dataflow variables and later expanded to numeric relations like >, &lt and != and might someday become as sophisticated as performing regular expression algebra to determine consistentcy of adding regular expression constraints to variables.

REFERENCES
(1) "An Example of Programming in Mozart versus Java" by Per Brand (http://www.sics.se/~perbrand/javaVSMozart/)
(2) "Efficient Logic Variables for Distributed Computing" by Haridi, Van Roy, Brand, Mehl, Scheidhauer and Smolka http://www.mozart-oz.org/papers/abstracts/TOPLAS99 .html
(3) "Computation Spaces" from the Mozart documentation http://www.mozart-oz.org/documentation/tutorial/no de12.html#label65

DESCRIPTION

The Mozart threading model uses logic variables to create synchronization between threads. This can be viewed as automatic construction of dataflow dependency graphs, or as what logic programming calls "AND-parallelism". Either way, synchronization falls out of functional or relational dependency inherent in the semantics of the program rather than being an additional thing for the application programmer have to write and therefore possibly write wrong. Constraints may be added to logic variables consistent with prior constraints but they may not be deconstrained once successfully constrained.

Comparing Java to Mozart, a simple consumer-producer multithreaded application running within:

The same processor:
Java execution time 17.6 seconds
Mozart execution time 3.9 seconds
Java code 108 lines
Mozart code 28 lines

Distributed processors:
Java execution time 1 hour
Mozart execution time 8.0 seconds
Java code 220 lines
Mozart code 32 lines

(See ref 1.)

IMPLEMENTATION

Mozart's threading model has been implemented for other languages (see ref 2). Central to this model is Mozart's "computation space" construct. Computation spaces are heirarchical collections of threads and logic variables. Each thread and each logic variable belongs to exactly one computation space. When a logic variable is introduced that is "local" to a thread, it spawns a new computation space. "local" as used herein has the same scoping as the Perl "local" keyword: upward visibilty and downward invisibility. When a thread attempts to add a binding (constraint) on a logic variable that is inconsistent with prior bindings, the thread fails thus raising the associated exception. (See ref 3)

For simplicity of initial implementation, constraints could be limited to simple single-assignment dataflow variables and later expanded to numeric relations like >, &lt and != and might someday become as sophisticated as performing regular expression algebra to determine consistentcy of adding regular expression constraints to variables.

REFERENCES
(1) "An Example of Programming in Mozart versus Java" by Per Brand (http://www.sics.se/~perbrand/javaVSMozart/)
(2) "Efficient Logic Variables for Distributed Computing" by Haridi, Van Roy, Brand, Mehl, Scheidhauer and Smolka http://www.mozart-oz.org/papers/abstracts/TOPLAS99 .html
(3) "Computation Spaces" from the Mozart documentation http://www.mozart-oz.org/documentation/tutorial/no de12.html#label65

and

There's another threading model, ithreads, which is more like a fork inside the process. That could be inefficient, but I think if we do what we're thinking of doing with copy-on-write semantics then it will not be as inefficient as all that to clone a new thread, and I think in some ways it's more safer to assume that all your global variables are not shared and make you specifically declare all the things that you want shared and how you want them shared. So that's my leaning.

If by "logic programming" Wall means he will include logic variables, then he can dramatically simplify the thread model while also enabling cleaner distributed applications by implementing logic variables the way the Mozart guys do.

IMNSHO, there really needs to be some serious outreach from the Perl6 team to the Mozart team.

and

There's another threading model, ithreads, which is more like a fork inside the process. That could be inefficient, but I think if we do what we're thinking of doing with copy-on-write semantics then it will not be as inefficient as all that to clone a new thread, and I think in some ways it's more safer to assume that all your global variables are not shared and make you specifically declare all the things that you want shared and how you want them shared. So that's my leaning.

If by "logic programming" Wall means he will include logic variables, then he can dramatically simplify the thread model while also enabling cleaner distributed applications by implementing logic variables the way the Mozart guys do.

IMNSHO, there really needs to be some serious outreach from the Perl6 team to the Mozart team.

Ultra light weight threads are one of the major advantages of the MVM, but another advantage is how well thought out and integrated with the other language features is it's thread synchronization scheme.

Many of the important theoretic issues have been addressed at the nuts-and-bolts level by the Mozart Programming System. Specifically, if you read Distributed Programming in Mozart - A Tutorial Introduction you'll have an idea of the kind of distributed programming power provided by a network of Mozart systems.

The key to Mozart's power is its use of ultra-light-weight threads that can share single-assignment distributed variables within heirarchical computation spaces. What this means is you can have unlimited "processes" that are waiting on all sorts of things all over the network -- and failures are easily confined to the minimum logical spaces.

By "ultra-light-weight threads" I mean a virtual unification of process structure with data structure.