For.example

Imagine an IDE where search were so fast that it became the sole means of navigation.

In such a system, one would not write //TODO but just this.todo() since browsing the callers of todo is so fast that is it faster than using a dedicated task view. The system might even be hidden to your Yahoogle query for “fast search in IDE” since in such a system search is so fast and ease-to-use that its ceases to be used as a verb. For example, the devs might speak of “browse callers” rather than “search callers” since no intermediate search step is between them and their need.

I can see some of my readers smile now :) …because…

There is such a system. It is little known since it predates the invention of today’s filesystems and has never made the transition to file based software development itself. It is Smalltalk, the old lady of dynamic programming languages.

In the IDE of Smalltalk “browse callers of” and “browse implements of” are the main means of navigation. Executing these actions opens–in the same instant–a new editor window with all callers (or implementers) of a given method. No spinning wheel, no tree list of search results, no browsing of results even, you are right there and can start editing.

NB: in fact, seasoned Smalltalk devs even omit “browse” and just say “senders’of” (in message-oriented languages such as Smalltalk and Ruby, objects don’t call methods but send each other messages) and “implementers’of” instead of a proper verbs.

For the alert reader: yes, graphical UIs predate hierarchical file systems. And even better, Smalltalk invented graphical windows. But we’ll stop the children’s games here. It does not matter who was first, but who makes the best out of it. And there, the winner is obvious.

The point I want to make is rather that there is a system out there with a 30-year head start in IDE search. So as researchers we can go and learn from the experience of that community, and then used what we learned to advance the state of current IDEs beyond it. Breakpoints, for example, are also just another method call in Smalltalk. You insert a call to #halt() where ever you want, and to view the list of current break points you browse all callers of halt. Again, no need for a dedicated view. As you see, search-driven development simplifies your tool set.

Of course, not all your navigation needs can be satisfied by hyperjumping. Sometimes you need to drill down from top-levels packages to methods. To do so Eclipse offers the code browsing perspective, which is however never used because the package explorer view offers the same drill-down capabilities without change of perspective. In Smalltalk we get a code browsing interface as well. In fact, Eclipse inherited that perspective from its predecessor VisualAge which was IBM’s prime Smalltalk IDE before they switched to Java.

So before I start to tell the story of how Eclipse’s elimination of the compilation step was inherited from VisualAge as well, lemme summarize this post.

• Search so fast that is disappears from the list of “verbs” in your IDE.
• Search so fast that it is called “browse code” instead.
• Search so fast that developers, for example, us method calls as TODO markers.
• Plus a drill-down interface for the remaining navigation needs that are not covered by hyperjumping.

The comparison with compilation is actually quite nice: With Eclipse “compile” and “build” ceased to be used as verbs in Java development. Now devs just execute code, done. This feature was brought to Java from Smalltalk. It would be awesome if we could achieve the same kind of “knowledge transfer” for IDE search.

I’d say that our job as providers of IDE search is only done when search ceases to be used as a verb in software development.

— that said, paper submission for SUITE is open until January 19, 2010.

The main focus of the SUITE workshop (co-located with ICSE) are search and software development. A frequently asked question is whether SUITE is limited to code search.

— SUITE is not limited to code search!

The general theme of SUITE is search-driven development. We consider search to be  a fundamental activity during software development. This includes (beside searching code, of course) search of external documents as well as search of runtime objects. Any search that may help when working with software.

Also, keep in mind that we are not only looking for solutions but also for studies of the problem space. So if you studied the search needs of developers, your results are as welcome as how to implement a new code search engine. The idea of SUITE is to explore all aspects of search in software development.

Lemme me give you an example that is not related to code only

• Assieme by Raphael Hoffmann etal is a meta-search engine for software documentation. Search results are presented as a browsable combination of API documentation, code examples and other information found on the web. Interestingly enough, code examples are not taken from source code repositories but from HTML pages. So you get a selection of examples that were considered worth to be put on the web by someone out there. All examples are compilable and thus ready to be paste in your program.

For further inspiration, you may find an exhaustive list of topics on the SUITE website—of course, submissions to the workshop are by no means limited to the topics covered there. If you have any position on software search, submission is open until Jan 19, 2010.

We are looking forward to hear your take on software search.

Be a rebel!

Reverse Engineering is an art, some say. Not any more: Felix Leder recently presented RE-Google, a search-driven plugin for IDA Pro, that queries Google code search (GSE) for terms found in disassembled executables.

Google code search is very valuable when trying to find algorithms or code excerpts that contain this information. Often the few results you see on one page can already tell you what the function might be doing.

This plugin enumerates all functions and extracts strings, constants (also called immediate values), and the names of imported functions. If there is sufficient data, a Google Code search is performed and the result is added to the IDA database as function comment. Reviewing these comments sometimes turns the analysis of the considered function unnecessary and saves time.

trunk/src/lib/third-party/jsSHA/src/sha.js
FileZilla3/tags/3.0.9/src/putty/sshsh512.c
trunk/v1/puzzle/vista/js/encriptar.js
StepMania-3.9-src/src/crypto/CryptSH512.cpp
coreutils-6.4/lib/sha512.c

It seems to be very likely that the considered function is SHA-512 based on the results shown above. And it is :)

Tools like Felix’s plugin are the future of software engineering. Search-driven tools are not only useful for reverse engineering but also for forward engineering. As more and more code is made available on the interwebs, we need new ways to integrate this vast information in IDEs.

Note: if your are interested in some more reverse engineering, please check out No Starch press’s “The IDA Pro Book: The Unofficial Guide to the World’s Most Popular Disassembler” by Chris Eagle. A great read!

What I particular like about RE-Google is that it uses a “push” model. Search happens as a background activity and results are presented to the user as comments in the dissembled source code. No need to “pull” by typing queries and waiting for results.

At last year’s SUITE workshop we had been discussing proactive search tools as well:

• Code Conjurer by Olivier Hummel etal is integrated into Eclipse. In proactive mode, Code Conjurer suggests methods as you are drawing UML diagrams. Code Conjurer can suggest the typical set of methods offered by components matching the partial interface defined by the user.
• Rascal by Frank McCarey etal is also integrated in Eclipse. It recommends how and when to call the methods of objects from common libraries such as Java Swing, based on an analysis of existing classes. It uses collaborative filtering, similar to that used in
  online shopping sites, to recommend products on the basis of those similar customers bought.
• Code Broker by Yunwen Ye, maybe on of the first search-driven development tools, is integrated in Emacs. While developers work on their source code, Code Broker offers coding suggestions on the basis of information collected from similar components in the repository.

All these tools have in common that they monitor the user’s activities while he is working, and then offer information they considers useful in that specific context.

We hope to see even more proactive search tools at the next SUITE workshop, or maybe even HCI studies about their usefulness compared to old-school reactive search.

That being said, SUITE 2010 is looking for submissions!

See ya in Cape Town next May ;)

Stumbled upon RE-Google via @duritong, thanks!