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.

Dreamweaver was my first editor and back then the WISYWIG philosophy (what you see is what you get) seemed convenient to me. I could type the code and the integrated browser visualized it. The relatively fast feedback loop without the need to test things in a real browser made the application feel almost self-sufficient. The results were somewhat inconsistent with those of the real browser though, which didn't eliminate the need to test in the latter as well. Many actions that generated code required clicks on buttons and dialogs, but this didn't seem slow to me, partially because I knew no better way. Everytime I wanted a rollover effect, Dreamweaver inserted the famous swap_(something) functions and I couldn't understand neither the meaning of the individual letters I saw nor why they were needed.

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.

Gvim or the GUI version of Vim is a very powerful editor, which helped when I needed more control. The nice thing is that it is cross-platform and I have been able to use it on both Windows and Linux. It can run even on very slow machines with limited amount of free resources. The bad news is that it speaks its own language, that can be hard to learn, even when it is logical most of the time. To make things more complicated, Vim has multiple modes, and in each mode each key can have a different function. In other words, the editor distinguishes between normal typing and working on various pieces of the file (higher level). This will “make you think”, which by definition is a bad design. Learning Vim takes a lot of time and effort, which aren't always justified, especially when you want to change just a couple of things. With Vim you'll need to spend more time on learning the editor commands than you will have to concentrate on your code. Vim has thousands of pages of documentation and even the most motivated person will need a lot of time to get the most out of them. However, I still use it very frequently, mainly for reading code. The powerful NERDTree file manager plugin, some configuration to disable interface elements, a nice color scheme and font allow you to feel very comfortable about opening and closing files, since all it takes is a couple of key presses. I have not found any other editor that allows “peeking” into multiple files in a simpler way (great for exploring large libraries). Searching in the current file with the “/” key highlights all occurrences of the word in the file in a very visible way. The editor has horizontal and vertical splits (adjustable to be of equal size) and you can use as many as you want. This allows you to have multiple open files on your screen that you can then “visit” with your cursor and edit frequently. You could have an HTML, CSS, JavaScript and PHP files open and visible and switch with a single keystroke between them (the last cursor position is automatically restored). Vim treats your work like data that it stores in a log file. This allows the editor to return you to the state of your file that it was 3 hours ago—another powerful feature. But some functions of Vim may not be questioned enough. For instance, the dot key (“.”) is used to repeat the last operation. If you copy a <li> tag inside an unordered list in HTML, you might think that using the dot ten more times would be fine, but this would easily lead to duplicate code (even with unique <li> tags). To make it more maintainable, it would be much better to have a PHP loop to generate all the tags. The more powerful a feature is, the more easily it is to be misused. Another assumption is that our index fingers shouldn't leave the F and J keys while typing for reasons of efficiency. This is why some people claim that the arrow keys to move within the file are too far and therefore need to be disabled in favor of the Vim-specific keys for cursor movement h,j,k and l. At the same time, some people have nothing against reaching for the Esc key any time they want to switch the editor to a different mode. I find this strange and somewhat controversial. Like every other application, Vim also works in a context. If we take a look at the mojority of our existing software today, seeing which shortcuts most programs agree to use for the same tasks, we will see that it is Vim that is inconsistent. If possible, it is better not to convert a change in technology into people's problem.

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.

Komodo Edit is becoming better and better. I remember when it was so slow, that I immediately uninstalled it. However the situation has improved and today it is reasonably fast, has a good amount of options and is perhaps one of the most friendly editors for new Python programmers. The options are well organized and it is clear what they do. You can assign a key to start the console automatically, even if this doesn't seem to be possible initially. Autocomplete works well and fast. There is a minimap like in Sublime Text that lets you quickly jump to a different part of the file. This comes at the cost of decreased performance while scrolling. The file manager is convenient but it is more usable through a mouse than through a keyboard. If you have opened the file through the keyboard, there is no easy way I know of in which you can return and open another one. Some slight inconvenience is the decision to use two different shortcuts for comment and uncomment, which can be error prone. But Komodo Edit definitely deserves a closer look.

WingIDE is also getting more popular. It offers enough features to be useful and not too many to be useless. It can be freely customized, although it could be a bit more efficient in terms of using the available screen space. Compared with Komodo, you don't need to save the file in order to execute it with the changes, which is a very nice detail. Its console isn't among the fastest ones, so if you have to print too much data in order to explore it, you may come into problems. After printing the first 20-25 thousand numbers, the console became especially slow in my test. Komodo has a slightly faster results rendering, which can become important when we consider that Python is mainly used to seek for patterns in large amounts of data. In terms of RAM consumption I have observed the following: WingIDE < Komodo Edit < PyCharm.

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.

Another alternative for Python programmers is PyScripter, which is a nice little program that seems a bit dull and unimpressive on the surface, but is actually quite powerful and configurable. Some people claim that it is a good alternative to Spyder, but I don't think that the two can be compared. You can choose the shortcuts with which you want to run the program or clear the console. You can organize the layout as you want in a space-efficient way. The console seems to be able to handle a lot of data gracefully and without excessive slowdown, which is very important in data exploration. The numbers until 100000 were printed in around 4 seconds, which is really impressive (although it is likely that CPU cycles are wasted only on the visible part of the data as it should be). Random scrolling within the results took around 2 seconds rendering time on a relatively slow single-core CPU. This means that PyScripter can be a good choice for people in need to explore lots of data.

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.