[Grace-core] How Does Grace Compare with Java? [Was: Inheritance: what is it meant to be good for?]

Andrew P. Black black at cs.pdx.edu
Sat Jan 10 18:03:04 PST 2015


I’ve just added this page to the Wiki at https://projects.cecs.pdx.edu:8443/~black/NewOOL/index.cgi/wiki/CompareWithJava.  Please make corrections there, and also discuss there that discussion that is better conducted in-line.

  How Does Grace Compare with Java?
In an email on 10 December 2014, Marco Servetto wrote:

For the best of my understanding, the only really complex point in the programming language design space that Grace do not have, but all of Java/C#/C++ do have, is type-based method overloading.

Oh, yes, and there is only one supported numeric type, so no need for conversion/coercions here

This didn't seem right to me; surely Grace is a lot simpler than Java (and certainly than C# and C++, although I know those languages a lot less well). Here is my list of Java features that Grace does not have, motivated by Kim Bruce's GraceToJava? document, prepared for his students.

Type-based overloading.
Arity-based overloading.
Primitive data — int, boolean, char, byte, short, long, float, double.
Classes (as built-in non-objects).
Packages (as built-in non-objects).
Constructors (as distinct from methods) and new.
Object initializers ( code in a class enclosed in { and } )
import * — introduction of names invisibly.
Operations on variables, like x++ meaning x := x + 1.
Multiple numeric types (so that, for example, 3.0 and 3 are different).
Numeric literals with F and L.
Integer arithmetic defined to wrap.
== as a built-in operation on objects.
static variables.
static methods.
static initializers.
final.
private (which is much more complicated than most people realize, since it interacts with the type system).
C-style for loops.
switch statements.
Class-types.
Packages
Package-based visibility.
Arrays (as a special built-in construct with their own special syntax and type rules).
Required semicolons.
() in method requests that take no parameters.
public static void main(String[] args) necessary to run your code.
Object with "functional interfaces" treated as λ-expressions.
Of course, there are a few things that Grace has that are not in Java. We should be careful to justify all of these things; the typical justification is that they remove more complexity from most programs than they add to the Grace language definition.

String interpolations:  "the value of x is {x}." rather than "the value of x is " + x.toString + ".".
Class syntax as a way of defining objects.
Factory method syntax as a way of defining methods.
Implicit declaration of variables in patterns. (I'm not counting patters themselves as these could be considered just a library. But implicit declaration of variables in Patterns is a language feature, and one that I find mind-bendingly complex).
Blocks usable as patterns (as well as functions).
Inheritance from "fresh" objects and the special semantics of method requests after inherits.
There are also a few things that are just different in Grace and Java. I think that all of these differences are well-motivated.

Operators are method, not built-in features.
Control structures are methods, not built-in features.
Method visibility is based on objects, not on files, or packages or classes.
Types correspond to Java interfaces
Type conformance depends on an object's methods, not on the class from which it was created.
Type annotations are optional.
Blocks define λ-expressions (rather than using a special syntax).
Can we complete these lists? I think that they will be useful in describing and "selling" grace to our colleagues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20150110/00f8fac5/attachment.html>


More information about the Grace-core mailing list