"The
tools market is dead. Open source killed it. The only commercial tools
that can survive today are the ones that leapfrog open source tools." Thus argues John De Goes, president of N-BRAIN,
which creates and provides UNA, a source code editor. After all, in the
midst of the competitive IDE space, mainly populated by IntelliJ,
Eclipse, and NetBeans, there are other players—lighter in
weight and fleeter of foot. These are the pure source code editors. The
personal edition of one of them, UNA, is now being distributed for
free, since a few days ago. We find out more from John, who made the announcement here on Javalobby.

Hi John, can you briefly introduce yourself?

I've
been a software developer for more than 20 years now, having written
dozens of programs in Pascal, Fortran, C, C++, Java, JavaScript, PHP,
and other languages. Likely more than a million lines of code, all
told. I absolutely love software development—it's my life's passion.
I devour books on software engineering and computer science and have
even written a few books myself, on 3D game programming (albeit not
recently).

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.

What are the languages currently supported by UNA?

Currently,
we have mixed levels of support for the following languages: Ada,
assembly language, batch files, C, Cobol, C++, C#, CSS, Eiffel, Erlang,
Fortran, Haskell, HTML, Java, JavaScript, Lisp, Lua, Pascal, Perl, PHP,
properties, Python, Rexx, Ruby, Shell, Smalltalk, SQL, VisualBasic,
Verilog, XML. For some of these languages, we just do syntax
highlighting, keyword completion, and so on. But for any language
supported by Exuberant CTags, we offer much broader functionality,
which includes structure views, object hierarchy views, go to
declaration, parameter hinting, and so on.

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.

Since
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.

What exactly do you do when you create new support for a language?

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.