Adam Bosworth: Ajax reconsidered

This isn't really about programming languages, but I still think it is relevant to our discussions,

A lot of Ajax applications have a lot of script (often 10 or 20,000 lines) and without broadband, the download of this can be extremely painful. With broadband and standard tricks for compressing the script, it is a breeze. Even if you could download this much script in 1997, it ran too slowly. Javascript wasn't fast enough to respond in real time to user actions let alone to fetch some related data over HTTP. But Moore's law has come to its rescue and what was sluggish in 1997 is often lightning quick today.

We often tell people that execution speed is less important than code readability and flexibility, which depend on high level abstraction facilities found in HLLs. I guess we should consider bandwidth efficiency instead...

What I predict will drive this change is the advent of truly mobile computing on mobile devices. This is going to force the game to change. It is way too expensive to build solutions for mobile on J2ME and often too poor a customer experience when they are built using WAP (except for super simple things). I think that we're going to rethink browsing around a model which has pub/sub, events, and caching built in..

Languages for mobile code are going to be important for this next phase. I think there are still many interesting language design questions related to mobile code that people should start thinking about (cf. Links). I am sure a savvy language maven can become the next BDFL, or alternatively earn some big bucks, by helping attack this problem.

Variables as Channels

Method mixins - written by Erik Ernst

