Ambient Oriented Programming (AmOP)

Ambient-Oriented Programming by Jessie Dedecker, Tom Van Cutsem, Stijn Mostinckx, Theo D'Hondt, and Wolfgang De Meuter. (2005). 9 pages.

A new ï¬eld in distributed computing, called Ambient Intelligence, has emerged as a consequence of the increasing availability of wireless devices and the mobile networks they induce. Developing software for such mobile networks is extremely hard in conventional programming languages because the network is dynamically deï¬ned. This hardware phenomenon leads us to postulate a suite of characteristics of future Ambient-Oriented Programming languages. A simple reï¬‚ective programming language kernel, called AmbientTalk, that meets these characteristics is subsequently presented. The power of the reï¬‚ective kernel is illustrated by using it to conceive a collection of high level tentative ambient-oriented programming language features.

This document focuses on requirements analysis for the language design, justification for certain design decisions, and a preliminary implementation (the Ambient Talk kernel). I don't agree with all the assumptions (especially not: "Our most basic research assumption is that ambient-oriented programming languages necessarily are concurrent distributed object-oriented programming languages." Content-centric networking is also very feasible). I feel security was ignored to the design's detriment. But there are some interesting ideas - e.g. reifying communication traces to help with error recovery.

More papers are available at the AmbientTalk site, including a full thesis. AmbientTalk is a language designed to support this field of ambient-oriented programming.

syntax

This may seem a trivial complaint, but why on earth does this language have semicolons? It uses curly braces to delimit blocks (closures), which is great, but then it requires semicolons after them, so that even a simple method (quoting from http://soft.vub.ac.be/amop/at/introduction) is likely to include something like
}; }; }; }); };

instead of ]]])], like in Smalltalk, or something similarly simple in Lisp.

By Jason Grossman at Wed, 2011-03-09 11:49 | login or register to post comments

AmbientTalk doesn't require

AmbientTalk doesn't require semicolons after its closures any more than Smalltalk requires dots after its blocks. Semicolons, like dots in ST, are used to terminate statements. Additionally, in AmbientTalk, a semicolon after the last statement in a statement list is optional, so in the example you are referring to, removing all the trailing semicolons would be legal.

That said, hopefully there are more interesting aspects of AmbientTalk to discuss than its syntax, such as its concurrency model and support for distributed programming! ;-)

By Tom Van Cutsem at Fri, 2011-03-11 10:12 | login or register to post comments

Aha. Thanks.

Aha. Thanks. So the semicolons are statement separators rather than statement terminators, right? I believe that's just the same as Smalltalk then.

Personally, I find syntax fascinating, but I agree that there are many other fascinating aspects to AmbientTalk. I hope I didn't sound negative.

By Jason Grossman at Tue, 2011-06-28 09:35 | login or register to post comments

Metaphor-Oriented Programming

Also, while we're talking about Ambient Oriented Programming, what about Metaphor-Oriented Programming? See the brilliant Homespring language by Jeff Binder and Joe Neeman: http://xeny.net/H_Ot_M_Ef_S_P_R_Ib_N_G

By Jason Grossman at Thu, 2011-03-10 09:10 | login or register to post comments

Horrible

Homespring (aka Hatchery Oblivion through Marshy Energy from Snowmelt Powers Rapids Insulated but Not Great) "allows you to avoid worrying about program style and focus on what programming is really about, the reproductive behaviour of salmon."

I'm not seeing a relationship to Ambient Oriented Programming, here.

By dmbarbour at Thu, 2011-03-10 16:56 | login or register to post comments

I thought that post was

I thought that this comment was generated by an intelligent SPAM generator. Maybe its passing the Turing test now?

By Sean McDirmid at Thu, 2011-03-10 18:13 | login or register to post comments

Are you calling me an

Are you calling me an intelligent SPAM generator? How rude. ;)

I don't think Homespring can afford the intelligent SPAM generators, and it certainly won't earn genuine endorsement.

By dmbarbour at Thu, 2011-03-10 18:49 | login or register to post comments

I was calling the post that

I was calling the post that parented your reply SPAM, according to my first-read filter. Actually, reading it again, I think you are correct, its not SPAM, just that the thoughts are enthusiastic but not very well organized yet. The parent poster could work on organizing and polishing their thoughts, it would be easier for us to understand what is going on and provide appropriate feedback.

By Sean McDirmid at Fri, 2011-03-11 03:00 | login or register to post comments

joke

Homespring is a joke language. I think it's rather funny.

By Jason Grossman at Fri, 2011-03-11 05:20 | login or register to post comments

I didn't get it. I apologize

I didn't get it. I apologize for jumping to conclusions.

By Sean McDirmid at Fri, 2011-03-11 09:05 | login or register to post comments

Classless objects in E?

When reading the paper about Ambient oriented programming http://soft.vub.ac.be/Publications/2006/vub-prog-tr-06-11.pdf the last line in chapter 3.1 says that E has classless objects.

Is this true, and if so, what does it mean?

By Mats at Wed, 2011-08-31 06:58 | login or register to post comments

Classless objects

It means that objects are not typed by constructor, nor can you discriminate on class by query or reflection. Instead, you only have a sort of duck-typing by the set of visible methods.

By dmbarbour at Wed, 2011-08-31 14:33 | login or register to post comments

All those mailboxes in AmbientTalk

When reading about the AmbientTalk kernel I notice that it has a number of mailboxes per object that can communicate remotely. One set of boxes is used to keep track of how communication fares and is intended to be used to recover from communication glitches. I'm not sure if I can find a better solution to this (yet), but it sounds hysterical having 8 boxes for this...

Another set of boxes handles service discovery. It can present a service for others to see and it can request service for others to reply to. This uses some kind of multicast technique. My question here is: Why not having a built-in object that act as a service broker? Then you would communicate with the object to request a service or publish a service and the broker will tell you when a service is lost or a request service has been found. Using service broker, the interpreter no longer needs to handle concurrency issues when updating those mailboxes that it shares with the object. Would this solve the same problem, or have I missed something?

By Mats at Wed, 2011-08-31 08:09 | login or register to post comments

Service Brokering

I think the intent in AmbientTalk is to have a relatively pure paradigm where service discovery is used as the exclusive mechanism for hooking objects together even within the application.

While it is possible to separate the brokering responsibility into another object, that would mean you need another model for hooking an object to its broker. This isn't a bad thing, but wouldn't meet the goals of the authors.

By dmbarbour at Wed, 2011-08-31 14:53 | login or register to post comments

Service Brokering

I see. While it might not meet the goals of the authors, I do think it would give a cleaner language. But that is of course only my personal opinion. Part of the reason for this opinion is that I've got so much bad experience with having several mail boxes. It is error prone. If you've got one place where messages arrive, and one place where you sort out all messages that are of interest, you do not risk stock piling messages.

By Mats at Wed, 2011-08-31 18:48 | login or register to post comments

Lambda the Ultimate

User login

Navigation