Lambda the Ultimate

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?

Type-Based Optimization for Regular Patterns, by Michael Y. Levin and Benjamin C. Pierce. WWW Workshop on High-Performance XML Processing, May 2004.

We describe work in progress on a compilation method based on matching automata, a form of tree automata specialized for pattern compilation, in which we use the schema of the value owing into a pattern matching expression to generate more efficient target code.

A set of slides is also available.

Logical Methods in Computer Science is a fully refereed, open access, free, electronic journal. It welcomes papers on theoretical and practical areas in computer science involving logical methods, taken in a broad sense... Papers are refereed in the traditional way, with two or more referees per paper. Copyright is retained by the author.

Many of the topics to be covered by this new journal are related to PL research or are of interest to PL researchers, so I hope many of the papers published in it will be interesting enough to discuss here.

The editorial team is impressive, with Dana Scott as editor-in-chief, and Plotkin and Vardi as managing editors.

The editorial board includes many prominent figures among them Abadi, Abramsky, Gries, Pierce, Wadler and Wand.

A very rich site devoted to tracking down the source code for the original Fortran compiler:

My name is Paul McJones. I hope to use this weblog to discuss software history among other topics. For several months I’ve been studying the early history of Fortran, and trying to track down the source code for the original Fortran compiler. Although I just set up this weblog recently (June-July 2004), I’ve created back-dated entries to document my quest in chronological order

It seems most items recently are about programming language history... This site describes an interesting quest, which makes me wonder if the evolution of more recent languages will be easier to document, given the Internet and so forth. It would be rather amusing if LtU will once be used as an historical resource ;-)

The idea of preserving classic software is a good one. I think programming languages (and programming technology in general) are very good indecators of the state of the art and the major issues of the day (e.g., Java and the Net), so building a timelime by considering PLs sounds like a good idea.

We should also keep in mind that John Backus of FP fame was famous even before that for his work on compilers, and was involved with the Fortran team at IBM.

Functional Objects. Matthias Felleisen. ECOOP 2004. slides (pdf).

In my talk, I will compare and contrast the two ideas of programming and programming language design. I will present and defend the thesis that good object-oriented programming heavily "borrows" from functional programming and that the future of object-oriented programming is to study functional programming and language design even more.

Not all that much that is new for LtU readers, but a nice overview none the less. Includes some details about the PLT Scheme approach to modules and objects.

(link)

From 20 years of the ACM SIGPLAN Conference on Programming Language Design and Implementation: 1979 - 1999. A Selection.

A one page retrospective of this highly important paper. Useful as a guide to the literature and related research.

The proceedings of the International Lisp Conference 2002 are now freely available for download here. A selection of video-recorded talks are also downloadable (currently the Robocup ones). ILC2002 was previously covered on LtU in a great report from Oleg.
Enjoy!

A very interesting site dedicated to the history of programming languages.

The navigation is a bit clunky, and I am still not sure I understand all the features of the site, but the database is impressive (use the "search" button on the right hand side of the window to open the search frame).

The site includes amusing statistics (e.g., which decade produced the most programming languages?)

It would be interesting to see what LtU readers think about the taxonomy used here. It's quite fine-grained.

Should Sun open-source Java? "The Big Question" keynote debate at JavaOne in San Francisco was devoted to this question.

Now, I don't really know what open-sourcing a language means, but this is obviously an important question...

The Java language specification and the JVM spec are both public. The Sun JVM isn't open source, but there are many other Java VMs out there.

The community process is controlled by Sun, but then again some process must exist if you want the language to remain cohesive, and someone or some group will have to control this process.

So it seems that this is ultimately about community dynamics. Languages create communities. Communities shape the way languages evolve.

LtU friends are readers who have us on their blogrolls are encouraged to change the URL to point to our new location.

Thanks!