A subjective comparison of some code editors

Editors are where we spend most of our time as designers and developers, so they need to support us in our tasks or they wouldn't be of much use. Currently we have many alternatives and it can be hard to choose one that works in our specific context. But this doesn't mean that it is wise to skip evaluating them when we will spend a dispropotionate amount of time with them. In addition, having to deal with an editor, learning how to configure it properly, memorizing its shortcuts and others should not distract us from the goal of delivering working code. Studying the capabilities of the editor is rarely more important than studying the properties that make our code great.

Sometimes, we may not have much choice. For instance, if everyone on a team uses Aptana, the decision has already been made and it will be much easier for a new person on the team to learn the existing platform than it will be for the team members to change their habits. But in general, companies need to be more open for new suggestions, ways of working and thinking about the work, because these can have greater impact than the productivity gains achieved by switching to a slightly more powerful tool.

All editors we could potentially use have their advantages and disadvantages. If someone claims that they use the best possible editor, we should check whether they aren't paid by the software makers. Any such statements must be seen with a healthy dose of skepticism. The interface is something very subjective, as are the design of the icons, their position and style, the organization of the various menus and submenus. In the same way that web designers have to deal with information architecture, GUI makers need to be able to explain why everything is where it is.

Once I felt slightly more comfortable with my code, and didn't break things as often as before, I decided to switch to PSPad. At the beginning I was quite impressed with its responsiveness. I also liked the ability to easily jump at different places in the code, which was a big time-saver. I appreciated the option to work with multiple files without experiencing performance issues. The nice splash screen made the program feel more personal. It served me well for a while, until I saw that new updates start to take longer and longer. At some point I started to look again for better alternatives.

My main editor today is Notepad++, where I have probably edited most of my code. By the standards of most editors I have tried, it is quite fast and responsive and it constantly gets better. It allows great flexibility in terms of style and font configuration, yet keeps its feature set relatively small. The ability to open very large files without crashing is a big plus, as is the speed of moving the cursor within a file. The first time I realized that after a crash my files were restored, I was happy for not losing any content. I could hide most menus to leave only the code visible, which meant that the interface could not longer distract me. Despite of this, the find function (Ctrl+F) shows a window over the code and when we move to the next match, it may suddenly appear below the window itself, in which case we need to move it to a different position in order to see anything. Initially, after opening the window, I always went to close it with the help of a mouse click, since this is what the interface suggested. Later I found that Esc does the same much faster. Sometimes long hours of editing in Notepad++ were tiring. Still, for writing code, Notepad++ is quite convenient.

Netbeans is a powerful IDE that supports HTML, CSS, PHP, C++ and Java and others. It requires a Java installation and can be quite resource-hungry. However, you can turn off some of the features you don't need (like the dynamic notifications as soon as a single keystroke is incomplete). If you look for a free IDE that has autocompletion support for PHP, it may still be useful for you. You can output the PHP result to the console, which allows you to inspect the code before you check it in the browser. Optionally, you can install a Python plugin for Python support that is still unofficial.

An even heavier alternative than Netbeans is PyCharm, which as its name suggests is directed towards Python programmers. I have found it to be too slow on my machine, even in its latest version. It does too many code checks, opening a new or exisiting project takes a while, generating skeletons and indexing are frequent operations that occur on the background, but eat a lot of CPU time. I suspect that this can be seen only if you have a less current PC, but it says a lot about the quality of the program. Simply pressing Enter and watching how the line numbers increase can make it slow. Pasting a couple of hundred lines of code is already a challenge for it. What I find good though is that it is more feature-rich compared to other IDEs. It has an option to install new or update the existing Python libraries, which despite being slow is more convenient over the alternative to install them manually. It seems that sometimes installs may fail if some new versions are incompatible with the installed Python version. Each installation is accompanied with skeleton generation and index building, so you have to be patient.

