Comparing Breezy to a traditional parallel debugger of high-performance applications such as gdb or dbx-like debuggers helps illustrate its purpose. Breezy operates one layer below a debugger. A debugger does not provide a programmable interface. Since Breezy makes the parallel program accessible to the client through an API, it is much more flexible than a debugger. In fact, the first use of Breezy was in a simple parallel debugger. The implementation was trivial, basically a GUI built on top of the Breezy API.
It also differs from a debugger in that it provides different functionality. It is specifically geared toward parallel data. Thus, only data of this type is known and can be access using Breezy, whereas a debugger keeps track of all data. Breezy streamlines extraction of parallel data and allows interesting interactions with that data.
Breezy also differs from most parallel debuggers in philosophy. Debuggers typically deal with symbol tables and pointers to all the data on each node or thread of execution. Thus, for each thread, a debugger window appears to address the variables in that thread. Breezy accesses data using the language. The philosophy of Breezy is to use the language constructs that exist already to get to parallel data. A single thread using these language-level constructs can access data from all other threads, just as any thread in the program itself would access data from other threads. This is how a single point of control is maintained, while allowing access to data on all nodes.