Lambda the Ultimate

B. Stroustrup. The design of C++0x. C/C++ Users Journal. May 2005.

My basic opinion is that the language wish list is far too long, and that the libraries wish list is far too modest.

Two topics of interest: type safety, and support for concepts in the template model (i.e., the generic programming model).

Interesting list.

Personally, I am most interested in seeing results come out of the PltStepper, PltDb and ErLisp projects.

Some of the papers mentioned recently are quite advanced, and require careful reading.

It occured to me that not everyone here is adept at reading papers of this sort, and that some tips might be helpful.

So if you are one of those who constantly read papers, how about describing your reading habits?

Do you skim first? Do you follow the detailed proofs on first rading? Do you try to execute code?

Specifically, what would you suggest to someone who asks for help reading A Monadic Framework for Subcontinuations?

And no, "go back to school" isn't an acceptable answer...

Tim O'Reilly posts a trend graph showing programming language books market share from January 2003 to mid-June 2005.

As LtU readers know, I don't really care about language popularity metrics. They don't tell you much that isn't obvious.

But at least this graph is supposed to reflect real data...

Tim Bray is struggling with the way Java integrates generics and interfaces,

Some day I must find out why generic declarations extend rather than implement interfaces. Grr.

Kinda makes me understand what my students go through when they first encounter Ada's generic model (which is much easier to understand, I hasten to add).

For those who want to know what's up in the world of VB, the VB8 Language Spec is available. Mostly, it looks like the language keeps creeping towards the C# language model, so much so that I always recommend that anyone using MS VS simply go the C# route, as it is more true to the .Net model. Not much to report from the Language Innovation department:

• Operator Overloading
• Generics
• IsNot Keyword
• Using Keyword
• Unsigned Integer Types
• Partial Classes
• Background Worker Object

(Note: In typical MS fashion, the VB Spec is an executable file, but the file is just a zip executable that contains a Word document.)

It seems worthwhile to connect a few discussions we had recently, and perhaps put them in prespective.

Web programming is becoming more and more important, and many feel there's room for better programming language support for the style of programming is entails. One approach is, of course, to design dedicated (i.e., domain specific) programing languages, such as Links. The other approach is to build application frameworks, but this isn't as easy as it might sound, and depends on the underlying language features, for example continuations (continuations and web programming were discussed here many times).

Ajax style web applications may require multi-language programming, and pose their own set of software engineering difficulties. The Ruby on Rails framework (tutorial) supposedly handles Ajax very nicely, and is causing some developers to move in the direction of Ruby. Libraries and framework often have this effect, and influence language popularity more than fundamental language features. This is quite reasonable since, as we see repeatedly, it is quite difficult to appreciate a language by evaluating language features in isolation.

It might be helpful to consider what Ian had to say regarding Ruby on Rails as opposed to Python web frameworks.

I don't think the important issue at the moment is to decide which language is best. I think it is more important to identify the trends and establish if language design can help improve the state of the art, and if so where.

Personally, I think the answer is yes, and I mentioned some areas of opportunity before, but I'd be interested in hearing what others think.

This isn't really about programming languages, but I still think it is relevant to our discussions,

A lot of Ajax applications have a lot of script (often 10 or 20,000 lines) and without broadband, the download of this can be extremely painful. With broadband and standard tricks for compressing the script, it is a breeze. Even if you could download this much script in 1997, it ran too slowly. Javascript wasn't fast enough to respond in real time to user actions let alone to fetch some related data over HTTP. But Moore's law has come to its rescue and what was sluggish in 1997 is often lightning quick today.

We often tell people that execution speed is less important than code readability and flexibility, which depend on high level abstraction facilities found in HLLs. I guess we should consider bandwidth efficiency instead...

What I predict will drive this change is the advent of truly mobile computing on mobile devices. This is going to force the game to change. It is way too expensive to build solutions for mobile on J2ME and often too poor a customer experience when they are built using WAP (except for super simple things). I think that we're going to rethink browsing around a model which has pub/sub, events, and caching built in..

Languages for mobile code are going to be important for this next phase. I think there are still many interesting language design questions related to mobile code that people should start thinking about (cf. Links). I am sure a savvy language maven can become the next BDFL, or alternatively earn some big bucks, by helping attack this problem.

A Judy tree is generally faster than and uses less memory than contemporary forms of trees such as binary (AVL) trees, b-trees, and skip-lists. When used in the "Judy Scalable Hashing" configuration, Judy is generally faster then a hashing method at all populations.

Some of the reasons Judy outperforms binary trees, b-trees, and skip-lists:

• Judy rarely compromises speed/space performance for simplicity (Judy will never be called simple except at the API).
• Judy is designed to avoid cache-line fills wherever possible.
• A b-tree requires a search of each node (branch), resulting in more cache-line fills.
• A binary-tree has many more levels (about 8X), resulting in more cache-line fills.
• A skip-list is roughly equivalent to a degree-4 (4-ary) tree, resulting in more cache-line fills.
• An "expanse"-based digital tree (of which Judy is a variation) never needs balancing as it grows.
• A portion (8 bits) of the key is used to subdivide an expanse into sub-trees. Only the remainder of the key need exist in the sub-trees, if at all, resulting in key compression.

The Achilles heel of a simple digital tree is very poor memory utilization, especially when the N in N-ary (the degree or fanout of each branch) increases. The Judy tree design was able to solve this problem. In fact a Judy tree is more memory-efficient than almost any other competitive structure (including a simple linked list). A highly populated linear array[] is the notable exception.

Worth a look, considering the open-source LGPL license and range of applications. HP released this library in 2004. From the PDF manual,

Judy arrays are remarkably fast, space-efficient, and simple to use. No initialization, configuration, or tuning is required or even possible, yet Judy works well over a wide dynamic range from zero to billions of indexes, over a wide variety of types of data sets -- sequential, clustered, periodic, random.

This article points out how open source scripting languages are in vogue in the corporate world:

Scripting languages have been used to build millions of applications on the Web, but in general have not been adopted widely by corporate developers. But more and more businesses and IT professionals are looking to these languages as a way to simplify and speed the creation of custom in-house programs, thus avoiding the now all-too-common logjam of late or overbudget applications.

Personally, I think the rise of these scripting languages as well as languages like Java demonstrates that the use of new programming languages is more fluid than most are willing to admit. Of course, it also demonstrates that building new scripting languages is becoming easier and easier.

(via PLNews)