Lambda the Ultimate

The idea of programming-language determinism has some truth to it, but is overrated. Because we are often tackling the same problems in C, Perl, Scheme, Smalltalk, and so on, we can usually find a way to analyze them and code solutions using common designs. Sometimes the features of a particular language make a particular solution much more elegant and comprehensible, and in that case form influences content. But these languages have enough common ground that they can share many designs. C may have pre-increment and post-increment operators, but you can still add 1 to a variable in any language that supports variables.

I agree with some of the style tips the author gives, but I think understanding the different abstraction facilities different languages offer is even more important for writing readable and maintainable code.

Yet it seems to me that the situation right now is that LtU has readers with very different backgrounds, among them many readers who haven't studied PL formally. Others come from academia, and study PL theory for a living.

Since we have such a lively community it occured to me to start a thread for advice on where to begin aimed at those who haven't studied PL theory, yet want to follow the papers and books we discuss.

So the question, mostly directed at old timers, is to which resources would you send a friend asking for advice on learning about the theoretical study of programming languages?

P.S The early LtU archives may be helpful, since I used LtU to organize and collect the papers I read when I began my studies in the field.

• Formula Engine Rewrite is an amusing story of how real software gets developed. In this case, a language processor inside Lotus Notes. VM hacking and the like...

• Waterstone's fires 11-year-employee for blogging. I wouldn't normally link to such an item, but since we all tend to buy books, and I am a great fan of bookstores, allow me to suggest our UK readers boycott Waterstones's.

In 50 years, we’ve already seen numerous programming systems come and (mostly) go, although some have remained a long time and will probably do so for: decades? centuries? millennia? The questions about language designs, levels of abstraction, libraries, and resulting longevity are numerous. Why do new languages arise? Why is it sometimes easier to write new software than to adapt old software that works? How many different levels of languages make sense? Why do some languages last in the face of "better" ones?

Nothing particularly new in this article but you might want to take a look.

I wish you all a happy new year, and hope that you are able and that you want to donate something for those less fortunate.

Pascal-FC is a programming language aimed at supporting the teaching of concurrent programming. It supports a wide range of concurrency primitives including semaphores, monitors with condition variables, synchronous message passing using channels (as in occam and CSP), remote invocation (as used in the Ada rendezvous), protected resources (as used in Ada 95 protected objects) and requeue. All of these features can be easily used, either in isolation or together.

An important feature of the implementation of Pascal-FC is the random switching between user processes incorporated into the run-time system. This provides an excellent simulation of true parallelism and invariably finds bugs in poorly structured programs.

It seems like Pascal-FC wasn't mentioned here before, and since there are implementations for various platforms I thought some of you may want to download and play with it a bit.

Link: This article gives an easy to follow introduction to the SETL language. SETL has been around since 1970 and excels at manipulating sets.

Being a mathematician, I've always dreamt of a programming language that would make use of the powerful formalism of Set Theory. Two years ago, I started looking for an open-source software tool to use in an elementary Set Theory class. I had a hard time finding any on the Net, but in the end I found the object of my dreams: a structured, general-purpose, open-source programming language that implements as closely as possible the Set Theory formal language.

(Previous LtU discussion)

A couple of years back, the Pragmatic Programmers had this sage advice:

Learn at least one new [programming] language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut.

For 2002, Haskell was presented as the LOTY choice - pretty good choice. But since that time, the authors became enamored of the Ruby way, and have failed to submit a nominee for subsequent annums. My personal choice for the coming year is tender young Alice. Anyone else have their dates picked out? Or are you all into the Language of the Week per our dear moderator?

The article highlights several interesting features of Ruby,

Yukihiro Matsumoto, aka Matz, has said that "The purpose of Ruby is to maximize programming pleasure", and experience has taught me that enjoying the creative process leads to faster development and higher quality code. Ruby features powerful object-oriented abstraction techniques, extreme dynamism, ease of extensibility and an armada of useful libraries. It is a veritable Swiss Army machete, precisely the sort of tool one should bring into uncharted territory such as the NFS-mounted priority queue I was seeking to build...

One of the things to note about this extension is I actually was able to add a method to Ruby's built-in File class. Ruby's classes are open--you can extend any class at any time, even the built-in ones. Obviously, extending the built-in classes should be done with great care, but there is a time and a place for it, and Ruby does not prevent you from doing so where it makes sense. The point here is not that you have to extend Ruby but that you can. And it is not difficult to do...

In Ruby a module not only is a namespace, but it can be mixed in to other classes to impart functionality. The effect is similar but less confusing than multiple inheritance. In fact, Ruby classes not only can be extended in this way, but instances of Ruby objects themselves can be extended dynamically with the functionality of a module--leaving other instances of that same class untouched.

Link: Alice is an extension to ML to support Open Programming, described as ML meets Oz. Alice Version 1.0 has been released.

Alice [is] a conservative extension of Standard ML. It adds only few simple, orthogonal high-level concepts that together form a coherent framework supporting all aspects of typed open programming.... Our understanding of open programming includes the following main characteristics:

• Modularity, to flexibly combine software blocks that were created separately.
• Dynamicity, to import and export software blocks in running programs.
• Safety, to safely deal with unknown or untrusted software blocks.
• Distribution, to communicate data and software blocks over networks.
• Concurrency, to deal with asynchronous events and non-sequential tasks.

(via Chris Double)

(also Previous discussion on LtU)

Link: The Lua folks discuss their implementation of coroutines, using Create, Resume and Yield methods.

Lua implements the concept of asymmetric coroutines, which are commonly denoted as semi-symmetric or semi-coroutines. Asymmetric coroutine facilities are so called because they involve two types of control transfer operations: one for (re)invoking a coroutine and one for suspending it, the latter returning control to the coroutine invoker. An asymmetric coroutine can be regarded as subordinate to its caller, the relationship between them being similar to that between a called and a calling routine.


Lua coroutine facilities provide three basic operations: create, resume and yield... Function coroutine.create creates a new coroutine, and allocates a separate stack for its execution... Function coroutine.resume (re)activates a coroutine, and receives as its required first argument the coroutine reference... A coroutine suspends by calling function coroutine.yield in this case, the coroutine’s execution state is saved and the corresponding call to coroutine.resume returns immediately.

The main difference with typical thread implementations is that (a). the caller is suspended until completion and (b). a coroutine can return values like a function call. I suppose I'd summarize it as functions that retain state between calls.