Interview: John De Goes Introduces a Newly Free Source Code Editor
Interview: John De Goes Introduces a Newly Free Source Code Editor
Join the DZone community and get the full member experience.Join For Free
Hi John, can you briefly introduce yourself?
These days, my day job is President of N-BRAIN, though I still spend up to 30% of my time acting as lead developer on UNA. Mainly working on stuff behind the scenes, like the concurrency framework, the collaborative merging algorithm, networking code, and parsing technology, in addition to serving as resident usability expert and interface designer.
Firstly, for for those who don't know, what is UNA in the first place?
UNA Collaborative Edition is a real-time collaborative development environment for software engineers. It lets two or more developers edit the same code, at the same time. It's similar to pair programming, but better because both developers can contribute productively, whether they're located across the hall from each other or on different continents. It includes other features like chat, a whiteboard, persistent notes, team tools and team queries, and other features to enable developers to work together in real-time.
As a development environment, both Collaborative and Personal editions of UNA support most of the features that developers have become accustomed to, such as syntax highlighting, source snippets, regular expression search and replace, external tool integration, auto-complete, structure and object hierarchy views, and lots more.
What does "UNA" stand for?
UNA (pronounced 'ooh-nuh') comes from the Latin adjective for 'together'. 'Una' also means 'one' in some languages, and that kind of fits too: the idea behind the collaborative edition is several developers working together, as one. We write it in uppercase because it looks better and is more faithful to the logo.
Basic support for Groovy, Scala, and several other languages is coming in the next micro release (about two weeks from now).
And how did UNA come to be?
Four years ago, I was working on a project with millions of lines of code, maintained by dozens of programmers over the span of two decades. It was hard to understand sections of this code, and impossible for anyone to understand all of it. As there were no unit tests, changing anything could have unintended consequences that might be detected only weeks or months later (possibly by customers).
In this environment, I discovered that two heads really are better than one. Developers have different ways of interpreting code, and different ways of solving problems. Combining this rich diversity creates a strength unequaled by any single developer. Put me in a room with a junior programmer, and turn us loose on some task, and I guarantee you that I will gain new insight into the problem from this developer, and that our resulting solution will be stronger than anything I could have come up with alone.
Once I came to understand this, I immediately began looking for a tool that would make real-time collaboration the default way of working, and which would allow both developers to contribute productively at the same time. SubEthaEdit was king of collaborative editing, but only on the Mac, and even this great editor assumed you would be working alone most of the time, sharing a file or two on occasion. Plus, it's not easy to develop software without external tools integration and other features that SubEthaEdit did not have. So, since nothing existed that satisfied my needs, I decided to contract out the development of such a product.
After several false starts, I found some stellar developers by the name of Alexander and Michael, who began work on the project that would later be called UNA. Eventually, I realized my background in mathematics, computer science, and distributed computing would be necessary, and I quit my day job to work on UNA full-time. Other contractors came and went over the years, and recently we've added two new developers, but we're still a small, tightly focused group of developers who all share the same vision for the future of software development.
You announced last week that UNA Personal Edition is now being distributed for free. How did that happen?
UNA Personal Edition exists as a byproduct of UNA Collaborative Edition. Last year, we realized that our networking layer (itself the result of two years of experimentation and refinement) was sufficiently abstracted that we could trivially produce a network-less plug-in, which would enable the server to run in the same JVM as the client, shuffling events around entirely in memory. At the same time, I was doing a lot of work on the road and really wanted a way to use UNA without having an Internet connection.
About a month later, UNA Personal Edition was born, packing all the non-collaborative features of UNA into a version that doesn't require a server or an Internet connection. Otherwise, it's feature-for-feature identical to UNA Collaborative Edition, even allowing you to add users, draw on the whiteboard, and chat to yourself.
We never intended Personal Edition to be free. Years of work and cutting-edge research went into this editor, and it rivals, even surpasses, commercial editors that are selling for $100, $200, even $400 a pop. Even though it wasn't our primary goal, we realized that we produced a standalone editor of great value, and we hoped to use Personal Edition to subsidize some of the costs of developing UNA.
Unfortunately for us, that wasn't meant to be. The tools market is dead. Open source killed it. The only commercial development tools that can survive today are the ones that leapfrog open source tools. With UNA Collaborative Edition, we have that—there's nothing for real-time collaborative development that even comes close, whether commercial or open source. But UNA Personal Edition is more of an incremental improvement on what's out there in the editing world.
UNA Personal Edition was not going to persuade Java developers to stop using Eclipse or Idea, .NET developers to stop using Visual Studio, Ruby developers to stop using TextMate, or die-hard Emacs and Vi developers from using those respective editors. Why? Because stripped of its collaborative features, what remains is an incremental improvement on the status quo. Incremental improvements that cost money don't fare well against free tools. Especially not in the context of a developer tool, which is a very personal issue to many. Some developers would rather quit their job than be forced to use a new editor or IDE.
So I think we've slowly come to the realization that in order to gain widespread acceptance, UNA Personal Edition has to be free—not free just for version 1.0, but free for all versions, for all time. We will never charge a penny for UNA Personal Edition. Now it can compete with all the other free stuff out there. Sure, it's an incremental improvement on what many people are using today—but it has some features you're not likely to see anytime soon in either free or commercial editors, and it's getting better every day.
Ironic, the way it turned out: UNA Collaborative Edition now subsidizes Personal Edition!
How does it compare to Eclipse, NetBeans IDE, and IntelliJ?
First of all, I should mention that UNA is a source code editor, not an IDE. It's a very sophisticated editor, well on the road to becoming an IDE, but it doesn't provide out-of-the-box support for compiling, testing, or debugging. However, you can add those features to UNA by using the external tools interface, which allows you to do all these things from inside UNA. The tools interface is, bar none, the most powerful interface for integrating with external tools that we know about.
Now, although setting up external tools takes less than 10 minutes for the average project, it's the single largest barrier to entry because the majority of today's developers don't know how to invoke tools from the command-line. The fantastic IDEs we have today have shielded developers from the workings of compilers and testing frameworks. This is wonderful, in that it's brought many people into the field who would not otherwise be in it. It's lowered the cost of entry. But it's not so great for tools like UNA, which assume that developers are familiar with such things. We have plans to dumb this down, to make UNA more accessible to the average developer, because we realize this is a growing segment we can't ignore.
All that said, I think UNA fares very well against Eclipse, NetBeans, and IntelliJ Idea.
- First of all, we're usability snobs, and I mean that in a good way. We've poured extreme attention to detail in building the user-interface of UNA. We routinely conduct usability tests to refine the product. And because of all this, we've built one of the most usable development environments out there. We have usability tests showing that a user who knows nothing about UNA can download and install the product, and write and compile a Hello World program in about 10 minutes. This is with absolutely no help from us and no user manual or reference of any kind. Ask a user who knows nothing about Eclipse to do the same, and you're looking at a timeframe measured in hours. Much less time for NetBeans or Idea, but still not as good as 10 minutes.
- We've taken great care to ensure that UNA's interface is non-modal, wherever possible. For example, every document and text box in UNA operates in the exact same way—auto-complete and incremental search work alike in both. Similarly, you can search any list or tree in the exact same way, regardless of where it's located in the program. These features let you forget about where you are in the interface and work in a uniform way. This may seem like a small thing, but it's really not. I can't count the number of times I've cursed the editor or IDE I was using because some operation that worked in one place simply refused to work somewhere else.
- UNA doesn't use pop up dialogs that force users to hit 'OK'. If modality is the number one enemy of usability, then pop up dialogs must be enemy number two. How many times have you filled in a dialog, and clicked 'OK', only to be informed you entered invalid data and must try again? If you're like me, hundreds of times. Most applications punish users for entering data that they allow the users to enter. They bash users over the head, effectively telling them, 'You stupid user, why did you enter such stupid information? Go try again!' In our view, it's not the user who is stupid, it's the application: applications should never punish users for entering data they allowed the users to enter. This philosophy is evident everywhere in UNA. For example, if you go to create a new class, but type in the name of an existing class, then as soon as you type that last letter, the OK button becomes disabled and an unobtrusive message appears on the same dialog to let you know that a file of the same name already exists. Similarly, if you create a new tool, but forget to specify the tool executable, the OK button is disabled, and displayed on the same dialog is a helpful little message explaining why you can't hit OK just yet. You won't find this obsessive attention to usability in any other IDE or editor (no one is as crazy as we are!).
- Keystrokes are another strength for UNA. We follow a set of rules: if you want to expand the scope of an operation, you hold down the 'Shift' key while invoking the operation. If you want to perform the interactive or expanded version of an operation, you hold down the 'Alt' key while invoking the operation. And if you want to do the opposite of an operation, you tap or hold down the 'Caps Lock' key while invoking the operation. Now, without any further hints, if Ctrl + S saves the current file, what does Shift + Ctrl + S do? What does Alt + Ctrl + S do? If Ctrl + O opens a file, what does Caps Lock + Ctrl + O do? You already know the answer to these questions because you know the rules. Developers have better things to do with their time than memorize keystrokes. Some of the above mentioned IDEs even go against the conventions of the underlying operating system—and as a Mac user, this drives me crazy. Applications, especially editors and IDEs, should respect the universal conventions of the underlying operating system, so users don't have to learn separate keystrokes for performing the same basic operations in different applications.
- Another standout feature in UNA is the non-blocking interface. Whenever you initiate an operation, it happens in the background. You're free to continue working while the operation completes. I suspect many developers like myself are tired of waiting for today's heavyweight IDEs to finish some operation, whether it's updating a project or running unit tests. UNA lets you work instead of wait. This is much more difficult to code, because it means UNA is massively multithreaded, capable of taking advantage of all the processing power you can throw at it. But the result is a more pleasant user experience.
- I would also say the search/replace and incremental search interfaces far surpass those in Eclipse, NetBeans, and IntelliJ Idea. I love IntelliJ Idea, but I can't count the number of separate Find and/or Replace dialogs that it has. Every time I open that menu I spend 10 seconds trying to sort through the mass of options I see. UNA has a single Search and Replace interface, which is non-modal and doesn't interfere with your editing of text. You can save search queries if you use some options repeatedly, and access them with a keystroke. But the basic interface is perfect because you don't have to think. You can literally do everything from a single interface. And did I mention that searches are instant, even if the project contains hundreds of files? The incremental search in UNA is so novel that we're patenting it. That's right, we're patenting a feature we're giving away for free. The incremental search interface allows you to navigate documents with theoretical maximum efficiency. You can jump to wherever you want in the document by typing just half a keystroke more than the minimum number of characters necessary to differentiate that position from others. You can't do better than that. People were blown away by the incremental search feature of Idea 7.0, but we've got something better than that.
- Finally, I think that the process of building, testing, and running complex projects is becoming something that can't be done natively by any IDE, but which requires a full-fledged build language such as Maven, Ant, SCons, etc. With cross-language development increasingly common, development environments that can handle any language, and which rely on external tools for building, are becoming more and more relevant. If you have 10 languages to support, then you're already going to be doing so much work outside the IDE, that UNA is a stronger contender. For example, if you're writing a project that is a combination of C and Java (perhaps even Jeannie), then your IDE with great support for just Java is not going to be as useful as a tool like UNA, which provides good support for both. In either case, you're going to be building, testing, and deploying the project with scripts or programs external to the IDE.
In summary, as long as you're aware that UNA will require some effort to get your project up and running, UNA Personal Edition is a great choice for software development. UNA far surpasses existing tools on grounds of usability, and includes features that just aren't available anywhere else. Will it replace your favorite Java IDE? Probably not right now, but it will do a fine job complementing that IDE, especially in mixed language environments. And you might just find yourself wishing your IDE was more like UNA, because no tool pays as much attention to you as UNA, nor works as hard as UNA to stay out of your way.
Can you explain what the external tools interface is and how it works and how someone would use it?
The tools interface is how you add functionality to UNA. For example, in our project for working on UNA using UNA, we have tools setup for running files, compiling them, building the project, running automated tests, and launching a debugger. All the results appear inside UNA. For example, the tool that runs the automated tests (for a given file or directory) produces a nicely formatted and color-coded table showing which tests are passing and which are failing.
How does UNA's tools interface differ from the facility available in IDEs to run external programs?
Take a look at the interface for running external programs in most IDEs. It's usually a tiny little dialog that lets you specify the program and the arguments you pass to the program. That's the extent of your options. Output is usually shown in a separate window.
UNA lets you completely control the environment of the program and nicely integrate the program with UNA. For example, UNA lets you determine where the standard input comes from—the active file, user input, the current line, etc. Similarly, you can specify where the output goes: whether it's shown inside UNA (as text or HTML), shown as a tooltip, used to replace the current document, discarded altogether, etc.
You can limit tools to operating on certain file types. For example, in a Java application, a compile tool might be setup to work only on Java files. In this case, when you right click on a Java file, 'compile' is shown as an option, and of course, you can also select the compile option from the tool menu or activate it by a keystroke.
You can also use a wide range of jokers when configuring a tool, which range from the current line, to the active file, to the projectspace location, to something the user types in, and so on.
It's a hacker's paradise, because with very little effort, you can achieve great integration with existing programs. It's very much in the spirit of TextMate's bundles.
OK, so, how does UNA compare to other source code editors that are not part of IDEs?
There are lots of great source code editors out there, and at some time or another, I've used most of them: vi, Emacs, TextMate, jEdit, SlickEdit, e, EditPlus, SubEthaEdit, Nedit, and many others. All serious code editors have incredible power, but in most cases it's not accessible to the average developer. You need a cheat sheet for all the hidden functionality, and a year or more to gain proficiency in the editor, and its bundled, often proprietary, scripting language.
UNA takes a different approach:
- First, virtually all functionality in UNA is accessible from menus, similar to Nedit. This means you don't need to memorize commands if you don't want to, since you can do everything with the mouse. This makes for some large menus, but it exposes the full power of UNA to the greenest of users. The commands are still there, and with time, you'll subconsciously memorize the ones you use most often. With the consistency of our keystrokes, we actually cut down on the number of keystrokes you'd ever need to memorize: a full two-thirds of commands can be guessed by following the three rules (shift = expanded scope, alt = interactive, caps lock = opposite).
- Second, instead of focusing on a large number of marginally useful features, we've tried to focus on a smaller number of killer features. For example, programmers spend more time navigating code than actually writing code. And the killer feature here is in-place incremental search. You can use the feature to instantly jump to some text, with the theoretical minimum number of keystrokes. Not just text, but you can actually use the same feature to jump forward by a word (simply search for whitespace), a newline (search for enter), a brace—whatever. In fact, I would go so far as to say the in-place incremental search replaces 20 or more individual commands, which goes a long way toward reducing mental overload. It's such a simple concept that changes the way you get around in a document.
- Third, we have the highest attention to usability that I know of. I've already talked about this somewhat, but I'd like to given an example in the context of an editor. TextMate is a fantastic editor, and if you work on the Mac, you owe it to yourself to purchase a copy. Since it gets so many things right, I don't mind picking on it a bit. Many of the bundle commands show results in a separate window. This window pops up, on top of my work, and forces me to pay attention to it immediately, at the expense of whatever else I'm doing. Commit a file, for example, and some number of seconds later, I'm rudely interrupted with a dialog telling me I've just committed a file. I don't want to know that an operation I expect to succeed actually does succeed—tell me if it doesn't work, and only then, in an unobtrusive way. UNA's tools and operations run in the background, with results appearing down below in a defined area; they never steal you away from your work, force you to wait for them to complete, or transfer your input focus from one area to another. UNA is the only tool that can make you that promise.
- Finally, even in the current 1.0 release, UNA has quickly approached the power of some IDEs. For example, take version control. If you have a project setup with version control, then until you decide to update or commit, you won't even know you're working with a repository. Create files, delete them, rename them, drag and drop them in the project tree to move them around—UNA keeps track of what you do and does the appropriate thing when you commit. This is IDE territory here. As far as I know, there's no text editor with this kind of functionality. Add to that file structure and object hierarchy views, go to declaration, parameter hinting, symbol renaming, and so forth, and you're well beyond the range of most text editors. From the screenshots, most people actually think UNA is an IDE—and with the proper tools added, it can actually function as one.
Now UNA isn't designed for editing single files. That's a definite weakness. So it's not going to replace most people's favorite code editor. It hasn't replaced TextMate for me. But for actual projects, UNA provides a shorter learning curve, some killer features you won't find anywhere else, a silky smooth experience that puts you first, and features you ordinarily find only in IDEs.
Who are your typical users and what do they say about it?
The typical user of UNA Collaborative Edition consists of between 2 and 10 developers. They're usually distributed, sometimes work in different time zones, often use dynamic languages, and they want a way to get together and collaborate on critical sections in the code.
we just released UNA Personal Edition free of charge, we can't say much
about the typical user. But since the day we announced UNA, we've seen
tens of gigabytes of traffic, mostly from people downloading Personal
Edition. So over the coming weeks, we'll be learning a lot about the
typical user of the product.
As for feedback, I think we've made believers of any critic who has actually tried the platform. For example, Russell Foltz-Smith of SocialMode fame wrote this unsolicited blurb about UNA Collaborative Edition:
UNA is a special platform. Anyone who knows how I code and run projects understand[s] how bold a statement that is for me. Why? I very much believe in the solo hacking til it works. UNA is about group - real time collab. I usually hate group collab on code and design because the communication and miscommunication gets in the way. UNA is different because the collaboration is weirdly seamless and actually real time - you all see the same things, you chat inline, code completion just works, everything is tracked, and never once does the group feature take precedence over just coding.
...I sure hope the Visual Studio, Netbeans, Eclipse, Zend, Codeworks, and Nusphere folks pay attention to this and either integrate or buy N-brain['s technology]. Seriously, the system is that cool.
Can you share some screenshots of your personal favorite features?
Sure. I'll provide my personal five favorite features of UNA Personal Edition. Several of these are features I use so much, that when I switch to IntelliJ Idea for some solo coding, I mistakenly invoke them.
- In-place incremental search, which lets me get around documents faster than vi or Emacs users:
- A single search and replace interface, no matter what or how I want to search:
- Shortcuts that transfer focus to different parts of UNA, so I don't have to use the mouse:
- Saving search queries that I use often and accessing them with keystrokes:
- Go to Declaration, which I use a hundred times a day to navigate to the declaration of methods and classes:
These are just my favorites. The other developers of UNA have their own favorites, which I'm sure are different from mine.
We create a syntax definition file, which is an XML file describing the basic syntactical elements of the language, and how they should be colored. This file also describes the keywords in the language, what constitutes code and what constitutes comments, what token is used to access members of an object, etc. If the language is already supported by CTags, then that's all we do, because our interface to CTags provides a lot of language-aware functionality for free. For languages not supported by CTags, but for which there is customer demand, then in the short term, we will probably contribute parsers to the CTags project.
In the long term, we're in the early stages of developing something similar to the NetBeans language extension API (itself currently in development). This will form the basis for more advanced language-specific functionality, such as semantic analysis and refactoring. The work that's been done in the past few years to unify the parsing and transformation of programs is quite amazing. I think all the major IDEs will move away from the massive amounts of hard coding that brought them to where they are today, and towards more generic platforms that employ language plug-ins—written in domain-specific languages tailored to the task.
Where do you stand, personally, on the place of Java in the language space, i.e., with multiple languages on the VM and polyglot programming and so on?
Java's going to be around for a long, long time. However, It's definitely showing signs of age. When you have to work as hard as some of these frameworks do to make Java development competitive, you know something is fundamentally wrong with the language. XML configuration files, dynamic proxy generation, aspect-oriented frameworks—they're all signs that Java is lacking the expressive power demanded by today's applications.
I could be wrong, but I think the Java community will continue to bolt new features onto the language in an effort to keep up with everyone else, which will turn Java into the next C++. There will be so many ways of doing things (closures or anonymous classes?), so much complexity in the grammar, that most developers working in Java will stick to a subset, while the larger community will move to other languages. Only unlike C++, the move to other languages will be facilitated by the JVM, which may turn out to have a larger impact on software development than Java itself.
Polyglot programming is not new, and a classic example is C and C++. Companies didn't have to abandon their existing code to move to C++ for new development. That's the key to Scala, Groovy, JRuby, JPython, and the other 20 different languages that now run directly on the JVM. They can all seamlessly reuse tens of millions of lines of code written in Java—all the libraries out there that have made Java so powerful, and any code that companies themselves maintain. This makes the language landscape far more competitive than it's ever been in the past. Language lock-in is less of an issue now, in the growing family of languages that run on the JVM.
Of course, there's a cost to maintaining code bases written in many different languages. You need to hire a different class of developer, and that costs more money. Most developers are also resistant to learning and using multiple languages (one developer I know maintains, "Java for life!"). So I think it will be difficult to move the broader market into routine use of multiple general-purpose languages.
I do expect that we'll see a kind of meta language in the next 5 years that a competent developer can use to construct domain-specific languages (please don't anyone say Lisp!). Ruby has had success in this area even though it was never designed with this goal in mind. Some Java and Flex developers are using Ruby to construct DSLs to perform automating testing and building. Who could have predicted that?
What's UNA's future direction?
Everything we do is motivated by the vision of bringing developers together, to collaborate in ways the development world has never seen before. So you can expect lots more in this direction—features I'd rather not discuss just yet, but which can only be built on top of a collaborative platform like UNA.
A lot of the other new features coming to UNA will also benefit Personal Edition users. For example: Live syntax checking for most languages. A new concept we're calling 'project mixins', which let you add chunks of functionality to a project (for example, a full suite of tools for compiling, testing, analyzing, running, and debugging a Java project from directly inside UNA). Support for more languages, such as Scala and Groovy, and improved support for existing languages. A more comprehensive plug-in framework. Eventually, even refactoring for common languages.
Of course, our ability to add these features depends on having a steady base of users, who work with us to make UNA the best it can be—both for collaborative and personal editions. I hope the developers reading this article will give Personal Edition a try and let us know what they think.
Opinions expressed by DZone contributors are their own.