Home » forums » LtU Forum

Disruptive PLT, 4 years later

in 2002, Todd Proebsting delivered a talk about "disruptive programming language technologies" (video) He suggested that certain ideas, when integrated into programming languages, would make those languages slower, but much more useful, and would lead to the eventual displacement of older and faster languages. The technologies he listed were:

  • Parsing (not regexes)
  • Undo
  • Tracking program state
  • Constraint solving
  • Concurrency
  • Database operations
  • XML manipulation

How has the landscape evolved since then? It seems to me that really large or really flexible programming languages could integrate these things in libraries. There are certainly parsing libraries in C++ and Haskell, for instance, and Haskell hackers have spent a lot of time trying to integrate XML and database operations into the language.

Other languages are designed exactly for these things that Proebsting mentions: XML manipulation is prominent in CDuce, XDuce, and Scala, and in the LL2 video Proebsting proposes Erlang as a solution to the concurrency problem.

Questions:

  1. The Next Big Thing might end up being Ruby on Rails. Does it fit with Proebsting's thesis?
  2. What other languages are filling the gaps suggesting by Proebsting? Will any become the next big thing?
  3. What other disruptive technologies have you seen in programming languages since 2002?
By Jim Apple at 2006-04-02 22:24 | LtU Forum | previous forum topic | next forum topic | other blogs | 9196 reads

Comment viewing options

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

Cω and friends

In the Microsoft camp, C#3 has LINQ, which provides some data-query operations and limited XML manipulation. VB9 will also include LINQ, so it rides along as well.

LINQ was informed by Cω, which included concurrency, database operations, and XML manipulations (as it subsumed PolyphonicC and Xen). There's a rumor afoot that C#4 will continue to absorb Cω and provide Join functionality to support concurrency.

Spec# and its descendant Sing# are intended to bring constraint-solving behaviour to the CLR platform, which isn't exactly designed for it. I think they do a good job. More rumors hint that C#4 might also include some of what's being learned in the development of Spec#.

As long as I'm on the subject of the CLR, I'd say that language-neutral runtimes (like the CLR, Parrot, to a certain extent the JVM, and the various and sundry others mentioned on these pages) have risen to significant prominance since 2002, and collectively represent their own type of disruptive technology.

I'll withhold my opinion about Ruby on Rails, except to say that it's a very nice program generator.

By Wolf Logan at Mon, 2006-04-03 07:59 | login or register to post comments

Haskell as a disruptive technology

There is a thread on the Haskell mailing-list on a very close subject: Haskell as a disruptive technology. There is no clear consensus on which applications would allow Haskell to thrive outside of academic circles.

By Sylvain Schmitz at Mon, 2006-04-03 12:41 | login or register to post comments

Oz as a disruptive technology and some reflections on the future

There is a discussion of this in the foreword and preface of the MOZ 2004 proceedings (Springer LNCS 3389). In his foreword, Peter Norvig mentions concurrency, constraints, and distribution, which are particular strengths of Mozart/Oz. He also talks about separation of concerns, automation, security, and performance. In the preface, I remark that two important themes of MOZ 2004 are security and concurrency. Both topics are intimately tied together. The E and Erlang designers also realized the importance of concurrency.

Making distributed programming easy is an important direction for disruptive technology. Being able to build Web applications easily is an example of this, but it goes much further. The first step toward making distributed programming easy is network transparency (see chapter 11 of CTM). But this is only practical for small numbers of nodes. The next step is one that we are taking now in the SELFMAN project, a new European project that will be starting in a few months. SELFMAN is about building large-scale distributed systems that are self-managing. (Note that automation is an example of self management.) We are using two starting points for this: structured overlay networks (which originated in peer-to-peer systems) and component models (allowing applications to configure and maintain themselves). In the SELFMAN vision, the combination of these two will enable self management.

To conclude, I would like to mention that Mozart/Oz was used by the European aerospace industry in a recent project because it combined two abilities: constraint programming and distributed programming. This is an example of a niche that was filled nicely by Mozart/Oz and by no other technology.

By Peter Van Roy at Mon, 2006-04-03 13:53 | login or register to post comments

release early, release often?

For a while now I have been looking at Mozart/Oz. I find the syntax a little unfamiliar but I appreciate the functionality of the language more and more as I learn about concurrency, constraints, etc. One thing I would like to suggest is that the Oz team interact more with its users. I know that is a strange thing to say since PVR himself responds to many queries on LtU as well as the Oz's mailing list. What I mean is the following: release updates to the language more often, update website more often (the website still informs users of a conference held two years ago), provide a more clear roadmap.

I realize that Oz is, foremost, a vehicle for research, but people who are used to other open source projects get the impression that the project is not moving.

By shahbaz at Mon, 2006-04-03 15:28 | login or register to post comments

Mozart releases, mailing lists, and roadmap

One thing I would like to suggest is that the Oz team interact more with its users

But there is a lot of activity on the Mozart users and Mozart hackers mailing lists! Just take a look at the Mozart mailing list archives. If you post a message you will get a prompt reply from a Mozart developer.

people who are used to other open source projects get the impression that the project is not moving

Yes, that perception is one of our perennial problems. We try to make one or two releases per year. Boris Mejias is preparing a release that should happen in a month or two. Later this year we plan to make a second release that incorporates the new Distribution Subsystem (work of Erik Klintskog, Raphael Collet, and Boris Mejias). More releases will be done in the SELFMAN project, of course, as we understand how to do self management. There is also the AVISPA group in Colombia, which is well on its way to becoming full-fledged Mozart developers.

update website more often

This is a manpower problem. We are looking for people to help us with this kind of thing. For example, Dominic Fox has set up a CTM Wiki and Chris Rathman is translating much useful code to and from Oz. If you want to volunteer to help us, please do so! The procedure for assigning responsibility is simple: submit a MEP (Mozart Enhancement Proposal) on the hackers list.

provide a more clear roadmap

There are three main directions that Mozart/Oz is moving in. First, the SELFMAN project (EU 6th Framework Programme) will extend Mozart/Oz with self management abilities. Second, the GeOz project (AVISPA group) will integrate the Gecode constraint solver into Mozart/Oz and generally work on enhancing Mozart's constraint solving abilities. Third, we are continuing our work on using Mozart/Oz for computer science education.

By Peter Van Roy at Mon, 2006-04-03 15:50 | login or register to post comments

Can't think of new languages that fill these needs

but I can think of some ones that predate his talk. Erlang for concurrency, obviously, but I really want to point out the parsing dialect built into REBOL. Really nice stuff.

Oh, I guess regexes and parsing are converging in Perl 6, at least that's how it appears to me.

By James Hague at Mon, 2006-04-03 15:52 | login or register to post comments

Original LtU discussion

Todd Proebsting's ideas were discussed here before.

By Ehud Lamm at Mon, 2006-04-03 20:11 | login or register to post comments