SlickEdit 2011 is an unusual release. Typically, a release contains a good number of new features that enhance your ability to edit source code. This year, the words “updated” and “enhancements” play more prominently in the list:

  • 64-bit Versions for Linux and Windows
  • Multithreading the Context Tagging Engine and Auto-Reload
  • Support for Ruby Debugging
  • Support for Git Version Control
  • Dynamic Debugger Enhancements
  • Updated Microsoft Visual Studio 2010 Support
  • Updated JUnit Support
  • SlickEdit License Manager

So what happened? Choosing what goes into a release is the toughest job for a product manager; there is never enough time to develop everything we’d like to get done in a given year. So we have to make hard choices.

We look at our customer base as a set of constituencies, each with different needs and change requests. Each language we support represents a different constituency with different needs, likewise for each platform. Fixing a tagging problem in C++ does little to help a Python programmer and vice versa. Some features, like Backup History, introduced in SlickEdit v9.0, are useful no matter what language or platform you are using.

Another way to divide constituents is into existing customers and new customers. Generally speaking, new features are considered more helpful in going after new customers, while bug fixes are aimed at existing customers. One consistent piece of feedback from existing customers is that they don’t really want new features; they just want the existing features to work better. In each release, we try to strike a balance between features to lure new customers and bug fixes for existing customers.

When we made the feature plan for this year, it became clear that there were parts of SlickEdit that really needed updating. As a product with a very long history—the first version of SlickEdit was released 23 years ago—we have seen some dramatic changes in the platforms we run on and the expectations of our customers.

In the early versions, resources were scarce so you needed to be as lean as possible, use as little memory and CPU as you can. This also makes your program very fast, which is one of our top goals. Now, a typical development machine has 4 cores and 4GB of memory or more. In this environment it’s frustrating to wait for an answer while the program is only using 25% of your available resources. That’s why the multithreading work was so important.

Don’t get me wrong. We’re not out to become a resource hog. We do believe that, for programmers, coding is the most important thing they are doing and that sufficient resources should be brought to bear.

As code bases grow, it’s even more important to have an editor, like SlickEdit, that knows the location and type of your symbols. Being able to generate that information efficiently and access it quickly is always our top priority. SlickEdit 2011 is a big step in giving you the fastest possible code navigation.