1. 2

Quorum is a programming language and development environment designed for teaching. It compiles to JVM bytecode and JavaScript. The development environment, libraries, and teaching materials place a special emphasis on accessibility for blind students, but this project is by no means limited to that niche. (Disclosure: I contributed to the accessibility of the UI toolkit.)

  1.  

  2. 2

    Quorum is divisive in the programming-language theory and design worlds. While Quorum appears to be usable as a language, it is excessively mediocre and does not advance the state of the art. On the other hand, there’s nothing especially wrong with mediocre languages.

    As an example of Quorum lagging behind the times, consider the object model. Quorum endows all objects with a very poor selection of methods, focusing on equality and ignoring everything else. Since objects can lie, objects must not be responsible for determining their own hash codes and equality; instead, some external global objects ought to be available for performing equality comparisons. This was known theoretically in the early 90s and by the late 90s, languages like E had demonstrated and fixed this set of flaws.

    There is no metaprogramming whatsoever. As a consequence, there are over 120 classes representing individual HTML tags, like this class for <abbr> tags. In Monte, a modern dialect of E, I represented every HTML tag polymorphically and using metaprogramming, in under 100 lines of code. My hands are tired; I do not have the strength to write out hundreds of modules in the Java tradition.

    On accessibility, Quorum would be very interesting if it were oriented exclusively around being accessible. Quotes on pages like this one suggest so:

    When it began, Quorum was used exclusively at schools for the blind or visually impaired.

    I did not know this before today, despite having examined Quorum multiple times. It is not a well-advertised fact. In the entire list of builtin libraries, I could only find one class that relates to this, and one tutorial lab. I wonder whether Quorum really is designed for the task of being accessible.

    It is not an accident or coincidence that Quorum has no usage whatsoever on Rosetta Code.

    1. 2

      I think I get your point; a new programming language doesn’t need to be cutting-edge, but whatever features it does support should be implemented in a reliable way. I also appreciate why the latter point is especially important in a language for beginners, since they’re (hopefully) trying to lay a strong conceptual foundation, and the language shouldn’t impede that. I haven’t had any involvement in the design of the Quorum language, so I don’t have any more to say on that subject.

      I think there are good reasons not to over-emphasize the accessibility angle. If Quorum were pigeonholed as the language for blind students, then it wouldn’t spread into mainstream classrooms. While schools for the blind do exist, and some of them use Quorum, most blind students, from elementary school up through university, are in mainstream classrooms. So if these students are to benefit from the accessibility of the Quorum environment and libraries, without being isolated from the rest of their class by using something different than the class as a whole, then Quorum needs to spread into mainstream classes, which it’s already doing IIUC. Now, it would be unreasonable to expect a mainstream teacher to use Quorum for the whole class just for the benefit of a blind student. But the hope, if not yet the reality, is that Quorum will be beneficial for all students.

      Also, if people perceive Quorum as the language for blind students (or blind programmers in general), then that gives them an overly limited view of what blind people can do. A blind programmer friend of mine expressed his concern about that possibility.

      As for the fact that Quorum isn’t on Rosetta Code, that merely means that it’s not interesting to language nerds. That doesn’t count for much IMO.

      1. 1

        What makes a language mediocre? The fact that it does not align with your views is a purely personal metric.

        What does advance the state of the art mean? A language that has some obscure construct that nobody has thought of yet?

        Quorum might be divisive because it is trying to use evidence to drive feature selection. I can see that being a problem for people involved in vanity research.

        1. 1

          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.

          1. 1

            What would advance the state of the art is people running experiments to show which features do what is claimed of them, and which don’t.

            Existing claims are based on ego, vanity and arm waving (there have been a few inconclusive studies).

            1. 1

              I believe the inventors of both Pyret (Shriram Krishnamurthi) and Hedy (Felienne Hermans) have done lots of quantitative research on software education.

              1. 1

                I was not previously aware of the Pyret/Shriram Krishnamurthi work.

                A quick scan of a dozen or so of his most recent experimental-looking papers finds they are essentially write-ups of student test results. Not experiments, as such. One was a survey (I treat surveys as fake research).

                Can you point me at the good experimental papers.

          2. 1

            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?

        Stories with similar links:

        1. The Quorum Programming Language via yumaikas 3 years ago | 5 points | 11 comments