Lambda the Ultimate

Probably goes against Dijkstra's advice of modeling real world objects, but Luca Cardelli is exploring Programming Languages for Biology.

If you want to go to another country, it would behoove you to learn the language of the land. Luca Cardelli, an Italian researcher working in England, knows this lesson well. He wants to help scientists travel to an unknown country — the membranes and cells of our bodies — and feel right at home. To do this, he is developing a computer language to model the processes of biology.

In this clip from an IT Conversations interview Jon Udell tries to explain what dynamic languages are.

I think this clip makes it clear that (a) the situation as regards the terminology used to describe type system issues is beyond hope and (b) the issues Jon tries to deal with are quite real.

As we noted many times in the past, "strong" typing is not the same as "explicit typing" and most of the goals Jon talks about are achievable with statically typed languages.

In fact, dynamic - or scripting - languages encourage a development process in which programs are modified and translated iteratively, so having the compiler check the "morphed" data structures and infer their type shouldn't really be a problem, and in fact can help the developer. Naturally, since not all the code is changed at once a language that would appeal to Jon would allow the programmer to restrict the scope of type checking to specific parts of the program (e.g., only routines that may in fact be invoked).

Whatever your opinions regrading typing, I think it is very clear that we should move the debate away from having Pscal and Java as the only examples of strong typing, and C as the only example of weak typing. I hope LtU would set a good example for the rest of the community...

The Schematics Scheme Cookbook is a collaborative effort to produce practical documentation for using the Scheme language, particularly in commercial environments. It is focused on PLT Scheme, although other Scheme dialects are supported as far as possible.

A nice attempt by several of lambda's friends to provide practical help for people trying to solve real problems using Scheme.

I think the community around any non-mainstream language must encourage and support such efforts for the language to have any chance of gaining momentum.

This is somewhat related to our discussion of real life programming using Haskell, and about the success of so-called scripting languages.

I must admit that I use Python for my scripting work. Tried to use Scheme but it was too much of a bother. Guess it's time to try again.

The SRFI 40 document (now in "final" status) includes a very nice discussion of streams, especially as regards implementing them in strict languages (i.e, "even" vs. "odd" streams).

The code is in Scheme, of course, this being an SRFI, but basic knowledge of Scheme should be enough in order to read the highly readable SRFI document. Do check it out if you are interested in streams.

Jayadev Misra's tribute to EWD at Europar-2003.

A short essay that may be relevant to the question whether language designers should make their languages more forgiving as regards programmer errors, or more stringent.

Hunter-gatherers from the Piraha tribe, whose language only contains words for the numbers one and two, were unable to reliably tell the difference between four objects placed in a row and five in the same configuration, revealed the study.

A new study may provide the strongest support yet for the controversial hypothesis that the language available to humans defines our thoughts.

The result is controversial enough that I withhold judgement until I read the journal paper.

MOZ 2004 is devoted to bringing together people interested
in the Oz language and the Mozart development platform.
MOZ 2004 will take place in Charleroi, Belgium on October
7-8, 2004. Early registration is possible until August 22.

MOZ 2004 will have two invited speakers (Gert Smolka, the
father of Oz, and Mark Miller, the father of the E secure
distributed language) technical sessions (see the list of
all 23 accepted papers), five tutorials (general overview,
constraint programming, distributed programming, teaching
programming, and tips on practical deployment), and a
panel on the future of Oz. Last but not least, MOZ 2004 is
an excellent opportunity to meet and discuss with the
Mozart designers and other users.

We're going to need a fabric of pervasive intermediation, and the TCP/IP of Web services -- that is, SOAP -- will enable that. But we're also going to need a whole lot of agility woven into that fabric. I want middleware that works like Indigo, but I want to program it in a language that works like Python.

Jon Udell is one of the champions of so-called dynamic languages. This item is yet another attempt to explain the importance of dynamic languages and the central role they should play in building complex networked applications.

I am sure all you guys debating static typing in the forum are going to find this worth reading (and worth debating).

We have previously mentioned these videos of a series of panel discussions that were hosted by the MIT Dynamic Languages group in 2001. I just watched them again and I thought they were great, so I'm re-posting them for people who missed them the first time around and as a reminder for anyone who'd like to watch them again.

There are three separate panels on different topics: compilation, runtime, and language design. The panelists are distinguished people mostly from the Lisp/Scheme/MIT world. These panels were a precursor to the Lightweight Languages workshop series.

The videos are in QuickTime format. To play them on Linux I used VLC. mplayer wasn't able to synchronize the audio and video.

A nice introduction by Chris Double.

In the previous example we've effectively called the continuation and then returned back to the caller of that continuation. What we really want to do is capture a 'partial continuation' or 'subcontinuation'. That is, not the entire continuation but a section of it and then return back to the caller.

The 'splitter' operator mentioned in the header to this article implements exactly that. It marks the point at which a continuation should be captured up to, instead of the entire continuation. A 'partial continuation' can then be reified up to this point.