User Tools

Site Tools


at:introduction

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
at:introduction [2007/04/07 11:21]
tvcutsem added
at:introduction [2008/07/15 12:19]
tvcutsem *
Line 1: Line 1:
-===== What is AmbientTalk? ===== 
  
-{{:at:atlogo.jpg?80  |:at:atlogo.jpg}} AmbientTalk is a //distributed programming language// developed specifically for writing programs to be deployed on [[:research:terms:monets|mobile ad hoc networks]]. A distributed programming language is often characterised as a programming language with built-in support for aiding the programmer in dealing with the difficulties engendered by distribution. If you wonder what those difficulties would be, a good starting point are the well-known [[Wp>Fallacies_of_Distributed_Computing|fallacies of distributed computing]]. 
- 
-For the programming language adepts: AmbientTalk is: 
-  * **dynamically typed**, which is **not** the same as being untyped: AmbientTalk //values// are typed, but //variables// are not 
-  * object-oriented, but prototype-based: AmbientTalk provides full support for objects, **delegation** (a form of inheritance) and polymorphic message dispatch. Objects are not instantiated from classes, as in Smalltalk, but rather cloned from existing objects or created //ex-nihilo//, as in Self. 
-  * event-driven: AmbientTalk has built-in support for **actor**-based concurrency, which operates based on entirely //asynchronous// and //event-driven// communication. No threads, no locks, no deadlock and no data-level race conditions! 
-  * distributed: AmbientTalk has built-in natives to make objects discover and talk to one another in a **peer-to-peer** manner across a TCP/IP network. 
-  * **symbiotic**: built on top of the Java Virtual Machine, AmbientTalk exploits the Java reflection API to enable AmbientTalk objects to collaborate with Java objects. This enables reuse of existing Java libraries while not abandoning the dynamic programming style of AmbientTalk. 
- 
-A word of warning, though: AmbientTalk is **not** a stable development platform. Rather, it is a research artifact used as a "programming language laboratory" to experiment with and discover new language abstractions for distributed computing in mobile ad hoc networks. 
- 
-==== AmbientTalk in a nutshell ==== 
- 
-Enough talking, let's delve into some AmbientTalk code by means of a simple example to see whether we can spark your interest in AmbientTalk. The demo program we're about to explore is an extremely simple instant messenger program. Each instant messenger runs on e.g. a PDA, laptop or cell phone. When peers join the ad hoc network, the instant messenger should issue a warning to the user that a new buddy is available for chatting. The user can then send simple text messages to that buddy. When peers leave the ad hoc network, the user should also be notified. Off we go. 
- 
-=== Design === 
- 
-Here is the skeleton code for the instant messenger: 
- 
-<code> 
-def createInstantMessenger(username) { 
-  defstripe InstantMessenger; 
- 
-  def TextMessage := isolate: { ... }; 
-  def buddyList := jlobby.java.util.HashMap.new(); 
-  def printMessage(textMessage) { ... }; 
- 
-  def localInterface := object: { 
- def sendTextMessage(to, string) { ... }; 
-  }; 
-  def remoteInterface := object: { 
-    def receiveTextMessage(textMessage, future) { ... }; 
-    def getName(future) { ... }; 
-  }; 
-   
-  export: remoteInterface as: InstantMessenger; 
-  whenever: InstantMessenger discovered: { |messenger| 
-    ... 
-  }; 
-  localInterface; 
-}; 
-</code> 
- 
-An instant messenger object is created by invoking a function called ''createInstantMessenger''. A ''username'' should be passed to identify the user. Within the lexical scope of that function, we define a //stripe// named ''InstantMessenger'' which will be used to identify remote objects in the network as peer instant messengers. Stripes are simply symbolic marks that can be attached to objects to classify them. They replace the role of classes in class-based OO languages to classify objects. The advantage over classes is that an object can be classified under multiple stripes (unlike classes, stripes do not say anything about the implementation of an object). 
- 
-=== Implementation === 
- 
-<code> 
-def createInstantMessenger(username) { 
- 
-  defstripe InstantMessenger; 
- 
-  def TextMessage := isolate: { 
-   def from := nil; 
-   def content := nil; 
-   def init(f,c) { 
-   from := f; 
-   content := c; 
-   }; 
-  }; 
- 
-  def buddyList := jlobby.java.util.HashMap.new(); 
-   
-  def printMessage(textMessage) { 
-    system.println(textMessage.from + ": " +  
-      textMessage.content) 
-  }; 
- 
-  def localInterface := object: { 
-   def sendTextMessage(to, string) { 
-   def buddy := buddyList.get(to); 
-   if: (nil == buddy) then: { 
-   system.println("Unknown buddy: " + to); 
-   } else: { 
-   def msg := TextMessage.new(username, string); 
-   buddy<-receiveTextMessage(msg, object: { 
-   def resolve() { 
-   printMessage(msg); 
-   } 
-   }); 
-   }; 
-    }; 
-  }; 
- 
-  def remoteInterface := object: { 
-    def receiveTextMessage(textMessage, future) { 
-      printMessage(textMessage); 
-      future<-resolve(); 
-    }; 
-    def getName(future) { future<-resolve(username) }; 
-  }; 
-   
-  export: remoteInterface as: InstantMessenger; 
-   
-  whenever: InstantMessenger discovered: { |messenger| 
-   messenger<-getName(object: { 
-   def resolve(name) { 
-   if: (nil == buddyList.get(name)) then: { 
-   buddyList.put(name, messenger); 
-   system.println("Added buddy: " + name); 
-   when: messenger disconnected: { 
-   system.println("Buddy offline: " + name); 
-   }; 
-   when: messenger reconnected: { 
-   system.println("Buddy online: " + name); 
-   }; 
-   }; 
-   }; 
-   }); 
-  }; 
-  
-  localInterface; 
-}; 
-</code> 
at/introduction.txt ยท Last modified: 2008/07/15 12:19 by tvcutsem