The following review has been automatically generated by a program.
The goal is to make fun of certain reviews made by certain reviewers in certain conferences.
Do not use this in your real reviews.
Enjoy!
*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*
The
major problem with this paper is that there is nothing new here. A lot
of this has already been proposed before. Some examples that come to
mind are: Bajracharya's OOPSLA posters chair's welcome: Sourcerer: a
search engine for open source code supporting structure-based search,
Kunz's Fast detection of communication patterns in distributed
executions, Xie's Informal tool demonstrations: 3D visualization for
concept location in source code, Sillito's Empirical methods and
program understanding: Questions programmers ask during software
evolution tasks, Sriram's Special issue: AI in engineering, just to
name a few.
The paper talks about "...classes frequently used by
other classe...", but I haven't seen any discussion on that (whether in
the theoretical part of the paper nor in the validation part). It is
just mentioned. For this kind of work, this is _relevant_ how an
approach can deal with that.
Some of the well-known concepts
have been just renamed: "search" is nothing else than "scour, ||fan,
frisk, shake down"; "source" is "derivation, fount, fountain,
fountainhead, inception, mother, origin, provenance, provenience, root,
rootage, rootstock, spring, well, wellhead, wellspring, whence"; parts
of the approach have not even gotten a name.
The paper uses the
term "source code." Crista Lopes's sourcerer is a system for source
code search. The paper cannot use the same term and generate confusion
(in many dimensions). A simple google search would have helped with the
naming.
The techniques are explained at a rather shallow level.
No details. So, for example, what's the precise definition of "code"?
How is search related to code? The paper talks about information, but
why is that important? The role of "entity" in the approach is not
clear. When the paper gets to a bit more detail on these things, it
stops abruptly.
The paper does not provide enough details for the work to be reproducible.
The difference to Google code search facility is also not discussed.
I could not understand Fig 1; this kind of "visualization" is not effective (and also not intuitive).
In
general, I found the paper disappointing, hardly any technical details,
too many claims, not well described. I could not find convincing
scientific depth in the paper.