Re: But is it Object-Oriented?

>I believe that you can do that in SmallTalk and Objective C since they have
>"open classes." You can have open classes without multiple dispatch. Similarly,
>you can have a method nested inside of a class that doesn't dispatch on the
>class (static methods in Java and C++). So, whether methods are "contained" by a
>class or by a package is orthogonal to dispatch issues. But it seems like you
>can't have multiple dispatch without open classes. And, while a multi-method
>could in theory be nested inside a class (even one that it doesn't dispatch on),
>it seems to not make much sense to do so. 
>  
>
Right, there are two concepts: multiple-dispatch, and definition of 
(possibly mono)-methods outside classes ("open classes"). Smalltalk and 
Objective C might have the latter only (i'm not very familiar, but I 
heard that about Objective C). Java's static methods do not count, they 
do not do any dispatch, so they are not really methods.

>>BTW, what are their pros?
>>    
>>
>
>Apparently they are easier to understand
>
Couldn't this be for a very large part that class-based OO has been 
taught for 20 years? I was young in the 80's, just starting to get 
interested in programming, and I remember that in every second computer 
magazine there would be one article presenting this new beast that was 
OO. It was a pretty big overhaul of the existing conceptions of most 
programmers, and it look a lot of time and effort to get it mainstream.

It would be very interesting to have data about how easily beginner 
students learn a first paradigm, be it procedural, functional, 
class-based OO, multi-method OO, ...
If there are courageous and enthusiastic teachers out there willing to 
make an experience with teaching Nice, I would gladly support and hear 
about how it goes. It would make quite a lot of sense because you can 
learn many ideas (class hierarchies, single dispatch, multiple dispatch, 
anonymous functions and functional programming) in a single language, 
that are usually isolated in different languages.

> and presumably easier to implement.
>  
>
Right ;-)

>Combined with single inheritence they also ensure that there are no dispatch
>ambiguities like we have in Nice. 
>  
>
True. But since these ambiguities are detected at compile time, it's a 
small price to pay for the expressiveness. In fact, think about what 
would happen if you had to work-around the absence of multi-methods with 
manual dispatch: then the ambiguity will not be reported, the behaviour 
will be the result of an implementation detail. It's better to have the 
ambiguity reported and to conciously decide what is the right thing to do.

>>Yes. Fundamentally, I agree that Nice is based on a quite different form 
>>of OO (or different from class-based OO). The good part is that that 
>>form is more powerful; the bad part is that it's much less known, and so 
>>newcomers need to learn it. The whole question is: when and how?
>>    
>>
>
>Teach them methods before classes. If you think about "Hello World" in Nice you
>don't even have to know what a class is. Similarly, you can do fibonacci, gcd,
>rock-scissors-paper, ackerman, heapsort, etc. (almost all of the Novice Examples
>in wiki including many of the language shootout ones) without classes.
>Functional language tutorials often teach recursion and higher-order functions
>before records. But, you cannot do any of these without knowing about methods.
>That indicates to me that methods should be learned first.
>  
>
Very interesting.

