In terms of teaching curricula, I’d consider “advancing the state of the art” things like Scratch, Pyret, or Hedy. Hedy in particular is really interesting to me as it has multiple syntax levels for introducing ideas gradually.

I will proceed along the lines of discussion that I already introduced.

First, there is a basic metric that we can use for language quality, Kolmogorov complexity, with respect to some basket of chosen problems. In short, shorter programs are better. Additionally, we can use Shutt’s insight and compare the first and second derivatives of semantics for languages. The first derivative is like Kolmogorov complexity, while the second derivative suggests that not just shorter programs are valuable, but also shorter patterns for reusing subprograms and abstracting their usage.

Putting this together, my critique is simply that Quorum isn’t very good on either metric. My own pet language, Monte, is both terrible and also handily surpasses Quorum.

To the state of the art, first, note that identity and equality operators have been a deep philosophical topic in our field for a long time. Baker’s paper is from 1990. By 1996 or so, E had added an “equalizer” object which performs identity and equality comparisons, rather than delegating responsibility to individual classes. To quote from linked E documentation:

The traditional language specification would state “a’s behavior and b’s behavior must agree” (see for example the specification of “equals” in Java). However, when code is integrated from multiple sources, such specifications are incoherent. If “a” and “b” don’t agree, who’s at fault? In Java, once someone adds the following code to a system,

/**
 * A "more equal" class of objects
 */
public class OrwellPig {
    public boolean equals(Object other) {
        return true;
    }
    public int hashCode() {
        return 0;
    }
}

it is equally valid, from the Java spec, to say OrwellPig is buggy as it is to say OrwellPig is correct and the equals/hashCode behavior of all other classes is buggy. In a programming model intended to support the interaction of mutually suspicious code (which Java claims to be), such diffusion of responsibility is unacceptable.

This dire bug in the Java object model remains in Quorum’s model, and is the only present feature. Quorum’s oldest papers date to 2003, and its code dates to 2011; they did not need to copy this mistake from Java, but they chose to copy it anyway, from one decade to another.

The state of the art, more generally, has been to understand that objects are not just a ubiquitous pattern, but fully isomorphic to certain other models of programming. Both actors and microservices are isomorphic to a certain style of object-based design where objects do not treat each other as bags of bytes, but as private agents who consent to computation, and where objects do not merely call one another, but send messages to each other. In doing so, we are constantly unwinding our mistakes and removing overly-delegated abilities which ended up being too easy to misuse. For example, Java has low-level object serialization and marshalling, and many languages like Python and Ruby also implemented subsystems like this; however, today, we generally realize that objects need to be designed to be serialized, and also that plain-old-data formats like JSON are preferable to serialized-code formats like pickle.

I understand the desire to use evidence. I hope that you can see that there are more kinds of evidence than merely just randomized controlled tests which examine how well undergraduate students can read code; I am not just providing links so that folks will have reading material, but because I believe that these links point to evidence which supports my position. I have examined Quorum’s evidence. I think that only one of the cited papers actually uses Quorum. In that paper, Quorum is compared against popular and common languages of the day for readability by novices. Quoting this PDF of the paper:

Post-hoc Tukey HSD tests reveal that Quorum was rated as as statistically significantly more intuitive than Go (p<0.001), C++ (p<0.001), Perl (p<0.001), Python (p<0.001), Ruby (p<0.024), Smalltalk (p<0.001), PHP (p<0.001), and approached significance with Java(p=.055). The result holds generally for programmers as well, except that there was no statistical difference between C++, Java, and Quorum, for these users (an example of the interaction effect). Obviously, this does not mean that Quorum is more intuitive than these languages, but it does mean that novices in our sample certainly perceived it to be.

Yikes. So, with a manual adjustment for Ruby, Quorum gets to soar above the competition to be almost as readable as Java to neophytes. I would accept this study as finding some interesting facts about local maxima in the context of USA culture and language, but not as a deep statement about how our society ought to write code. And meanwhile, Quorum still isn’t very desirable. Would you write code in Quorum?