Lambda the Ultimate

Follow these links.

Reading some of the recent threads, it occured to me that there's room for a new thread in the spirit of the Getting Started thread and threads like Explaining monads and Why type systems are interesting.

The issue I want to raise is what is at the focus of the study of programming languages. By this I mean, what is the thing (or things) programming language researchers study. I do not want to discuss what should be done, at the moment, but rather orient outsiders about the actual practice in the field.

Specifically, my aim is to explain which aspects of languages are studied, and to let people know how these research areas are called, and perhaps where to find more information about new results etc. I am not thinking about specific lines of research, but rather about the kinds of things researchers study.

My intention will hopefully be clearer after reading my answer to the question in the title of this post:

Most of the time, programming language theory (PLT) is concerned with the semantics (i.e., meaning) of specific programming constructs. Much less outstanding research is done on other aspects, such as syntax, implementation and runtime issues, and languages as wholes (compared to the study indvidual constructs).

This is, of course, a very incomplete answer to the question. Let the discussion begin...

After Larry, it is appropriate to read Anders who makes a point of saying that in designing C# they try to make sure that there are not multiple ways of doing things...

I should point out that saying it's all syntax in the end isn't the same as saying that languages are syntactic sugar. The term "Syntactic sugar" is often misused. It is a technical term, with precise meaning ;-)

Personally, I find this sort of humour bothering: Oh, absolutely. And, you know, honestly, first of all, let's give credit where credit is due. I am not inventing anything completely new here. It's all based on this thing called lambda expressions or lambda calculus or whatever, which has existed in the functional programming space for decades. But somehow, that has never really seen the light of day in a mainstream programming language.

Imagine a doctor (GP) talking about the Avian flu: "There's something called mutations or whatever, which has existed in biology for decades. But somehow, that has never really seen the light of day in general medical practice."

It's quite legitimate to mention that some of these ideas, while not original, were indeed not to be found in "mainstream languages" (even though, one could argue that C# isn't the first to try to do something about it). But why the dismissive "or whatver"? LC is part of the science of programming (and of CS in general), and to me that sounded like trying to make Philistines happy. I think all of us can try to raise the level of discussion in the field.

It's an interesting interview nonetheless, and Anders always sounds like a nice and reasonable person.

Larry is as amusing as you'd expect him to be.

Of particular intest is the endorsement of Pugs, and the fact that Haskell is mentioned by name.

Since Erik's got us on a VB kick these days, here are a couple recent videos from Microsoft's Channel 9 on current and future developments of the language:

Dynamic Programming in VB - more on the "static typing where possible, dynamic typing where necessary" theme.

VB Language Futures - ideas for the future of VB, including some new syntactic sugar, type inference, and all this query stuff.

At a glance, the dynamic interfaces make me think of Semantic Casts: Contracts and Structural Subtyping in a Nominal World. I wonder if there's any relevance.

Language design isn't just about big ideas, it's also about little details...

In writing Scheme programs, I've learned a lot about coding, design, architecture, and aesthetics.

Old news, right? Still, this piece might be worth sending around to your unenlightened frieds.

Have you ever pressed the "stop" button in your web browser? Did it always work? Should PLs make it easier for developers to make it work?

Asynchronous Exceptions in Haskell

Asynchronous exceptions, such as timeouts, are important for robust, modular programs, but are extremely difficult to program with — so much so that most programming languages either heavily restrict them or ban them altogether. We extend our earlier work, in which we added synchronous exceptions to Haskell, to support asynchronous exceptions too. Our design introduces scoped combinators for blocking and unblocking asynchronous interrupts, along with a somewhat surprising semantics for operations that can suspend. Uniquely, we also give a formal semantics for our system.

PS: this was mentioned some time ago on LtU, but seems to be gone.

(via Keith)

We analyze the source code of production Java open source projects such as Ant, Tomcat and Batik and load that analysis into a java examples database designed for easy searching. You enter the name of a Java API Class.method you want to see example invocations of and click Search.

Nice idea. Looks like a useful resource.

More on Ruby and Rails in this interview.

Rails is becoming the main reason people decide to pick up Ruby, which is something worth pondering. The interaction between a programming language and a very dominant framework, which isn't part of the standard library of language, is quite interesting.

Some quotes from the interview:

Rails is opinionated software. It eschews placing the old ideals of software in a primary position.

One characteristic of opinionated software is the notion of "conventions over configuration." If you follow basic conventions, such as classes are singular and tables are plural (a person class relates to a people table), you're rewarded by not having to configure that link. The class automatically knows which table to use for persistence. We have a ton of examples like that, which all add up to make a huge difference in daily use.

I really like our domain-specific languages. The beauty of specifying relationships with belongs_to, has_one, has_many and has_and_belongs_to_many. The ease of using validations like validates_presence_of :name.

I think Rails feels, smells, and tastes like it does exactly because its very Ruby-like. It plays heavily on the best in Ruby. The blocks, the ease of creating domain-specific languages, and so on.

What has happened, though, is that Active Record has reduced the pain of dealing with the object-relational mismatch to a point where its a lot less appealing to seek alternatives—especially with databases like SQLite that give you the feel of flat text files, but within the context of SQL.