CS846 Paper Review Form - Winter 2012 Reviewer: Jia Liang Paper Title: Propramming pearls: little languages Author(s): Jon Bentley 1) Is the paper technically correct? [*] Yes [ ] Mostly (minor flaws, but mostly solid) [ ] No 2) Originality [ ] Very good (very novel, trailblazing work) [ ] Good [*] Marginal (very incremental) [ ] Poor (little or nothing that is new) 3) Technical Depth [ ] Very good (comparable to best conference papers) [ ] Good (comparable to typical conference papers) [*] Marginal depth [ ] Little or no depth 4) Impact/Significance [ ] Very significant [ ] Significant [ ] Marginal significance. [*] Little or no significance. 5) Presentation [ ] Very well written [*] Generally well written [ ] Readable [ ] Needs considerable work [ ] Unacceptably bad 6) Overall Rating [ ] Strong accept (award quality) [ ] 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) The paper discusses 'little' languages, primarily focusing on Brian Kernighan's PIC language for drawing lines and shapes. There are three obvious approaches to drawing pictures. The first is interactive, best for simple pictures. Subroutine libraries are most cost efficient for larger scale work. Little languages takes some advantages from the other approaches and is easy to integrate within a system. The output of a little language can be the input of another little language, simplifying the implementation and improving portability. Each layer adds expressiveness to solve the problems of the domain more elegantly. A little language should be as simple as possible. Add features when experience shows a need for them. The author lists the good properties of a little language: orthogonality, generality, parsimony, completeness, similarity, extensibility, openness. The paper was an interesting read but very light on depth. The sections covered a few 'little' languages but the author's definition of 'little' remains vague. The article is a crash course of a few selected languages and contributes little to the field. It is informative but not insightful. Although the writing was well organized and readable, I would not recommend it for others. 8) List 1-3 strengths of the paper. (1-2 sentences each, identified as S1, S2, S3.) S1. The examples of little languages were good: PIC, YACC, LEX, CHEM, Make. Each had a very obvious problem domain. S2. The author gave concrete criterias for designing a little language. S3. The CHEM example gave a real world situation of the need for a new language, and outlined the design process. 9) List 1-3 weaknesses of the paper (1-2 sentences each, identified as W1, W2, W3.) W1. Calling Unix Shell a little language is a bit of a stretch, devaluing the meaning of 'little'. W2. Does not cover the disadvantages of little languages, such as development, debugging, and maintenaince costs.