It is quite common to describe languages with mutable state as machine-oriented, and to describe functional, logical, and other kinds of `declarative' languages as more abstract, liberated from the old-fashioned attachment to bits and memory cells. This opinion was brought to prominence with the 1977 Turing Award
speech by John Backus [...] We must recognize that the functional and other paradigms have have produced deep and useful results. However, it is our opinion that imperative languages, especially object-oriented ones, are being widely used because of their
inherent power and not because programmers are nostalgic about
writing programs in assembly language. It is not a question of abstraction or hardware concreteness, it is about safety and freedom. Restrictive communication topologies bring safety, and flexible topologies bring freedom. To substantiate this, we need to consider variables and similar concepts as communication channels, thereby making them comparable.

This paper provides an interesting perspective on the role of variables in programming. It is about a construct called method mixins, but the discussion about the role of variables in Sec. 2 is relatively independent of the specific construct proposed in the paper:

A Core Calculus of Metaclasses

A Core Calculus of Metaclasses - written by Sam Tobin-Hochstadt and Eric Allen for Fool 12

Metaclasses provide a useful method of abstraction for programmers working with object-oriented languages, but they have not seen the formal exploration applied to more conventional object-oriented programming features. In order to elucidate the structure of metaclasses and their relationship with static typing, we present a core calculus for a nominally-typed object-oriented language with metaclasses and prove type soundness over this core.

Metaclasses are a nifty (albeit somewhat arcane) OOP feature. I found the article interesting, but I had a lot of trouble with the elaborate type soundness proofs. Those who are unfamiliar with metaclass programming might want to read some introductory material before tackling this article. Metaclass Programming in Python by Mertz and Simionato is a particularly good overview.

LtU needs you!

It seems that the LtU community has grown quite a bit recently, and the editorial team has to play catch-up.

If you are regular reader, and follow programming related news from other venues (e.g., online discussion groups, departmental seminar, read published paper for fun), how about joining the team and posting relevant items to the home page?

If you are interested, please get in touch with me via email.

2005 ICFP Programming Contest

Think your favorite programming language is the best one out
there? Put it to the test in this year's International Conference
on Functional Programming's annual Programming Contest. The
contest is coming up in a little under 4 weeks and we have just
released more information (including a live cd, mailing list, and
prize details) to the web page, at:



http://icfpc.plt-scheme.org/



This year's competition rewards programmers who can plan ahead. As
before, we'll announce a problem and give you three days to solve it.
Two weeks later, we'll announce a change to the problem specification
and give you one day to adapt your program to the new spec. And you
guessed it: the second half will be worth considerably more than the
first.


Important dates:

  • Problem announced: Friday, June 24th, 9:00am CDT (UTC-6)
  • Initial entries due: Monday, June 27th, 9:00am CDT (UTC-6)
  • Revision announced: Saturday, July 9th, 9:00am CDT (UTC-6)
  • Final entries due: Sunday, July 10th, 9:00am CDT (UTC-6)

ICFP Contest Organizers


icfpc@plt-scheme.org

The Essence of Data Access in Cw

The Essence of Data Access in Cw, The power is in the dot! Gavin Bierman, Erik Meijer, and Wolfram Schulte.

In this paper we concentrate on the data dimension. Our aim is to describe the essence of these extentions; by which we mean we identify, exemplify and formalize their essential features. Our tool is a small core language FCw, which is a valid subset of the full Cw language... we are able to formalize the type system and operational semantics of the data access fragments of Cw.

If you have been following the discussions here of Cw, you already know about the language features discussed here, since the paper doesn't introduce new features. If you haven't seen Cw, section 2 is a short and readable introduction.

The rest of the paper is more formal, and unless you need to prove formal results regarding Cw, might not be all that interesting. It won't hurt to keep in mind that it exists, since some of us may need something like FCw at one point or another.

Judy Stores

A Judy tree is generally faster than and uses less memory than contemporary forms of trees such as binary (AVL) trees, b-trees, and skip-lists. When used in the "Judy Scalable Hashing" configuration, Judy is generally faster then a hashing method at all populations.

Some of the reasons Judy outperforms binary trees, b-trees, and skip-lists:

  • Judy rarely compromises speed/space performance for simplicity (Judy will never be called simple except at the API).
  • Judy is designed to avoid cache-line fills wherever possible.
  • A b-tree requires a search of each node (branch), resulting in more cache-line fills.
  • A binary-tree has many more levels (about 8X), resulting in more cache-line fills.
  • A skip-list is roughly equivalent to a degree-4 (4-ary) tree, resulting in more cache-line fills.
  • An "expanse"-based digital tree (of which Judy is a variation) never needs balancing as it grows.
  • A portion (8 bits) of the key is used to subdivide an expanse into sub-trees. Only the remainder of the key need exist in the sub-trees, if at all, resulting in key compression.

The Achilles heel of a simple digital tree is very poor memory utilization, especially when the N in N-ary (the degree or fanout of each branch) increases. The Judy tree design was able to solve this problem. In fact a Judy tree is more memory-efficient than almost any other competitive structure (including a simple linked list). A highly populated linear array[] is the notable exception.

Worth a look, considering the open-source LGPL license and range of applications. HP released this library in 2004. From the PDF manual,

Judy arrays are remarkably fast, space-efficient, and simple to use. No initialization, configuration, or tuning is required or even possible, yet Judy works well over a wide dynamic range from zero to billions of indexes, over a wide variety of types of data sets -- sequential, clustered, periodic, random.

Scrap your boilerplate with class: extensible generic functions

Scrap your boilerplate with class: extensible generic functions. Ralf Laemmel and Simon Peyton Jones.

The "scrap your boilerplate" approach to generic programming allows the programmer to generic functions that can traverse arbitrary data structures, and yet have type-specific cases. However, the approach requires all the type-specific cases to be supplied at once, when the function is defined: the function is closed. In contrast, Haskell's type classes support open, or extensible functions, that can be extended with new type-specific cases as new data types are defined. In this paper we show how to extend the scrap-your-boilerplate approach to support this open style. On the way we demonstrate the desirablility of abstraction over type classes, and the usefulness of recursive dictionaries.

If you haven't been paying attention, this is your chance to learn about the "scrap your boilerplate" approach to generic programming in Haskell. We mentioned and discussed the earlier papers in the series.

Like many of Peyton Jones's papers this one is an enlightening exploration of language design.

Generics: The Importance of Wildcards

Martin Bravenboer writes about generic wildcards in Java, and concludes that it is unfortunate that C# will not support wildcards or a similar mechanism.

Eric Gunnerson from Microsoft replies.

I was originally a type-erasure fan, but these days I am not so sure. I hope this turns into a fruitful discussion that helps me decide...

P.S

The Java paper was mentioned on LtU before.

PLT Needs You!

PLT needs your help. From the mailing list:

Financial support for our implementation and infrastructure work is running out over the next year. I am hoping to raise money from the National Science Foundation (NSF) with a proposal to the infrastructure initiative. The purpose of this initiative is to help with the maintenance of projects that are useful in research and advanced development, but also teaching and education. The emphasis is on the former two; the latter two are acknowledged, and I don't think we need to worry about the latter.

So, if you have used DrScheme/MzScheme/MrEd/Web Server etc for research or advanced development and you don't want the project to die, could you please send a short one-page, signed letter of support to me c/o Eli Barzilay on some formal looking letter head please? The letter should state what you do, where you work, and that you have used PLT Scheme for research and advanced development. If you are so inclined, you can also add that it is critical and what you have done with it.

For addresses, see below. Thanks! -- Matthias

P.S. Electronic signatures are okay, too, indeed they are ideal.

Matthias Felleisen
c/o Eli Barzilay
Trustee Professor
College of Computer Science
Northeastern University
Boston, MA 02115

The deadline for letters of support is 1 July 2005.