Semi-rejection

Onward has rejected my paper, but invites me to cut it in half and resubmit it. I feel like withdrawing the paper, but will probably swallow my pride.

Dear Jonathan

Thank you for your submission to Onward! and congratulations because your paper “Coherent Reaction” has been conditionally accepted in the short (8 pages) paper category! Please consider the reviewer comments below, and more details will follow shortly.

*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=

First reviewer’s review:

>>> Summary of the submission < << The paper proposes a new programming style in which dependencies between variables are set up through the evaluation of functions such that future changes to variables propagate values. The programming style combines some of the features of both imperative and functional programming. >>> Evaluation < << I enjoyed reading this paper. It offers some very interesting ideas about a programming language/paradigm for interactive systems where data is exchanged between models and views, and behavior and structure are very dynamic. The examples are well-chosen and develop through the paper, making the concepts understandable and providing good motivation. I particularly like the challenge problem introduced at the end which really explains why these sorts of programs are so difficult. I only have a few minor suggestions on the text: Sec. 2.3: "order will found", my dictionary suggests "cannot" is preferred to "can not" I didn't understand line 96: do=>{tasklist < <}. A little more explanation would help. There's not much discussion of implementation and overhead. I do not think it is necessary, but want to note that the reader has to take it on faith that the bookkeeping of dependencies between variables can be managed reasonably. This is one of the attractions of imperative updates: it is usually fast and compact to code explicit instructions for propagating value changes, but automating this by recording dependencies often results in rather baroque data structures that are essentially interpreted at runtime to propagate values. Of course, the argument in the paper is that imperative updates are often too complex for developers to write correctly. *=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=* Second reviewer's review: >>> Summary of the submission < << Introduces a new "R-brain" programming language, Coherence, and underlying concepts of change-driven computation that purports to coordinate side effects in the use of programming languages. >>> Evaluation < << This is an interesting paper -- quite conversational and intuitive for a language paper but maybe that is appropriate for introducing a R-brain language. Is this the debut of Coherence? or is there a more formal introduction of the language written somewhere? The language itself seems a bit self-serving -- it seems to be grounded in the objective to address relatively tactical concerns of the programmer and not deep needs to communicate with the medium to solve problems. Coordinating side effects just doesn't seem like that grand a motivation to invent a language. However, the notion of coherence as a model is intellectually stimulating and the possibility of a R-brain language a good proposition for an Onward! talk. *=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=* Third reviewer's review: >>> Summary of the submission < << The paper presents a computational paradigm called "coherent reaction". Computation is viewed as the maintenance of a consistent tree structure, the state space, where changes in input lead to reaction chains that change the tree's state, which then lead to a second wave of derivations, changing the tree again. >>> Evaluation <<< I weakly recommend to accept the paper. I like the paper but view it more as a curiosity. The motivation, of programmers falling over their own feet trying to keep dependencies in order, is not a strong motivation for a new paradigm. Basically, you are addressing a practical, not a conceptual problem. Every programmer solves this problem every day. Better support for that is desirable, but doesn't really motivate a whole new language. As a point of comparison, the motivation for OO (Simula tradition) was to reduce conceptual application complexity by bringing the programming language close to modeling the real world. Your motivation is a some technical complexity issue that a user wouldn't really care about. There is a boatload of questions that you partially address but don't solve yourself. What about predictability of response time? What about programming issues like your "random convention" on using the first argument when adjusting reactions. But I guess for a first Onward! paper this presentation is fine. I don't understand your complaints about other languages needing libraries. You don't? How do language features replace libraries. Please elaborate. In a similar vein, for a language definition, I would have expected a more formal definition of syntax and semantics. No need for that? Does it exist? Some technical report? It would help alleviate the feeling of some hand-waving going on in your paper. I recommend you discuss the relationship with transaction processing in more detail. In particular the ACID properties seem to apply to your paradigm yet you don't mention it at all. Some of this looks awfully similar to Prolog and related logic programming. You don't discuss this in your related work section. *=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*

