Interview: John De Goes Introduces a Newly Free Source Code Editor
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.
|Save search queries for later.png||13.17 KB|
|Quickly navigate UNA without using a mouse.png||15.91 KB|
|Quickly navigate documents with incremental search.png||5.45 KB|
|Quickly locate symbols, files, declarations of symbols.png||15.17 KB|
|One search and replace interface - unlimited power.png||5.61 KB|