Lambda the Ultimate

Ok, I added Scala to the spotlighted languages.

The object-functional department should still be used for items that deal with issues relating to the mixture of the two paradigms, for other object-functional languages etc. I expect many items in the new Scala department will need to be also included in the object-functional dept. (items can belong to more than one department).

In Defense of Pattern Matching

As I wrote before, Scala aims to unify object-oriented and functional programming. When people talk about functional programming, they usually mean one of two different things: In the exclusive sense, functional means no side-effects. In the inclusive sense it means a programming style which composes functions in interesting ways. When I talk about functional programming, I usually mean it in the inclusive sense.

A number of language constructs are called functional because they are used a lot in functional languages or because they first appeared in a functional language.

He does acknowledge Smalltalk, as well as Ruby, Python, C#, Eiffel...

nat: I'd have thought that Smalltalk is both a functional and an OO language. It has far more in common with LISP than with current mainstream OO languages.

Smalltalk could easily have included functional features like some in Scheme, but that appears seldom (if ever) pursued in Smalltalk, in the older stuff I know at the language and standard platform level. App code writers must have found it trivially easy to add functional behavior at high levels, but unfortunately without special support from the VM.

I expect it makes a big difference to have functional support in the VM and libraries, so it would be a qualitative change for Smalltalk to have a lot of explicit functional semantics like general immutable objects and fine granularity copy-on-write done by the VM. It might go so much at odds with existing high level frameworks (like those in Squeak), that most high level things would need a fresh start.

Since Smalltalk and Lisp have so much in common, it would be not painfully hard to start with a Scheme (say gyp) and add a Smalltalk style object system (say gab) to allow class/message based dispatch, and have both gyp and gab share functional VM and library support, but you'd have a hard time saying gab was actually Smalltalk since it would be fairly different, having forked from Smalltalk at a very early point in design.

But Scala is a real thing and shouldn't be compared with hypothetical changes to Smalltalk (meaning I don't want to compare them). My understanding is that current Smalltalk technology doesn't particularly aim for coverage in functional effects.

I've been doing a little more research, and it's clear Lisp and Smalltalk heavily influenced each other through the folks working on them. For example, Steele and Gabriel write in the Evolution of Lisp that Scheme was intended as an exercise in exploring some actor based messaging (cf Hewitt) in the fashion of Smalltalk. Elsewhere L. Peter Deutsch says Alan Kay gave him an idea for a coding tactic in Lisp. (later Deutsch worked on Smalltalk's runtime and VM.)

I was just reading this document:

Daniel Weinreb and David Moon. Flavors: Message Passing in the Lisp Machine. A.I. Memo No. 602, Artificial Intelligence Laboratory, Massachusetts Institute of Technology, November 1980.

which you might say is an attempt to do Smalltalk style message passing in Lisp. So steps to integrate Smalltalk and Lisp are basically old, modulo specific goals in desired results. Folks in different camps were just working with different technology stacks, and didn't really have big ideological differences. (But I see more inclusiveness in Lisp, and less so in Smalltalk, which merely benefited from more refined best practices developed in Lisp.)

A former colleague of mine, Nik Boyd, is the developer of Bistro, "a place where people meet to share Java and Smalltalk." A point that he made to me when we got to talking about functional vs. object-oriented programming is that Smalltalk has two features that most of its progeny forgot: Protocols and Blocks. When you look at well-written Smalltalk code, it becomes apparent (IMHO) how important the grouping mechanism of Protocols is, and how pervasive the use of Blocks (essentially lambda expressions) is. Most Smalltalk code in Smalltalk implementations themselves (that I've seen, anyway) has a strongly functional flavor, and people forget that that's deliberate. Alan Kay is very clear that the point is to "eliminate state oriented metaphors from programming!" If that doesn't make Lisp and Smalltalk kissing cousins, I don't know what does.

A point that he made to me when we got to talking about functional vs. object-oriented programming is that Smalltalk has two features that most of its progeny forgot: Protocols and Blocks. When you look at well-written Smalltalk code, it becomes apparent (IMHO) how important the grouping mechanism of Protocols is...

Hmm? The notion of "protocol" in Smalltalk is purely conceptual and has no physical presence in the language. (Protocols have a more in-language presence in Objective C, and perhaps more statically-typed dialects of Smalltalk with which I am unfamiliar.) Of course, it's an unarguably useful and extensively used device, roughly corresponding to what the kids nowadays call a "duck type" or what Stepanov calls a "concept" in his work on generic programming.

Good point about Protocols, but I think the point was merely that they helped identify related features to the programmer, not that there was any enforcement or, for that matter, real "mechanism" behind them. It was very much the flavor of "duck typing," I think, particularly in the sense that by following Protocols and using Blocks you weren't strictly tied to the functionality locked into the inheritance hierarchy that was the point.

Smalltalk's implicit protocols were made explicit in Strongtalk, which had statically-typed protocols. These correspond very closely to Java interfaces. The same concept is regularly used in C++, implemented via abstract classes which serve as interfaces (i.e. protocols). So Smalltalk's statically-typed progeny, at least, didn't forget about protocols. Blocks, OTOH, were certainly forgotten for quite some time.

On the dynamically-typed OO language side, the protocol concept has always been relied on implicitly, even though the concept often wasn't explicitly identified and named.

For the record: I created the Scala department because of the "current interest", not beacuse I have a strong opinion regarding its "unique position".

I wasn't trying to suggest that Nemerle should be in the SpotLight section, just that they are similiar in many aspects. I think Scala is great and I'm glad its getting attention. I think forms of both languages are what will be the next step in "mainstream" programming.

You can be sure of that. If C# 3.0 is going to be as promised, Scala and C# won't be that different on the functional programming side.