SublimeText is a very-lightweight (although not more so than Notepad++) editor that also allows you to build Python code (Notepad++ doesn't have this by default). It does this cleanly, showing only the result, not informing you each time of the version of the Python executable. Modifying the settings involves editing a user file, containing clear explanation of the various options. The package manager is also very easy to use and there are many packages from which to choose. Once you choose a package to install, everything is handled in a silent way, not bothering you with the details of the installation. By default, it comes with a dark theme and I am not a fan of dark themes, not only in editors, but also on websites as well. I like to keep my monitor brightness at a lower setting, so that I still stare at the screen after a couple of hours. This means that text on a black background that has insufficient contrast becomes unreadable for me. While good in general, Sublime Text doesn't always work without problems. I had multiple cases where the editor had memory leaks, became progressively slower and crashed. But I suspect that this is only a temporary problem, since its cause is well-known. Most people seem to be quite happy with Sublime Text.

Geany and Gedit are two other lightweight editors, suitable for simple editing tasks. The last time I checked Geany, it didn't have a normal Python console, but rendered the results in the MS-DOS prompt. While still possible to use for Python, it wouldn't be the best choice. Gedit seems fast, looks good and has nice file manager. But I wasn't able to trigger autocomplete and the brackets weren't automatically closed.

Spyder tends to be neglected, but it can be a good editor if properly configured. Unfortunately this isn't always an easy task—I succeeded on my third attempt mainly due to having no knowledge of the dependencies that the program required in order to run. The first time I installed it without any and then removed it; the second time I installed it with PyQT (which was bigger than I expected), but nothing happened. A more recent version of Spyder said during the install that it could work with PySide instead of PyQT, so I tried again and this time it worked. But I still have problems accessing the preferences of the program, where some module consistently failed to load. Anyway I was pleasantly surprised by the different conceptual thinking behind the program. It is fast enough and it is built for exploratory analysis in mind unlike some other programs on the list. Once you define and reshape a numpy array, you can click on it to get a 2D table of all its values and you can manipulate them in real time tabbing between them. However I was willing to see how changes in the data would reflect back into changes in the code, but this did not happen. Interactive manipulation and inspection of data could define our future as programmers, but not unless we create the necessary tools for them. What we can do is to: 1) manipulate the data through the variable explorer, 2) access it through the Python console (through the name of the variable), 3) manipulate it from there, 4) access the changed result again from within the variable explorer. But this could be a tedious process. Spyder has an integrated profiler, which can also be convenient if you want to optimize the speed of the code. By default the shell doesn't restart each time the code is executed, but the results are appended to those of the last session, which may cause performance issues in case of large result sets. Execution is also possible in an external console in which case it is cleared each time, but with the side effect of having much longer initialization times. To manually clear the console, you can use Ctrl+L, but not before it is already on focus. The object inspector is something like a search engine for documentation about various scientific methods. Overall Spyder is an interesting project and only time will show whether it can become more useful. My only criticism for now is that it doesn't feel as a cohesive whole, but as various components stitched together.

What I noticed is that the speed of rendering during scrolling can very often determine the success or failure of an editor. The same is valid for browsers, where slow rendering during scrolling can destroy the user experience. Noone wants to have websites that appear gradually on the screen. Windows has the option “show window contents while dragging” also indicating the importance of fast real-time rendering. PDF readers also benefit from fast rendering, because noone wants to see empty pages as feedback while they gradually move the slider in an attempt to find the right page. An important consideration then is how to render in a way which people perceive as fast. If the scrollbar moves too slowly, rendering would be easier since only small areas will need to be updated. But this also means that the user will have to wait considerably longer until they arrive at the position they want within the file. Another option is to scroll by page (for instance with PgDown, going from the start to the end of the file), which allows to render only the portions of the file not yet rendered. But this may leave the user with the impression that scrolling happens too fast now, when it is easy to forget what was on the previous page. The balance is somewhere in the middle, and it is in many cases still missing in our software. The creators of Vim have recognized this, which is why they allow you to scroll by (exactly) half a screen (Ctrl+U for up, Ctrl+D for down), which is fast but not too fast that you lose sense of where you are in the file. I have recently discovered something else about PDF readers. For instance, Foxit reader is quite good at rendering, but sometimes I want to scroll faster through the arrows on the keyboard, since the wheel on my mouse shows first signs of wear. Sumatra PDF on the other hand, despite having some issues with fast rendering during fast movements, has recognized this need and offers a more efficient way to move through the file – with Shift + up/down. As a result, it strikes a good balance between speed of scrolling and rendering speed. In a similar way, although we rarely get vocal about it, everything in editors seems to be not only about the interface, but about how fast we come to the content we are looking for. Hopefully you see now why the quality of our tools is so subjective.