Lambda the Ultimate

You're part of the C# language design team thinking about the next version of C# (ie the version after VS 2005). You get the following email:

When I'm writing code, I often come across a situation where my code throws an exception because another component called with a null parameter. I'd like a way to prevent that from happening.

What are the pros and cons of such a feature? What are the ramifications of adding it to the language? What would have to change? What is your recommendation? Exactly what would such a feature look like?

A discussion over on Eric Gunnerson's weblog.

I suppose this is one way of doing language design. You are welcome to comment on the specific issue, or on this cutting edge language design technique ("just blog it, silly")...

Just to get the juices flowing, I should point out that this is a type system issue.

Should we have a language design department for general discussions about language design?

Here's something to offset all the
long discussions on typing that
have been taking place recently
(see Concurrent Components With Message Passing):

In our experience, the right default for structuring programs is as concurrent components that communicate through asynchronous message passing. Components should be sequential or communicate synchronously only if necessary. This is not a new idea; Carl Hewitt anticipated it thirty years ago in the Actor model. But today we have many strong reasons for accepting it. For example: [...] (discussion continues with
references to Erlang, E, and CTM)
[...] Unfortunately, these reasons and their conclusion are almost completely ignored by mainstream languages and by books on program design. In both, object-oriented programming and shared-state concurrency are given priority, even though they are the wrong default. [...]

So, is this heresy or an unfortunately ignored truth?

A Methodology for Generating Verified Combinatorial Circuits. Oleg Kiselyov, Kedar N.Swadi, Walid Taha.

This is the final version of a paper accepted for Embedded Software Conference 2004. The paper doesn't show any circuits but the straight-line C code should be implementable easily.

There is a significant difference from FFTW in that the authors don't do any intensional code analysis -- the generated code is black box and can't be processed nor manipulated any further. Moreover, the generated code can't even be compared by equality. Oleg tells me that the paper is somewhat obsolete: it says that they approach FFTW in the number of operations in the generated code. That is no longer true: the power-two FFT generated code has exactly the same number of floating-point operations as that in codelets of FFTW.

Abstract interpretation is used to fix several problems in the generated code. This makes some optimizations possible (e.g., avoiding code duplication).

Multi-stage programming fans, enjoy!

Booch's Rational User Conference presentation on software archeology is available online.

This is related to our previous discussions about reading code, mining code for patterns and about the history of programming languages and software systems.

Obviously, many of the issues mentioned in the presentation (e.g., SLOC counts) are programming language dependent. The major case study is Eclipse, which should make this interesting to IDEs buffs as well.

See here for more on Booch's work on documenting software architecture.

This project's goal is to provide integrated support for Aspect Orientated Programming in Oracle's JDeveloper IDE. Where possible we hope to make use of, and reuse code from, projects that have solved similar problems for other IDEs. The initial focus of the project is to integrate ADJT, the AspectJ design time environment, into JDeveloper.

It would be interesting to see whether projects such as this will help get AOP accepted by industry.

(via Val Henson's weblog)

This paper (from HotOS IX) describes a software design approach which seems very close to the design techniques erlang tries to encourage.

You knew it couldn't be far behind, right?

Defining and Using Generics in Visual Basic 2005 on MSDN has the details.

From time to time I like to return to the issue of database integration, only to once again remark that the difficulty in creating good database APIs (as opposed to simply embedding SQL) is the result of the poor programming facilities provided by most programming languages (e.g., no macros for syntax extension, no continuation or first class functions to handle control flow etc.).

Why return to this topic today? Jeremy Zawodny aruges on his blog that Database Abstraction Layers Must Die!

Along the way he says,

Adding another layer increases complexity, degrades performance, and generally doesn't really improve things.

So why do folks do it? Because PHP is also a programming language and they feel the need to "dumb it down" or insulate themselves (or others) from the "complexity" of PHP.

Ouch!

Why do we need an abstraction layer anyway?

The author uses an argument I hear all the time: If you use a good abstraction layer, it'll be easy to move from $this_database to $other_database down the road.

That's bullshit. It's never easy.

Double ouch, but true enough. Databases are like women (can't live with them, can't live without), and getting rid of one can be as painful as divorce...

So what's the solution? Surprise, surprise: use a libary. But isn't that an abstraction layer? Of course it is.

What Jeremy advocates is plain old software engineering and design. Everyone should do it. I can't beleive anyone does anything else.

But wait. I just told you it's hard to build such a library, since programming languages makes the design of such libraries hard (e.g., should you use iterators, cursors or return record buffers? should your library database access routine be as flexible as a select statement?) So we design libaries that aren't very good, but hopefully are good enough.

And that's the question I put before you. We all know about coupling and cohesion. We all know about building software abstractions. Are our tools for building abstractions powerful enough for this basic and standard abstraction: the database access abstraction layer?

Sven-Olof Nyström presented his Soft-typing system for Erlang at the 2003 ACM Erlang Workshop. I haven't tried it, but I thought it looked promising. His conclusions are thought-provoking too.

Zing is a new software model checking project at Microsoft Research.

Software model checking is hard, but it is still a promising line of research.

Tools are generally influenced by the type of languages they model. On top of that, I am sure software model checking is going to influence language design and implementation.