Lambda the Ultimate

It seems that Oslo is going to get a lot of press soon, and I don't think we have discussed it yet, nor am I sure I really understand what it's all about...

We have been following Microsoft's DSL and modeling project on and off for a couple of years, and Oslo seems to be another step on this road. The buzz seems to be about visual development, a textual DSL, and development by non-developers (which is probably not the same as end-user programming).

eWeek has a short discussion of The Origins of Microsoft's Oslo Software Modeling Platform. If you have links to more informative resources, or insights to share, please do.

Tim Bray reports about half of the JVM language summit. Among the things he discusses are Clojure, PHP and JVM/CLR cross-pollination.

Probably worth noting MISRA-C++. Not much to go on since you have to pay for the document that outlines the standards.

MISRA C++:2008 was finally released on June 5, 2008, following 3 years of work by a group of willing volunteers. They set out to craft a set of rules for the safe use of C++ in critical systems...

It seems not so long ago that the insurrection to fork a safer subset of C++ in Europe was suppressed. Instead of redefining the language, the efforts are now on trying to enforce coding standards and best practices. Try to solve things on the engineering side, rather than the programming language specification side.

Intel is working on a C++ extension called Ct to simplify multicore programming and data parallelism more properly than they did with previous library efforts like TBB.

One of the main challenges in scaling multi-core for the future is that of migrating programming tools, build environments, and millions of lines of existing code to new parallel programming models or compilers. To help this transition, Intel researchers are developing “Ct,” or C/C++ for Throughput Computing.

Ct is not intended to be a C++ dialect or replacement but rather a tricky integration of a runtime engine with existing C++ compiler environments.

In principal, Ct works with any standard C++ compiler because it is a standards-compliant C++ library (with a lot of runtime behind the scenes). When one initializes the Ct library, one loads a runtime that includes the compiler, threading runtime, memory manager — essentially all the components one needs for threaded and/or vectorized code generation.

A Simon Peyton Jones interview as part of the series The A-Z of Programming Languages that Naomi Hamilton has been putting together. Posting this one to the front page, not because of any bias towards functional programming, so much as it stands on its own as interesting and insightful from the standpoint of programming language design and evolution.

To supplant established languages, even in the functional programming area, like Haskell or ML or Scheme, you have to build a language that’s not only intriguing and interesting, and enables people to write programs faster, but you also need an implementation that can handle full scale applications and has lots of libraries and can handle profilers and debuggers and graphical analyzers… there’s a whole eco-system that goes with a programming language, and it’s jolly hard work building that up.

Anand S. Rao (1996). AgentSpeak(L): BDI Agents speak out in a logical computable language.

Rao's AgentSpeak(L) is a Prolog-like resolution-based language, but which is extended to support agent-based programming in several ways, most importantly:

1. It extends the language, so that clauses can talk about not just satisfaction of predicates, but also of an agent desiring to bring about a predicate, and desiring to find out whether a predicate is true; and to distinguish between normal goals and special goals relevant to the BDI model (Belief-Desire-Intention model);
2. It amends the resolution engine to support what Rao calls reactive concurrency, where agents form plans via a process resembling SLD-resolution, but plans are formed or abandoned on the basis of agent-internal reactions called triggering events.

Rao and Georgeff's work on BDI agents and procedural reasoning together constitutes one of the most important contributions to the theory of agents in AI, a topic which hasn't been discussed much here on LtU, but was raised in the Agent Oriented Programming story.

SourceIDE: A Semi-live Cross-development IDE for Cola Scott Wallace, Viewpoints Research Institute, 2008

This paper describes the first phase of a long-term effort that will culminate in the availability of native, incremental, “live,” interactive development environments for the “Cola” family of languages.

Here's a peek at bootstrapping a new programming environment. The author has written an IDE for the new Cola programming language by adapting Squeak's IDE to operate on external source files written in a language other than Smalltalk. This was done as temporary scaffolding to help develop (amongst other things) a successor IDE written in the target language itself. Oj what a lot of disposable code to write for bootstrap!

This is a part of Alan Kay and Viewpoints Research's Inventing Fundamental New Computing Technologies project. I've just started hacking on this project myself and I'm really excited so expect more about it in the coming weeks!

We are experiencing a surge of new members, and that's great! We always value new members.

Let me remind everyone to pursue the policies document (available through the FAQ page). I want to emphasize two policy items in particular: We discourage nicknames, and when they are used encourage members to provide a url of a home page or related information in their profile. Second, LtU is in general not intended for detailed design discussions. More relevant forums are listed in the policies document.

Proving that particular methods within a code base are functionally pure - deterministic and side-effect free - would aid verification of security properties including function invertibility, reproducibility of computation, and safety of untrusted code execution. Until now it has not been possible to automatically prove a method is functionally pure within a high-level imperative language in wide use such as Java. We discuss a technique to prove that methods are functionally pure by writing programs in a subset of Java called Joe-E; a static verifier ensures that programs fall within the subset. In Joe-E, pure methods can be trivially recognized from their method signature.

The paper includes a nice discussion of security benefits that can stem from being able to identify pure functions (of course, it is not obvious that guarantees at the programming language level are maintained at the run time level). I am sure many here have opinions about whether it makes more sense to try to graft purity on an imperative language, exposing it as an added feature, or to move programmers to functional languages..

Courtesy of my shiny new commute, I have been listing to various podcasts, including Software Engineering Radio. A while back, they had an interview with Dan Grossman on his OOPSLA 2007 paper, which I have not seen discussed here.

The Transactional Memory / Garbage Collection Analogy is an essay comparing transactional memory with garbage collection based on the analogy:

Transactional memory (TM) is to shared-memory concurrency
as
garbage collection (GC) is to memory management.

Grossman presents the analogy as a word-for-word transliteration of a discussion of each of the technologies. (Hence the "fun" category.)

(As an aside, Grossman does not address message-passing, but says, "Assuming that shared memory is one model we will continue to use for the foreseeable future, it is worth improving," which is probably a correct assumption.)

One point that he does make is that

[This essay] will lead us to the balanced and obvious-once-you-say-it conclusion that transactions make it easy to define critical sections (which is a huge help in writing and maintaining shared-memory programs) but provide no help in identifying where a critical section should begin or end (which remains an enormous challenge).

The one serious weakness of the analogy, to me, is that GC does not require (much) programmer input to work, while TM does.

Although some parts of the analogy are strained, there are some interesting correspondences.