Home » forums » LtU Forum

Network Transparent languages

Are there any network transparent languages apart from Mozart(Oz) and Google's Sawzall(to some extent).I have tried searching on this subject, but nothing significant turned up.I have not even found any references to such languages in any of the programming language (text) books.

I would be glad if anyone can answer the following questions:
- Are they different from languages which support distributed programming?
- Why are they not popular, i feel that such a language has very interesting and practical applications.( like run-time load balancing of applications etc..)
- Are there any theoritical/practical reasons why they will not be useful, even if one exists?

Any other pointers will also be helpful.

By mansu at 2005-11-27 19:34 | LtU Forum | previous forum topic | next forum topic | other blogs | 8522 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Network transparency is usually a bad idea

In practice, "network transparency" ends up meaning "the system attempts to hide the real problems of networks using a one-size-fits-all solution". Problems thus hidden include partial failure, bandwidth, latency, concurrency, security, and administration. If the network-transparent solutions to these problems turn out to be not quite what your application needs, there's usually nothing you can do about it.

"Distributed" languages, on the other hand, have programming models that explicitly takes all of those issues into account, and allows the developer at least some flexibility in how those problems are solved for their application.

By Dave Griffith at Sun, 2005-11-27 19:52 | login or register to post comments

Network transparency can work if done wisely

Network transparency can work if it is done wisely. That is, don't try to hide the network or partial failures, but try to *separate* the language semantics from the distributed behavior. Luca Cardelli, in his papers on Obliq, said it nicely: network transparency with network awareness. The choice of language is also very important: if your language is contaminated by state (has state everywhere, like Java), then network transparency will not work. This is because distributed systems are by nature concurrent, and concurrency and state do not mix well. I.e., it is extremely expensive to maintain global consistency of a stateful entity in a distributed environment. For network transparency to work well, your language should be stateless by default (i.e., state has to be declared explicitly).

We have been thinking about these issues since 1995, and chapter 11 of CTM gives some of our conclusions. The basic conclusion is that network transparency, if done right, greatly simplifies distributed programming without sacrificing control. Another conclusion that is not given in CTM (but maybe we will explain it in another book) is that you need to have appropriate language abstractions. For example, a replicated object store with a transactional interface is a good abstraction. It is transparent (since running in one process has the same language semantics as running in many) and it gives a good solution both for partial failure and for latency. (It's a little known insight that transactions are a good way to mask latency.) See the second talk on this page for more information.

By Peter Van Roy at Mon, 2005-11-28 10:30 | login or register to post comments

Concurrency and state

This is because distributed systems are by nature concurrent, and concurrency and state do not mix well. I.e., it is extremely expensive to maintain global consistency of a stateful entity in a distributed environment.

Here at my new group at CWI, I am getting exposed to a lot of work related to concurrency, and a lot of it is state-based, for example automata as models of process algebra programs. There are very good tools like model-checkers for specifying, building and testing stateful concurrent processes, and they are used successfully in industry on very large systems every day.

Actually, it is getting hard for me to think of concurrency without state: to be able to distinguish two processes with the same code, it seems to me you have to acknowledge that each has a different identity which at minimum includes the execution state. I get the impression that internal actions are probably a ubiquitous problem, but I really cannot agree with your remark above as stated.

I don't say this lightly; I think everybody here knows that I am a big fan of purely functional languages and controlled effects. But even a pure FP program has an execution state when it is running.

By Frank Atanassow at Tue, 2005-11-29 16:02 | login or register to post comments

Different senses of "state"?

I'm not sure that your "stateful concurrent process" is the same thing as Peter's "global consistency of a stateful entity". The latter seems to imply that you're trying to propagate the "same" state between different nodes, raising all the sorts of issues you see in distributed object systems and replicated databases; whereas the former merely implies that nodes have an execution state, which as you point out is a given.

By Anton van Straaten at Tue, 2005-11-29 16:29 | login or register to post comments

Global versus local state

It's global state that is the problem, not local state. Automata to model concurrent processes have local state. So I don't think we're contradicting each other.

By Peter Van Roy at Tue, 2005-11-29 16:49 | login or register to post comments

Correctness versus efficiency

There are very good tools like model-checkers for specifying, building and testing stateful concurrent processes, and they are used successfully in industry on very large systems every day.

My point was regarding efficiency, not correctness: maintaining global consistency is *expensive* in a distributed system. Network communications are orders of magnitude more expensive than local operations.

BTW, as far as I know, these "very good tools" do not miraculously make shared-state concurrency easy (a fortiori, they do not make fault-tolerant distributed programming easy). I think that good concurrent program design (e.g., use local state, use message passing, use high-level concurrency abstractions) remains just as important, even with the "very good tools".

By Peter Van Roy at Tue, 2005-11-29 16:59 | login or register to post comments

BTW, as far as I know, these

BTW, as far as I know, these "very good tools" do not miraculously make shared-state concurrency easy

You are quite correct. Although they do at least give you some tools to model shared-state concurrency and analyze it's behavior, if you were silly enough to want to implement shared-state. But the real power of using things like process algebras and model-checkers comes from building systems that use local, encapsulated state and message-passing. The systems are much easier to analyze, much easier to build, and much easier to maintain. Languages which support an easy mapping from process-algebraic abstractions to actual implementations (such as Erlang, occam, or Oz) make it far more likely that the implementation will be correct - there's a far smaller semantic gap between model and reality. Failing that, libraries which wrap shared-state concurrency primitives in an abstraction layer that is closer to the process-algebraic model (such as JCSP or CTJ for Java) can make life much easier.

By Allan McInnes at Tue, 2005-11-29 17:21 | login or register to post comments

Fallacies...

In the same vein of the previous post, here are some well known fallacies(which I suppose you may know, but its still useful to post...)

The 7 Fallacies of Distributed Computing.

And I guess, in the same vein, I thought "network transparency" was equivalent to "distributed computing"? Am I the only one who considers these to be the same?

It also strikes me that Erlang would fit the bill for many of your requirements as well.

By Matt Estes at Mon, 2005-11-28 03:29 | login or register to post comments

Not quite....

Distributed Computing centers on distributing load over multiple computers.

Network transparency implies the code runs the same, unchanged, no matter where it is, and/or where it's other (sub)?elements of it are running.

However, the fallacies still apply...

By John Carter at Wed, 2005-11-30 01:57 | login or register to post comments

Definitions

I'm not sure I agree with your definitions. To me, distributed computing means concurrent processes running on multiple computers and communicating through a network. "Distribute load over multiple computers" is just a particular application of distributed computing.

Network transparency means that you can ignore the fact that processes are not executing on the same computer for some operations (like sending messages) or that you can access some remote shared object like if it was local.

As for code that "runs the same, unchanged, no matter where it is", I'd call that location transparency.

By Guillaume at Tue, 2006-08-08 19:10 | login or register to post comments

ToonTalk

ToonTalk is network transparent or almost so. A long-distance bird behaves much like a local bird.

(Although ToonTalk as implemented has some tools that give shared state, I'd like to imagine a "pure" dialect that would exclude those. They can be confined to the edges of a system.)

And E programming language, I think it aims to be close to network transparent. Where another vat turns doesn't matter to this vat.

Erlang probably comes close.

By and large, these languages avoid communication via shared state.

The Actor model (Hewitt and Agha) is like that, too (and you can delete the "by and large" wrt the Actor model; it's purely free of shared state).

By Jack Waugh at Tue, 2006-08-08 18:03 | login or register to post comments