CS846 Paper Review Form - Winter 2012 Reviewer: Tommy Carpenter Paper Title: Programming Pearls: Little Languages Author(s): John Bentley 1) Is the paper technically correct? [x] Yes [ ] Mostly (minor flaws, but mostly solid) [ ] No 2) Originality [ ] Very good (very novel, trailblazing work) [x] Good [ ] Marginal (very incremental) [ ] Poor (little or nothing that is new) 3) Technical Depth [x] Very good (comparable to best conference papers) [ ] Good (comparable to typical conference papers) [ ] Marginal depth [ ] Little or no depth 4) Impact/Significance [ ] Very significant [x] Significant [ ] Marginal significance. [ ] Little or no significance. 5) Presentation [x] Very well written [ ] Generally well written [ ] Readable [ ] Needs considerable work [ ] Unacceptably bad 6) Overall Rating [ ] Strong accept (award quality) [x] Accept (high quality - would argue for acceptance) [ ] Weak Accept (borderline, but lean towards acceptance) [ ] Weak Reject (not sure why this paper was published) 7) Summary of the paper's main contribution and rationale for your recommendation. (1-2 paragraphs) This paper explains the concept of "little languages". Little languages are small programming languages used to convert user-friendly "input code" into code readable by more complex functions that are difficult to interface with directly. They can be seen as preprocessors that process the easy-to-write code into code that is actually used by the program. The author does not invent the concept of little languages, but rather brings to light that we use them frequently without knowing it, and that if we think more along the lines of little languages, programs can be designed better. The paper gives an insightful overview, but does not present much new research, hence I chose accept over strong accept. I think I figured out why this paper is being presented in this course. Little languages were one of the first (this paper was written before I was even born) constructs to allow programmers to "model" the input to more complex programs. The idea is that we can write a model of the input to a complex program that can be used as an interface. We can then feed easy to write code into the model, and the model (the little language) can convert it into the input of the complex function. A perfect example that I use frequently came to mind: AMPL. Researchers who preform a lot of optimization tend to use optimization solvers such as ILOG CPLEX or Gurobi. These solvers are a nightmare to deal with directly; programming for them is very painful. AMPL is a tiny language that allows users to specify optimization problems in a readable format that you would expect in a textbook formulation of a problem (minimize X subject to Y...), and it converts this easy to read input into the bizarre language CPLEX understands. I now (after reading this paper) think of AMPL as a tiny language that models inputs to more complex optimization solvers, and I hadn't thought of it that way before. 8) List 1-3 strengths of the paper. (1-2 sentences each, identified as S1, S2, S3.) S1: This paper does an excellent job in describing how common little languages are, even though we may not have thought of them before. Even the linux make command used extensively in modern development can be seen as a model or abstraction of the compilation and linking process; I had never thought of it in this respect before. S2: The author creates several informative little languages just for the sake of explaining the concept in the paper. For example, the concept of pseudocolumns was helpful: the author explains how he came up with this little language and how it helped solved the problem at hand. 9) List 1-3 weaknesses of the paper (1-2 sentences each, identified as W1, W2, W3.) Because this paper is not presenting new research I do not have any problems with the paper; there is no research to criticize. It is simply a helpful survey of a topic.