13 Replies to “Semi-rejection”

  1. @The motivation, of programmers falling over their own feet trying to keep dependencies in order, is not a strong motivation for a new paradigm. Basically, you are addressing a practical, not a conceptual problem.

    I was laughing out loud at this for a good 5 minutes.

    I don’t even know what it means.

    Dear Oliver Heaviside: “Your modeling of naval ships using your ‘calculi’ has been rejected because it solves real-world engineering problems we don’t have solutions for today. Please be aware we use balsa wood models instead, and that is all we need at a theoretical level.”

    @I don’t understand your complaints about other languages needing libraries. You don’t? How do language features replace libraries. Please elaborate.

    Isn’t this simple to understand? Is a reasonable reply to such a pedantic question to copy and paste Greenspun’s Tenth Law?

  2. Don’t withdraw, please. The only ones suffering would be us programmers.

    I agree with one thing, though: The arbitrary first argument convention feels a bit lacking in elegance. Perhaps comment on why you think it’s sufficient.

    And yeah, the third reviewer is hilarious.

  3. I agree with Erez. First, strip out all the quotes in your paper. Then shrink down the figures.

    Although I don’t fully understand how committee recommendations work, my guess is you were picked to cut your paper short, presumably because they felt your points could be condensed into a shorter format. 8 pages is a tight squeeze, though. You could definitely get down to 11 by making pictures smaller and eliminating those quotes. If you need the help of a fierce editor, let me know. He will cost money, but he can pick up domain specific vocabularies lightning fast (he is a chemist), has a way with words, and operates quickly.

  4. Dear Jonathan,

    please get over you pride and try the very best for a short paper version. I think your ideas are worth getting spread. Don’t miss the opportunity!

    Cheers,

    Dominikus

  5. >The motivation, of programmers falling over their own feet trying to keep dependencies in >order, is not a strong motivation for a new paradigm. Basically, you are addressing a >practical, not a conceptual problem. Every programmer solves this problem every
    >day. Better support for that is desirable, but doesn’t really motivate a whole new language.
    Yes, why would we ever ever want to solve practical problems that we deal with every day. Remarkable. Thanks for publishing it through your blog. I guess you predicted this nicely with your previous post about if smalltalk were invented today.

  6. Is there anything to be said about Software Transactional Memory (esp. Haskell STM in GHC) under Related Work?

    1. Yes, and I did, but obviously not clearly enough as one of the reviewers didn’t notice it either. Transactions are about making a series of changes look atomic to the outside. But they still look serial on the inside. I am trying to make them atomic on the inside.

  7. In section 2, I found myself wondering whether race conditions could arise due to the non-uniqueness of coherent execution orderings. I think the restriction that each field can change at most once (sec. 2.4) may prevent races in simple cases, but if there are arbitrary computations involved, then I would guess that there are no guarantees. Perhaps you can address this question in the revision.

    Also, even if a computation is functionally deterministic, what about performance? Could some orderings execute more slowly than others?

    1. Steve, Coherence uses a metaphor similar to Jabber or even object state machines from real-time embedded systems, where the objects support indeterminate time metaphor. In both situations, if you need to divide up your state machine to prevent race conditions, then you do so. Jonathan’s biggest implementation challenge, imho, is the fact he is basically dynamically configuring these state machines for you with his language’s compiler/environment.

      The other form of non-determinism is stable evaluation of terms. Within a given field update, Jonathan should definitely guarantee left-to-right order of evaluation like the C# language and other similar languages… especially for single/double ops

      Jonathan: i c what u did there 😉 semi is actually not different from half, though… they’ve both 1/2 fractions, just one sounds softer! You were quarter rejected! 😉

    2. There are no race conditions, because everything happens simultaneously, as far as can be observed. But some sort of normalization or confluence theorem is needed to guarantee that the coherence algorithm is deterministic.

  8. With derivation you just compute a value based on other values. This is like FRP. But with reaction you compute a value *and* you can change other values.

    If you have

    x = f(y)

    then if you change y you compute a new x, but if you change x the reaction presumably computes a new y *and* potentially executes some other code. Why did you put in this asymmetry?

    Why didn’t you go for the symmetric route and use relations R(x,y) that update x if y changes and y if x changes, and can update other state when x changes but also when y changes?

    1. Good question, that should probably go into an FAQ. Because symmetric constraints can’t easily express arbitrary reactions of the sort that typical apps need. Here is a trivial one: count the number of times a button is pressed. There is a reason we don’t all program in Prolog.

      1. What about trap-door functions?
        This leads to another interesting point-of-view: in the MVC-paradigm, it is possible to make some values of a Model read-only. In Java, for example, this is solved by not providing a (public) setter method.

        How would you adress this, in Coherent?

Comments are closed.