Text editors are a pleasure for developers. A good programmer uses the text editor as his main working tool. After all, programmers spend most of their day typing away code on text files.

That is why text editors are so important for a good programmer. And learning a new editor is like learning a new language, giving you a lot of possibilities on how to accomplish certain tasks.

That is the reason why I like to try new text editors from time to time, in order to see if they provide any useful features that I might be interested in adding to my toolbox.

One the latest editors that I tried out was wily. Wily is a relatively obscure editor, but it comes from the same tradition of ed, vi, and Sam. It is a version for UNIX of the acme editor, that was designed and implemented on plan9.

What is really different about wily and acme is that hey are text editors for programmers that are completely based on use of the mouse.

The Mouse and Programmers

Almost every programmer out there hates to use the mouse. This is an issue because most of us are faster using the keyboard, and the keyboard provides far more combinations of commands than the mouse.

Therefore, coming to the wily world is not as easy for a programmer as using other editors such as Vim.

Essentially Wily uses the mouse to activate a number of functions, such as running commands, searching, and of course, cutting and pasting.

While the idea is interesting in theory, it has the big drawback that it requires people to learn to use the mouse in ways that they are not used to do. For example, most user interfaces require users to click or double click in elements of the screen. On wily, however, one has sometimes to do “mouse chords” a sequence of left, right, and middle-button clicks that performs some action.

This is not only unusual, but it is also really painful. And the worse, in my opinion, is that there are several options that may be used to avoid doing these operations with the mouse.

The main reasoning for this behavior used by wily/acme users is that the mouse is the easiest way to select text in a GUI.

I agree that it may be an easy way, however it is not the best one. In vi, for example, there are at least two ways that are easier: using search or jumping to a specific line on the screen using the keyboard. And these are just two methods, there are many more available for Vim users.

For example, on wily one can search for the next selection using a middle click on the desired text. However, in Vim one can perform the same search using the * command, with is several times faster if you can touch type.

Another problem with wily is the limited set of features. The proponents of the software think that this is a strength, because the total amount of source code is small and easy to understand. However, there is no advantage is a code base that is easy to understand if you are not willing to extend it. It is the same as saying that you like to have a clear kitchen because it makes it easier to cook, and them refusing to cook because it is going to mess up the kitchen.

Therefore, my impression is that wily/acme is an interesting experiment and that some people would become used to it. However, I don’t think it provides anything really better, compared to other programmable editors such as Vim or Emacs. In fact, due to its views of software development, the writers are convinced that it is OK to offer much less features, without really providing a better alternative.

Hi, this is the 12th part of a series of posts on 30 tips to becoming a better developer. If you would like to keep up to date with the topics that I am covering, just check the main post.

Coding is a fun activity. But in the middle of creating interesting algorithms and user interfaces it is easy to lose track of the main context of the application we are writing. Getting the global picture, however, is not only important, it is essential to create a software product that really delivers what customers need.

The problem is that it is really easy to get side tracked while completing peripheral features that seem interesting for us, but are ultimately useless for clients. How many times have you spend a whole afternoon optimizing an obscure part of your code, or creating a more elegant class for something that is not all that important?

Although implementing the ideas you like most is a fun activity, it contributes little for the success of a software project. On the other hand, the results of getting side-tracked are not fun, and can cause major problems during the development of a large application.

Here are some tips to avoid missing the focus while writing a major software component:

Keep in touch with customers: The best way to understand the main focus of your application is to keep in contact with users. They are the ones that can help judge if a feature is important or not.

Work from a to-do list: It is always useful to have a map when travelling. When working, the closest thing to a map is a to do list. You can decide ahead of time what the plan is for your application, so you don’t get distracted by superficial details.

Avoid the unnecessary: sometimes we try to add features just because they are nice or fun to have. Avoid doing this always. It doesn’t add value to your application, and at the same time creates complexity that you don’t need. Always limit your features to what you really need and you will have more solid products.

Iterate fast: a good way to avoid losing context is to be pragmatic. Iterating fast gives you the focus necessary to keep the main context of your application in your head.

XML is a generic format for data storage that has been widely used by the industry. That could be all that there is to XML, if were not for the importance of data in programming. One of the things you learn when using Lisp is that data can also be viewed as code — we just need some way to interpret it using a programming language. This is the secret that make s-expressions so powerful.

It turns out that using C++ or Java to interpret data in XML format is not terribly complicated. Many people have made a good life just doing this kind of thing, using one of the many libraries available.

It is possible to use data encoded as XML as code and use a standard XML parser to interpret that data.

There are several examples of how this strategy may work. Ant is a well know case, where XML has been used to encode not only data about the building process but also other programming-like actions.

XML and Domain Languages

Using a textual language to express commonly used actions has always been a powerful way of creating software. For example, whole systems have been implemented using a domain language.

Think for example of Emacs, which was implemented in a simplified version of Lisp. Or, in a more specific domain, troff was implemented using a special-purpose language.

The advantage of using XML, though, is that one doesn’t need to use yet-another-parser for a domain-specific language. At the end, using a generic format such as XML is almost as good as the s-expressions used by Lisp.

In a sense, XML unleashes the possibilities of domain-specific languages for everyone else who doesn’t know how to write good parsers. You still need to implement the semantics of the language in Java or C, but this is a great step towards improved support for domain specific languages.

Further Reading

To Understand how Lisp leverages the power of DSLs, the best reference is Paradigms of AI, where this and related techniques are discussed.