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.<\/p>\n
Dear Jonathan<\/p>\n
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.<\/p>\n
*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=<\/p>\n
First reviewer’s review:<\/p>\n
>>> Summary of the submission < <<\n\nThe 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.\n\n >>> Evaluation < <<\n\nI 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\nunderstandable 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.\n\nI only have a few minor suggestions on the text: Sec. 2.3: \"order will found\", my dictionary suggests \"cannot\" is preferred to \"can not\"\n\nI didn't understand line 96: do=>{tasklist < <}. A little more explanation would help.\n\nThere'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.\n\n*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*\n\nSecond reviewer's review:\n\n >>> Summary of the submission < <<\n\nIntroduces 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.\n\n >>> Evaluation < <<\n\nThis 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\nintroduction of the language written somewhere? \n\nThe 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.\n\nHowever, 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. \n\n*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*\n\nThird reviewer's review:\n\n >>> Summary of the submission < <<\n\nThe 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\ntree again.\n\n >>> Evaluation <<<\n\nI weakly recommend to accept the paper.\n\nI 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\nday. Better support for that is desirable, but doesn't really motivate a whole new language.\n\nAs 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.\n\nThere 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.\n\nI don't understand your complaints about other languages needing libraries. You don't? How do language features replace libraries. Please elaborate.\n\nIn 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.\n\nI 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.\n\nSome of this looks awfully similar to Prolog and related logic programming. You don't discuss this in your related work section.\n\n*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*\n\n\n<\/p>\n","protected":false},"excerpt":{"rendered":"
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.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-261","post","type-post","status-publish","format-standard","hentry","category-general"],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pfEnU-4d","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/posts\/261","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=261"}],"version-history":[{"count":8,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/posts\/261\/revisions"}],"predecessor-version":[{"id":269,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/posts\/261\/revisions\/269"}],"wp:attachment":[{"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=261"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=261"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=261"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}