Lambda the Ultimate

At a session entitled "The Great J2EE vs. Microsoft .Net Shootout" at the OOPSLA conference here this week, software development superstars debated the relative strengths and weaknesses of Microsoft's .Net and Sun's Java 2 Platform, Enterprise Edition. The panelists included Anders Hejlsberg, Microsoft Corp. distinguished engineer and lead designer for the C# language; John Crupi, chief Java architect for Sun Services at Sun Microsystems Inc.; Don Box, leading Microsoft architect on its Indigo project; Rob High, IBM's chief architect for the WebSphere Application Server Family; and Alan Knight, lead developer for the Web Toolkit at Cincom Systems Inc. and a Smalltalk expert.

From the eWeek coverage it would seem that the panelinsts didn't explore the deep, underlying, issues (but then, for that you read LtU).

Still, some of you might want to check out this article for yourselves.

This might be an interestng project to keep an eye on.

The papers seem to cover a wide range of topics relevant to end user programming in a variety of settings.

90 minute video presentation from Marc Feeley, along with accompanying PowerPoint slides and source code, for a Scheme to C compiler. Good discussion of continuations and closures, as well as some dipping into the area of compiler construction.

How to write a simple Scheme to C compiler, in Scheme. In only 90 minutes! And although not supporting the whole Scheme standard, the compiler supports fully optimized proper tail calls, continuations, and (of course) full closures. The compiler is implemented using two important compilation techniques for functional languages: closure conversion and CPS-conversion.

The emphasis is on the 4 major problem areas that crop up in an attempt to convert Scheme to C:

• tail-calls a.k.a. tail-recursion opt.
• first-class continuations
• closures of indefinite extent
• automatic memory management i.e. GC

The solution presented gives a series of source-to-source transformations. Stage 1 of the compiler expands the 'let' forms in the Scheme code. Stage 2 converts continuations to CPS. Stage 3 converts the code to closures using encapsulated closure objects. Stage 4 is not presented but touches on how the results would lend itself to a GC implementation.

Gordon Plotkin's Call-by-Name, Call-by-Value and the Lambda Calculus (Theoretical Computer Science , Vol. 1, pp. 125-159, 1975), is available online.

The fundamental point made in the paper should seem natural to most LtU readers: In order to reason about programming language semantics one should look for programming language/calculus pairs.

The paper contrasts CBN and CBV, and shows the differences between the Lambda Calculi appropriate for describing each of them.

Yet another simple example of decorators in Pyhton (via Daily Python-URL).

Microsoft gave a demo of their Software Factories & DSL tools and philosophy over at OOPSLA. It would be great to see the slides but as far as I can see they aren't available online.

I want to love the DSL approach, but I still haven't seen enough examples and detailed discussion to be convinced.

I'd be happy to hear what others think about the UML vs. DSL controversy.

An article from IEEE Security & Privacy magazine.

The article is an accessible introduction to the idea of static code analysis. Several security-related tools are described.

I guess it's tool-week here on LtU what with Dialyzer, JFluid and now this...

I am pleased to announce that the Scheme Language Editors Committee
has produced its first progress report. This report details the
progress made from appointment of the committee in January, 2004,
through its meetings at ICFP in September, 2004.

The progress report can be found at

http://www.schemers.org/Documents/Standards/Charter/

The Steering Committee has also made some small amendments to the
Charter. The updated charter can be found at the same location.

The members of the Scheme Language Editors Committee are:
Marc Feeley, editor in chief (Universite de Montreal)
Will Clinger (Northeastern University)
Kent Dybvig (Indiana University)
Matthew Flatt (University of Utah)
Richard Kelsey (Ember Corporation)
Manuel Serrano (INRIA)
Michael Sperber (DeinProgramm)

The members of the Scheme Language Steering Committee are:
Alan Bawden (Brandeis University)
Guy L. Steele Jr. (Sun Microsystems)
Mitch Wand (Northeastern University)

For the Steering Committee,
--Mitch Wand

According to Infoworld,

JFluid is a "profiling" tool, software that examines Java applications and informs developers of potential performance bottlenecks in their code. It was developed by a team lead by Misha Dmitriev, who was transferred from Sun Labs to the software group last week, according to a statement on Sun's Web site.

Which makes me wonder about performance tools in IDEs. On the one hand, performance can be an important factor in software development, and educating programmers about performance isn't such a bad idea. On the other hand, performance considerations are often abused ('the root of all evil,' and all that).

So what kind of performance tools do we really want inside our IDEs? How is the answer effected by the type of programming language language considered? How about IDEs targeting students (DrScheme etc.)?

A highlight from the Erlang/OTP User Conference 2004:

The Dialyzer is a static analysis tool that identifies software discrepancies such as obvious type errors, unreachable code, redundant tests, virtual machine bytecode which is unsafe, etc. in single Erlang modules or entire applications. Currently, it starts its analysis from BEAM bytecode and reports to its user the functions where the discrepancies occur and an indication of what the discrepancy is about.

A lot of static-analysis programs have been written for Erlang but this is the first one that programmers have immediately downloaded, used, and liked. I would love to see more researchers following the development philosophy they describe in their paper.