The first season of Saturday Night Live had a great skit featuring Gilda Radner, Dan Aykroyd , and Chevy Chase arguing about new Shimmer(i):
Gilda: “New Shimmer is a floor wax.”
Dan: “No, new Shimmer is a dessert topping.”
Gilda: “It’s a floor wax!”
Dan: “It’s a desert topping!”
Gilda: “It’s a floor wax, I’m telling you!”
Dan: “It’s a desert topping, you cow!”
Chevy: “Hey, hey, hey, calm down, you two. New Shimmer is both a floor wax and a dessert topping!”

I often get involved in a similar debate about SlickEdit–not about whether it is a floor wax or dessert topping–but whether it is an editor or an Integrated Development Environment (IDE). To answer this we need to examine a brief history of programming and the differences between editors and IDEs.

A Brief History of Programming
The first evidence we have of man as programmer lies in the cave paintings in France. Some would have you believe that these are depictions recording daily prehistoric life. If you look more closely it becomes clear that these are really the first known examples of a written program.

The programming language is symbolic with a confusing syntax. What, today, we would write simply as:

requires many more figures in this primitive programming language. Of course, there were no computers back then, so all programs had to be hand executed. This could explain why most of the programs were about hunting and dancing. These early cave programs were written with bits of charcoal and pigments made from plant extracts. Editing tools were utterly lacking.

Another prominent example of early programming is seen in Egypt during the reign of the pharaohs. While some hieroglyphs may, indeed, be a form of writing, some we now know were early programs. This is particularly true of the large obelisks carved by the Egyptians. These were intended to be inserted into a large, obelisk-shaped reader. Unfortunately, no examples of these early peripherals still exist. As with many stone computers, they were disassembled and reconfigured into items more practical in those times, such as homes, restaurants, and parking garages.

The Egyptians’ programming language, called Osiris (later replaced by Osiris++), uses several abstract symbols that are combined to represent a larger set of programming concepts. In fact, the Egyptians were the first to introduce the concept of the variable, as seen in this example:

Though no interpreters from that time still exists, it’s largely believed that this statement translates into:

Again, the Egyptians had little in the way of editing tools. Programs were typically written with a hammer and chisel, making undo a very time consuming operation. They did, however, introduce the earliest use of whiteboards in the form of clay tablets, which allowed them to prototype code in a more forgiving form.

There isn’t time for a comprehensive history of programming, so we’ll have to skip over the early Greek and Roman programmers, who used Scroll 1.0 to write their programs, and frontier programmers in the early American west, who whittled their programs out of wood. We’ll skip past systems where you toggled programs into the front panel in binary and those using paper tape or punch cards.

The modern era of programming began in 19-mumble-mumble with the advent of the teletype. With these systems you had access to your full program and could readily extend and modify it. Editing was done a line at a time, so these editors were called “line editors”. You would print a range of lines, then type a command to insert or alter a line.

Teletypes were just an evolutionary bridge to the console, early CRT systems that displayed your code electronically. With consoles, the first visual editors were created. These editors displayed a page of code and allowed you to move a cursor within the file. Editing could be done simply by positioning the cursor and inserting or overwriting characters.

Contemporary editors share many characteristics with these early editors. They have added features like syntax highlighting, Graphical User Interfaces, window management, and a host of other features, but the process of writing code is fundamentally the same. Typically, these editors are file-oriented. You open a file, make changes, and save the file. All other activities are performed by programs or utilities launched from a command line or shell.

Integrated Development Environments group the related development activities into a single…well…integrated development environment. This is generally considered to be more convenient because it allows previously separate utilities to interact.

An IDE generally has 4 main components:

1. An editor—something providing the heretofore described ability to write code.
2. A project/build system—something that knows about the set of files in your project and allows you to launch a build on these files.
3. A compiler or interpreter—that allows you to build and execute your program.
4. A debugger—that allows you to step through your code and examine values.

Typically, an IDE will also provide a number of code/object browsers, integration with source control tools, and other utilities related to programming.

Interaction between the editor and the other components in the IDE provides key points of efficiency not available using standalone editors:

• The project/build system provides the knowledge of the available files and symbols in the program. Using this information you can browse to open files and use powerful completions while typing. This saves keystrokes, prevents wasted time looking up functions and methods, and reduces the number of compile errors.
• Integration with the compiler allows an IDE to launch a build and gather the results of the build. Programmers can quickly step through the errors and navigate to the source code for that error. With a standalone editor, you must manually open files and execute an operation to go to the specified line.
• Integration with the debugger allows you to set breakpoints from within the editor and view the code in the editor as you step through the code. Though similar capabilities are available in standalone debuggers, the code will be displayed differently, often without or with different color coding (sometimes called syntax highlighting). Once you are used to reading code in color, any alternate presentation slows your comprehension.

Different Strokes for Different Folks?
So, obviously, the IDE has completely supplanted the visual editor, right? No, for a number of reasons some users still prefer to use editors rather than IDEs. Emacs and vi (and their descendents) are the two most common examples of these.

One reason some people prefer a standalone editor is that IDEs tend to be very GUI-oriented, providing graphical mechanisms to launch operations. Standalone editors tend to be command-oriented, providing comprehensive key bindings to initiate operations. Using commands and key bindings is a big boost to programming efficiency, compared to the time lost grabbing the mouse and selecting things.

The editors in IDEs are often less powerful than the standalone editors. When all you do is write an editor, you can focus on the kind of power programmer operations that really improve programming efficiency. Developers of IDEs have to split their time between the editor and all of the other elements in the environment.

The choice of platform also makes a difference. Use of standalone editors is far more common on UNIX and Linux systems than on MS Windows or the Apple Macintosh. UNIX and Linux users are typically more comfortable writing scripts to automate builds and process results. They see the OS as the integrated environment.

Even with these reasons, users of standalone editors are missing out on those key points of efficiency that come with an IDE. That’s why the descendents of standalone editors, like Vim and GNU Emacs, have been adding more of those capabilities.

So What the Heck is SlickEdit?
SlickEdit looks and works like an IDE, but we call ourselves an editor. This is because we don’t include a compiler or a debugger with SlickEdit. It’s also because we place our emphasis on the editor. SlickEdit is a command-oriented, keyboard-centric editor. In fact, SlickEdit began as a powerful visual editor that grew to include the most essential IDE capabilities.

Though we don’t include a compiler and a debugger(iii), we work with commonly available compilers and debuggers. If you have installed the GNU C/C++ tool chain, a Java JDK, or Microsoft Visual Studio, then SlickEdit works like an IDE, providing the key integrations described previously. SlickEdit detects the presence of these tools and interacts with them inside the SlickEdit environment(ii).

So, is SlickEdit a great editor that works like an IDE, or is it an IDE with a great editor? Like the Shimmer product in the SNL skit, SlickEdit is both.

————————————————————-
i: http://snltranscripts.jt.org/75/75ishimmer.phtml
ii: SlickEdit launches the Visual Studio debugger in a separate window.
iii: SlickEdit does include a copy of GDB to insure compatibility.