>Furthermore, making a distinction between monomethods and multimethods is
>something better done in a language comparison paper than in the user manual.
>Just say "here is a method, here is how you specialize it on its parameter(s)." 
>  
>
Agreed, I think we should simply use the word method (don't we?).

>>My way to look at it is: multi-methods allow you to do everything that 
>>mono-methods do. So it's possible to "make them look like" mono-methods 
>>(that's the syntactic sugar), so that new users can feel at home and be 
>>able to write code very soon.
>>
>>Besides that, multi-methods are usable in other situations where, 
>>without them, you would need to work around the limitations of 
>>mono-methods (visitor pattern, static methods, manual dispatch, ...). 
>>When you get there, this is the time to learn the features that you need 
>>(declare a method outside a class, dispatch on several arguments).
>>    
>>
>
>That is the point I disagree with you on. The fact that one can make Nice look
>like Java is what has created the most confusion and started numerous debates
>including this one, the one about method lookup, do we even need interfaces,
>what does "private" mean, overloading/overriding syntax, etc. 
>
I think there is one fact which creates much confusion: if you write 
classes exactly like in Java, you will get overloading, and not 
overriding. This is definitely wrong. I've mentioned before the idea to 
"unify" overloading and overriding, which would solve this problem.

For private, your view is quite sound and quite be extended naturally. 
There are compilation units ("files"), and features can be visible only 
inside their unit if they are private. units are groups in packages, 
which hold the default visibility. public features are visible 
everywhere. (we would need to define this even if Nice didn't have this 
Java look, by the way)

>Basically, you are
>saying that you want people to be able to write programs in Nice without
>understanding the language, by assuming it is just like Java. 
>
I'm arguing it's not "not understanding the language", it's not 
understanding the _whole_ language (which is normal). That is, they 
might not know every way in which a method can be used, that does not 
mean they are wrong in what they know.

>But, I don't see
>the harm in asking them to learn a little first. And, I think Nice would be
>easier to learn without the syntactic suger. 
>
I believe you, but this must be a pretty personal point, depending a lot 
on where you come from.

>In particular, I don't think the
>manual should use it.
>  
>
See below.

>>I think it is fair to say that a multi-method is exactly what you get 
>>when you take mono-methods, and you add them the ability to dispatch on 
>>several arguments and to be declared outside classes. Maybe the 
>>documentation is not telling this story, and maybe it should.
>>    
>>
>
>I think this view does not belong in the language manual. Instead, it belongs in
>a seperate "how do I migrate from Java" manual. If somebody was migrating from
>ML then the "progressive" presentation would be useless to them; they would be
>better off starting with the pure view. I don't think that the language manual
>should refer to Java at all. I think an ML programmer should be able to learn
>Nice without knowing any Java first.
>  
>
Agreed, the user manual is not about a progressive presentation. It 
should present features exaustively, as a reference.

In addition to the manual, it would indeed be great to have several 
tutorials/introductions, targetting different audiences. Currently, the 
user manual might have this Java flavour because such info is also 
needed, and it is not presented elsewhere. The more we have of this kind 
of material, the more we can make sure that the manual is "neutral". 
It's a question of manpower. It you and/or others would like to write a 
tutorial targetting people familiar with functional languages, that 
would be a great contribution.

>To be honest, I don't think that knowing Java is really that much of a benefit
>to learning Nice anymore. It has diverged too much.
>  
>
There is a fair amount of interest around Nice. I don't think there 
would be half of it if the language was a traditional research language, 
with a brand new syntax and close to no libraries, however pure and 
clever that language may be.

>>Furthermore, I agree this is not the most direct definition. So it could 
>>be worth to also present the "pure" view too, and that would be most 
>>suitable for beginer programmers and people not familiar with 
>>class-based OO.
>>    
>>
>
>I agree both presentations are important but I think the "pure" view is what
>belongs in the language manual and the "progressive" view should go in a
>migration/interoperability manual.
>  
>
Agreed. If such documentation becomes available and parts of the manual 
become redundant, then we will be able to remove them.

>>Agreed. What about:
>>
>>Nice is a new programming language. It extends the ideas behind 
>>object-orientation in order to better support modular programming and 
>>static type safety. it also 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.
>>    
>>
>
>I agree that that sounds better but I don't think it describes the language as
>it is right now. 
>
Any proposal? I'm aware mine is not perfect, it's just that perfection 
is hard ;-)

>In particular, most of the support for modularity has not been
>designed or implemented yet.
>  
>
Well, you can already write the kind of modular code that only 
multi-methods allow. What is missing is enforcing visibility. That does 
not really prevent you from anything, although it does miss the benefit 
of being sure a feature is not used out of its scope.
So that's not a lie, but OK that's a half trugh ;-)

Visibility should not be very hard to implement, though. If somebody is 
considering helping out with the compiler, that might be a good way to 
get started.

Daniel



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click