To increase transparency, PeerJ operates a system of 'optional signed reviews and history'. This takes two forms: (1) peer reviewers are encouraged, but not required, to provide their names (if they do so, then their profile page records the articles they have reviewed), and (2) authors are given the option of reproducing their entire peer review history alongside their published article (in which case the complete peer review process is provided, including revisions, rebuttal letters and editor decision letters).
Thank you for your careful revision and incorporation of the helpful comments from reviewers.
Both reviewers found your paper compelling and of general interest. Both have also provided a number of comments that I believe will help improve the readability of your paper. Please consider them carefully as you revise your paper.
-line 52, the argument in the sentence "This often makes programs more verbose than would be convenient." is, in my opinion, less an issue that implementing the same solution in multiple languages, which LWBs solve nicely.
-I highly encourage the authors to include a timeline or table describing how long it took them to develop each piece of NYoSh (composable languages, language compilation modules, etc.). This is valuable information that other bioinformaticians would benefit from as they weight the benefits and drawbacks of using NYoSh and developing their own solutions in a LWB.
-lines 369-371, the justification referred to in this sentence needs to be unpacked and/or qualified: "Comparing the script in Figure 8 and the pure-Java source code equivalent in supplementary material provides a compelling justification for the design of concise domain specific languages." Clearly the script is going to be shorter—and likely easier to read—because it's using the Java libraries, while the Java implementation is not using any additional libraries and must implement/define everything (and is doing so in an automated way that may not optimize readability). The authors should be explicit about the advantages of the script vs. Java implementation.
-Sentence on line 38-39 does not make sense.
-It's very unusual for Figure 7 to be the first figure mentioned (line 161); this could be fixed by omitted reference to Figure 7 until later.
* "that support the script programmers"
-> it is not clear to me who exactly the target audience is.
what kinds of scripts are these?
* "analysis logic written in the BASH language
-> that is not the shell script bash thing, right?
* Usually, Language workbenches are abbreviated LWB.
* "creating several typesystem “checking rule”
-> 's' missing in "rules" at the end.
* "Micro-parsing Technique.
-> it is not clear why this is important and how it fits in here.
* Reading the Results section, it seems like BASH really is the
shell thing. Did that really originate from bioinformatics as you
say earlier? I didn't know that.
* "robust clinical data analysis pipelines with shell scripts
-> it is somehow a bit sad that shell scripts is the state of the art
for this kind of data analysis. I can clearly see why you would
want to develop something more advanced/robust.
* "reusable code is code that can be used, without modification, from
-> or from diff. parts in the same program.
* "Beyond the structure, reusable code needs ...
-> even more importantly, it has to have clear interfaces and contracts.
* Is there a reason why all figures are at the end? THat's a bit inconvenient
* "BaseLanguage provides most of the capabilities of Java 1.6
-> in fact, it has more than Java (closures, e.g.)
* "a specialization of the NYoSh language
-> I think you hadn't use "specialization" before, you used extension.
* "See material and methods for a brief description of MPS languages
-> should this be a footnote? Interrupts reading flow.
* " the same semantic than BASH at..."
-> "the same semantics as a BASH at..."
* The micro-parsing stuff is interesting. You could automate it further, by
having checking rules that automatically detect a mismatch between
AST and the textual string.
* The comparison between micro parsing and the multiline/richtext stuff isn't
quite to the point, because the important thing about the rich text stuff is
the ability to embed actual MPS program notes into free-flowing text.
* "developed along the years
-> "developed over the years
All text and materials provided via this peer-review history page are made available under a Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.