Lambda the Ultimate

inactiveTopic The Nice Programming Language
started 5/10/2002; 1:17:12 PM - last post 6/5/2002; 8:44:19 AM
Bryn Keller - The Nice Programming Language  blueArrow
5/10/2002; 1:17:12 PM (reads: 2664, responses: 10)
The Nice Programming Language
(via Frank)
Nice is a new object-oriented programming language based on Java. It incorporates features from functional programming, and puts into practice state-of-the-art results from academic research. This results in more expressivity, modularity and safety.

Since we're talking about multimethods lately - Nice adds multimethods, parametric polymorphism, first-class functions, and an MLish type system to Java. Allows easy interop with Java (though it's harder to use Nice from Java than Java from Nice).
Posted to object-functional by Bryn Keller on 5/10/02; 1:18:45 PM

Ehud Lamm - Re: The Nice Programming Language  blueArrow
5/10/2002; 2:34:16 PM (reads: 1880, responses: 1)
Looks quite interesting!

I will have to look more closely at the abstract interfaces work.

I hope that the future version supporting DbC (see roadmap) will make use the recent work on sound contracts from Rice.

Adewale Oshineye - Re: The Nice Programming Language  blueArrow
5/10/2002; 2:45:31 PM (reads: 1958, responses: 0)
This is probably the most impressive home-grown language I've ever seen. I'm downloading it at the moment but from a language-evangelism point of view he's got a lot of things right.

There's a nice friendly web-site with most of the information that curious people will want to know. He still doesn't have a FAQ but he's identified the areas where this language would be useful, identified why people would want to use it, detailed the special features, provided an example of the code and (best of all) piggy-backed upon the feature-set of an existing popular language. [And it has an Emacs mode so there's no excuse for not trying it out.]

This is exactly the kind fo thing that helped C++ and Java get widespread. That and the hype merchants.

There does seem to be a proliferation of object-functional programming languages at the moment. The object-functional name has precedence I think and might be a better choice than a FOOPL category. See and Thomas Kuehne's PhD thesis ( and

The object-functional merger is one of my favourite features of Python and it seems to offer concrete benefits that are accessible to people who have no interest in the lambda calculus.

So apart from Python, Ruby and Nice what other object-functional programming languages are there? I'm not sure that Perl counts.

Chris Rathman - Re: The Nice Programming Language  blueArrow
5/11/2002; 8:53:26 AM (reads: 1848, responses: 1)
So apart from Python, Ruby and Nice what other object-functional programming languages are there?
Coming from the other direction, there's Oz/Mozart and O'Caml.

Ehud Lamm - Re: The Nice Programming Language  blueArrow
5/11/2002; 11:40:21 AM (reads: 1907, responses: 0)
Where exactly do you draw the line? Is any language that supports some functional constructs (e.g., Python) object-functional?

Maybe it would be more productive to consider only languages that either support well defined functional programming constructs (first class continuations...) or that provide an OOP framework based on immutable objects?

rev - Re: The Nice Programming Language  blueArrow
5/11/2002; 5:41:58 PM (reads: 1825, responses: 0)
If Ruby and Python pass as object-functional, Smalltalk is definitely in the same camp. Blocks are used everywhere. The Smalltalk version of (lambda (x y) (+ (* x 2) y)) is [ :x :y | (x * 2) + y ].

Daniel Bonniot - Re: The Nice Programming Language  blueArrow
5/31/2002; 12:04:05 PM (reads: 1673, responses: 3)
As the designer of Nice, I was glad to find some positive comments here. People who are interested are welcome to join in the Nice mailing-list, where future design of the language can be discussed.

In response to Ehud: could you give pointers to the recent work on DBC / sound contracts that you mention? As for abstract interfaces, I have a reseach article that has just been accepted for the Types in programming workshop. It will be available in a few weeks on the academic research page on the Nice website.

Ehud Lamm - Re: The Nice Programming Language  blueArrow
5/31/2002; 2:31:15 PM (reads: 1748, responses: 2)
Check the papers mentioned in this LtU post.

Daniel Bonniot - Re: The Nice Programming Language  blueArrow
6/3/2002; 1:15:09 AM (reads: 1803, responses: 1)
After reading the abstract of Contract Soundness for OOL: it seems that their concern with classical DBC is that the overriding of a method can change the contract of the original method in a way that breaks substituability. It is interesting to look at what happens with multi-methods.

In Nice, a multi-method is made of two complementary parts: the method declaration, and multiple implementations, possibly scattered in different files and packages. I think this is much cleaner that classical OO languages, where the two concepts are mixed, which create many problems. First, it raises questions like "can the new method change the arguments/return type, the exceptions thrown, the contract (our main issue here). Also, it is not possible, looking at a class definition, to know wether a method overrides a method in the parent or not (unless you add an 'override' keyword like in Object Pascal, which essentially amounts to reestablishing the distinction, but poorly (you still have to mention the types).

I think that the method declaration is the place where the specification (in the general sense) is established: there goes the type, the pre- and post-conditions, the method documentation (what does this method do). Then each implementation has the task to implement this contract in one case (dispatching on some arguments' classes). I think this nicely fits with the separation of specification and implementation, that is otherwise somewhat blurred.

Note that you can have precise specifications, like covariant return types, by using constrained polymorphic types in the method declaration. I would be interested to hear challenges about extending the contract depending on the implementation. Does it go beyond class invariant and assertions in the implementation code?

Ehud Lamm - Re: The Nice Programming Language  blueArrow
6/3/2002; 2:35:58 AM (reads: 1869, responses: 0)
I am not sure I follow your description, but one thing to keep in mind is that post-conditions can (and often do) contain (hidden) implementation details. The pre-condition should be verifiable by the client. The post-condition can establish properties that imply correct implementation, and are hidden from the outside user.

Daniel Bonniot - Re: The Nice Programming Language  blueArrow
6/5/2002; 8:44:19 AM (reads: 1640, responses: 0)
Post-conditions are part of the contract to the user. Ex:

class Collection<T> { void add(T elem) POST: this.size() = old.size() + 1; }

The ouside user knows this post-condition and can rely on it.

Now suppose I implement Collection as a linked list, and decide to add at the front. Then the fact that 'this.get(0) == elem' is true at the end of the method, but since it is not relevant to the user, it should be be 'assert'ed at the end of the code, rather that put in a postcondition. If I later change my implementation decisions, I will not need to change the spec (post-condition), which is good.

So my (tentative) claim is that the contract of a method should be declared only once. Implementations (or overriden versions) must of course follow the same contract, but do not need to refine it, since they are just different implementations of the same operation. Does that sound reasonable?