idea.log

IntelliJ IDEA is the "best HTML editor in the world"

2007-04-06T22:37:00.000+02:00

Patrick Lightbody calls IntelliJ IDEA the "best HTML editor in the world". Strange. You would think that he meant best Java editor, or that he would have picked a dedicated HTML editor. But no, he is very clear:

This is not an understatement. Ruby-fanatics even admit their beloved TextMate has nothing on IDEA (right Dion?). Heck, at my company, our VP of Marketing (who gets hands-on w/ web design) now uses IDEA and swears by it. Why? Because it speaks fluent CSS, HTML, and JavaScript. And all those nice inspections work here too. It'll highlight unused CSS declarations. It'll help you find usages for JS functions and CSS classes. It'll even point out the fact that "0px" is redundant and can simply be "0"... and you don't have to delete "px"... remember, just press Alt-Enter!

In fact, he's right! And he's not the first to notice. This year, IntelliJ IDEA won a Jolt Productivity Award in a new category, under Web Development, at least in part due to its HTML-editing features. (Check out the Javascript and Ruby support as well....)

The trick is that IDEA is not just dedicated to Java, it has a code-centric architecture that can enhance any language in an intelligent way, including editing, refactoring, code search, navigation, inspections, code highlighting, and formatting. On top of this architecture is the Language API, which allows any language (e.g. Ruby, SQL, etc.) to be plugged in to benefit from these productivity features. Of course, the real beauty of web development with IDEA is the ability of all the languages to work together. Got a JSP page with embedded HTML, CSS, and Javascript? No problem! It all works.

The IntelliJ philosophy is this: Programmers spend most of their time working with code, so the IDE should be as intelligent about code as possible. That's why we have a dedicated code-centric architecture to handle any language a Java programmer might need to tackle. It is also why IntelliJ IDEA is not only the best Java editor, but the best HTML editor, too.

Rediscovering Refactorings

2007-03-26T15:32:00.000+02:00

Michael Feathers wrote a blog listing some of the refactorings he would like to see in IDEs. Two refactorings in particular caught my eye, Extract Class and Introduce Parameter Object. In fact, these refactorings have been available for quite some time via a third-party plugin for IntelliJ IDEA called Refactor-J, from Sixth & Red River Software.

Introduce Parameter Object is great for simplifying a long parameter list by condensing several parameters into a single parameter object. This can be a great way to clean up your design to make it easier to use, easier to read and comprehend, and easier to maintain. Parameter objects can stay as simple value objects, or they can evolve into something more intelligent, as needed.

Michael's request also includes that any arbitrary group of variables (fields or local variables) could also be converted into aggregate objects. If it is possible to implement, I'd like to see this as well. It could potentially be a very useful refactoring, allowing you to quickly sketch out the collaborating classes your design may need. Just start with basic ints and Strings and build your object-oriented design from that.

If you regularly do complex refactorings, or if you just happen to want more power out of refactoring, I suggest looking into the Refactor-J plugin. It has about 20 extra refactorings in total. Also, for more 'personalized' refactorings, you can always use the built-in Structural Search & Replace feature of IDEA. It takes a little getting used to, and it cannot do all kinds of refactoring, but it is often the best way to make refactoring-like changes to your code that cannot already be made with existing refactorings.

At the end of his post, Michael asks for what he calls 'intelligent statement move'. Well, unfortunately what he's asking for is not likely to be seen for a while, but with a sufficient suite of unit tests, the basic Move Statement Up/Down editor command (Ctrl-Shift-Up/Down) is sufficient for most purposes. It can even move syntactically correct blocks of code (you can select sytactic blocks with Ctrl-W), or even whole methods.

Have you ever dreamed up any special refactorings you would like to see in your IDE?

Productivity Talks at JHUG Tech Day

2007-03-15T16:02:00.000+01:00

Last Saturday I gave a talk at the Java Hellenic User Group, and I found it interesting that all of the talks given there had an underlying motivation of increasing productivity.

First was Dr. Heinz Kabutz, the famous Java Champion and editor of the Java Specialist newsletter, who had a talk called Productive Coder. It was a good talk to start the day because he gets you thinking right away about seeing things from a productivitiy perspective. For instance, his first major point is that most programmers that he has met cannot even touch-type without looking at the keyboard. It seems like such a minor thing, but by learning the keyboard so well that it is intuitive, it's just more productive since you don't have to spend your awareness on the keyboard and can think of the task at hand instead. Heinz' talk included many similar small-but-important ideas about becoming a more productive coder.

He also showed a demo of IntelliJ IDEA, emphasizing learning the keyboard shortcuts for an IDE (even I learned a feature -- column editing mode, Alt-Shift-Insert). I think learning shortcut keys is in many ways like learning a new language. Once you've learned one useful language, it's frustrating to try to get to the same fluency in another, unless you put some effort into it. This can make switching IDEs painful. Heinz mentioned the IntelliJ IDEA keymap reference card you can print out and stand up on your desk to help you learn the shortcuts (see here). He also talked about object-oriented principles and how to tame a jungle of legacy code with refactorings like Encapsulate Fields, to make fields private.

Tom Baeyens of JBoss/RedHat did a talk on workflows and process languages. Part of the motivation there is to simplify and automate communication between the analyst and the programmer, an attempt to increase productivity in this area. Tom has a great sense of humour and I enjoyed his talk very much.

Patrick Linskey of BEA talked about JPA (Java Persistence API), and how a big motivation is to simplify object-relational mapping, automating it, so you can think in higher level concepts of objects rather than tables. Of course the flexibility is there to use tables if necessary, but the real power of the spec is in ease of use and testability that the object abstraction gives you. Patrick was extremely knowledgeable, as we could tell during the Q&A.

Finally, my talk was on Tools for Agile Teams, focusing on how IntelliJ IDEA and TeamCity support agile development methodologies by helping developers stay in flow longer and more often. Flow is the highly productive state of mind when you're focused on a task and outside distractions seem to melt away. Most people in the audience reported that they had experienced the state of flow and also that they have experienced being frustrated by tools that interfere with flow by annoying distractions and context switches. I demoed some of IntelliJ IDEA's productivity features and gave an overview demo of how the TeamCity continuous-integration server can help increase team-level productivity.

Thanks to Paris Apostolopoulos and Panos Konstantinidis of the JHUG for organizing the event. It went very well and was quite enjoyable.

TheServerSide asks the right questions

2007-03-01T19:06:00.000+01:00

Some IDE surveys are just simple popularity contests. Not this one. This survey from TheServerSide.com, has much smarter questions, and I'm really looking forward to the results!

For instance, instead of just asking which IDE you use, it splits it up into which IDE the organization uses as standard, and which IDE you personally use.

Some organizations impose a particular IDE on all the developers because of an 'organizational standard'. Such standards might be good for something like databases and servers, but I hardly think it makes sense to force a developer to use an IDE that he or she is not productive in. Developer productivity often trumps the relatively small cost-savings of standardization. If you save $1,000 a month by standardizing, but the IDE you choose makes your 10 programmers even 5% less productive, you're actually losing a big chunk of money there, since the lost productivity is closer to $5,000 per month.

Also, professional programmers like being productive and, given the choice, most of them would choose the one that makes them more productive rather than being forced to use an organizational standard. One of the interesting questions in the survey is "If you do not directly choose your IDE, which one would you prefer to use?" I definitely want to see the results there! I expect to see a lot of cases of organizations standardizing on a particular IDE, but some of their developers wishing they could use a different IDE. IDE choice is often a personal thing, and hopefully this survey will help people realize that.

Of course, the questions aren't perfect, although they are definitely a step in the right direction. One of the questions asks, "Which three features do you value most in an IDE?" While this is a good start, it completely ignores that things like 'productivity' and 'usability' are not features, but they can easily be the most important thing people value in an IDE. It is very common to hear fans of IntelliJ IDEA say things like, "There's no particular feature I can point to, it's just that all the features just seem to work better." I hope to see surveys in the future that tackle the importance of intangibles like usability, intelligence, and productivity.

Check out the survey here.

BDD and the Power of Metaphor

2007-02-27T15:23:00.000+01:00

I read an interesting article by "Uncle" Bob Martin talking about Behaviour Driven Development (BDD). Since I hadn't heard of it before, I decided to scratch the surface and see what I could find. One of the nuggets I found was a PDF by Dave Astels expressing his frustration about how no one seems to get Test Driven Development (TDD) right:

"Everyone who's doing TDD is fully understanding it and getting the full benefit, right? Fat Chance! Too few people I talk to really understand what it's really about. That means that many people who practice TDD are not getting the full benefit from it."
...
"The thing is, when the evolution to TDD happened what we ended up with was a different kind of animal... not just a slight tweak on the original."
...
"So, there you have it. A fabulous idea... wrapped in packaging that causes people to think from a testing point of view."
...
"So if it's not about testing, what's it about? It's about figuring out what you are trying to do before you run off half-cocked to try to do it."

Digging a little deeper, it turns out that Dan North has been having these ideas for a while and he writes a nice introduction to behaviour-driven development. I recommend it highly, as it clearly lays out the motivation for BDD. This introduction to BDD is also a good place to start.
Basically, BDD is taking TDD closer to specifications rather than tests. Well, executable specifications, so they remain tests, just look and sound more like specifications. In essence, it's not really a new technique per se, but a new way of thinking about, designing, and organizing tests.

What I find interesting is that one of the main motivations is 'getting the words right', which is exactly what I was thinking when I wrote a blog called "Why Are Continuations So Confusing, and What Do They Really Do?". My gripe was that the word 'continuation' doesn't actually help you to understand what a continuation really is, and I proposed thinking instead in terms of 'execution sites'. For me, that metaphor works much better, just as the metaphor of specifying behaviour is better than the metaphor of unit testing.

Metaphor and analogy are powerful tools of understanding and insight, if you can find a useful connection. Earlier this week I blogged about the connection shared by TDD and continuous integration (CI), showing that they are both part of the same agile trend towards faster and faster feedback on quality (TDD at the programmer-level and CI at the team-level). Now with this whole BDD thing, I wonder what kinds of insights and connections BDD can bring to CI and vice versa. Maybe part of the job of developing TeamCity will be to develop a new vocabulary for continuous integration.

Why IntelliJ IDEA Customers Keep Coming Back

2007-02-23T12:59:00.000+01:00

Brian Pontarelli has a passion for the keyboard and makes some good points about usability and support in regards to Java IDEs, specifically IntelliJ IDEA and Eclipse. The comments after the main post are especially interesting, such as where some commenters argue over whether a reported issue counts as either a severe bug or a missing feature. I mean, come on. Does it really matter? The point is that it interferes with Brian's experience of usability and productivity. I've been saying it for a while: It's not about feature lists, it's about usability and productivity. You won't find usability or productivity on a feature list, but it can easily be the most important deciding factor on whether or not to choose one piece of software over another. JBuilder was marketed on the length of its feature list, and look where it got them.

JDJ Readers' Choice Awards

2007-02-21T12:05:00.000+01:00

Just a reminder for folks to join in the voting at the Java Developers’ Journal Readers’ Choice Awards. JetBrains has entries in several categories for IntelliJ IDEA and TeamCity:

Best IDE - IntelliJ IDEA 6.0
Best Web Development Tool - IntelliJ IDEA 6.0
Best Java Application - IntelliJ IDEA 6.0
Best Java Debugging Tool - IntelliJ IDEA 6.0
Best Java EE App Dev. Framework - IntelliJ IDEA 6.0
Best Java IDE Environment - IntelliJ IDEA 6.0
Best Java Project Build Tool - TeamCity 1.0
Best Team Development Tool - "IntelliJ IDEA 6.0 / TeamCity 1.0" Pack
Best Tool for Rich Internet Applications - IntelliJ IDEA 6.0
Most Innovative Java Product - TeamCity 1.0

Faster Feedback and Why You Want It: From TDD to CI and Beyond

2007-02-20T17:59:00.000+01:00

I recently heard from someone in the industry that around 30-40% of teams are using test-driven development, but only 5-10% of teams are using continuous integration servers. I'm not sure how reliable those numbers are, but that's not important; what is important is the general picture: Even the people who seem to understand the benefits of test-driven development don't seem to understand the benefits of continuous integration. I found that very puzzling, especially because I see continuous integration (CI) as a natural progression of test-driven development (TDD). They are, after all, part of the same trend of agile software development leading towards faster and faster feedback.

Oh, Waterfall...
The trend goes all the way back to that dusty fossil of software development theory, the waterfall model and its fixed and rigid phases of: Analysis, Design, Coding, Integration, Testing (and Deployment and Maintenance, which I won't bother with here). The big problem with waterfall is that once something is planned at the beginning, it is set-in-stone and changing it becomes very expensive. Many projects would either fail by going over time or budget constraints, or by the death of a thousand cuts... the dreaded Feature Creep. Clearly there needed to be a more flexible way to get the right plans up-front so that there would be no need for changes during development.

Spiralling Towards Agility
This is the motivation for the spiral model, with its repeated iterations of little waterfalls: Analysis, Design, Coding, Integration, and Testing, repeated several times until done. Of course, the spiral model's flexibility was complicated by too much reliance on planning and documentation, leading to the recent rise of agile methodologies which repeat that loop in ever smaller, but more frequent, iterations. Depending on the agile methodology you look at, sometimes it will treat a 1 month iteration as a mini-waterfall, and in other cases it will take this progression even further, even down to the level of a week or even a day, so that on any given day, a programmer might do a bit of Analysis, a bit of Design, a bit of Coding, a bit of Integration, and a bit of Testing.

What is the meaning of this trend? The obvious answer is that it is a progression toward greater and greater flexibility. However, the proponents of test-driven development see flexibility as a side effect of a more important trend toward faster and faster feedback cycles. By seeing where things are going off-track earlier, you can make corrections to get things back on-track earlier. That is the source of flexibility; when a change or a new requirement comes up, fast feedback allows you to adjust to the new circumstances faster. So, faster feedback leads to greater flexibility.

A New Style
TDD takes it to the next level, breaking the programming task into even smaller iterations, and simultaneously putting the primary feedback mechanism, testing, at the forefront. In fact, it kind of reverses the whole process, putting testing at the beginning of each iteration, rather than at the end. The goal of TDD is to use the feedback from unit-tests to actually drive development. While this may seem counter-intuitive, when you realize that the goal is faster feedback, it actually makes sense because the sooner you have the test running, the sooner you are getting feedback from that test.

If for no other reason, it is important for programmers to understand TDD because it opens up a new style of programming. Instead of starting by thinking about how to make a design for the task, the programmer thinks about what it would take for the task to be complete. By holding the mindset of "tests first", this immediately requires breaking the task into much smaller sub-tasks because it is nearly impossible to write a high-level test from scratch. In fact, the only practical way to proceed is to start with very simple tests and build up from there. You need to think: "What is the simplest test that will actually test something useful?" In essence, we have shifted mindsets from being task-oriented to feedback-oriented.

When you think in this mindset, you can actually reverse the normal programming process. Analysis, Design, Coding, Integration, Testing (ADCIT) becomes Testing, Integration, Coding, Design, Analysis (TICDA).
But in order for this analogy to make sense, you need to think at a much lower level. The actual process goes something like this: Write a small test for some behaviour, compile and run the test to ensure that it fails (you can think of compiling as 'integration' at this low level of coding), write some code that will make the test pass, refactor the code until its design is as simple and clean as possible, then analyze the information you learned to decide which test to write next.

Test-o-matic Tools
The reason this reversal of the process is interesting is because it can change the way you look at programming, and potentially make you much more productive, but it is only possible with the right experience and the right tools. Every phase has its own tools associated with it to help automate it. It is only by sufficiently automating these phases that TDD can be achieved economically. Testing is done with a testing framework such as JUnit, compilation/integration is usually done by the IDE or a build script in Ant, coding is automated somewhat by editor features such as code completion, low-level design is aided with automated refactoring in the IDE, and analysis can even be automated somewhat with a static code analysis tool (either built into the IDE or separate). With all this tool support, TDD can be a very productive style of programming.

Next Up, Continuous Integration
Like testing, integration has followed a similar trend toward faster and faster feedback. In the early days, you had one big integration phase near the end of the project as different components were basically forced together. This was called Big Bang Integration. And like a big bang, it often did. The integration efforts often failed miserably, pushing project development past deadlines. People started to do integration more often, eventually implementing weekly or even daily builds. The concept of the daily build is promoted by several agile methodologies.

Continuous Integration is the next logical step beyond daily builds. With CI, each programmer takes responsibility for making sure that their contribution does not break the build. Martin Fowler describes it in detail in his article on the subject, but the basic idea of Continuous Integration is that once you finish a task, including writing tests for that task, you:

Ensure that the project (including all the latest changes from the repository) builds properly on your development machine.
Then, after fixing any issues that arise, you check in your code and do another clean build on an integration machine to ensure that you properly submitted everything to the repository.
After you fix any problems from this, you are done. Your change has been included in the repository and everything in the repository is integrated and builds correctly.

When every programmer follows this same procedure each time they commit a contribution to the repository -- often resulting in building dozens of times per day -- this is continuous integration.

Martin Fowler writes:

"If you have continuous integration, it removes one of the biggest barriers to frequent deployment. Frequent deployment is valuable because it allows your users to get new features more rapidly, to give more rapid feedback on those features, and generally become more collaborative in the development cycle. This helps break down the barriers between customers and development - barriers which I believe are the biggest barriers to successful software development."

The Feedback Connection
Again, like with testing, a little automation of this procedure can start to change our understanding of integration. With the help of a continuous integration server, the final step of performing a second build on an integration machine can be automated so that whenever a programmer commits code to the repository, the CI server detects this event and automatically starts a build, without requiring the programmer to manually do this himself. If the build succeeds, no problem; code is submitted to the repository, and everything is fine. But if the build fails, a report detailing the problem is generated and sent out. This report is essentially a feedback mechanism.

With this insight, now we can see a deeper similarity between testing and integration. Not only are they following a similar trend, but we can also see that integration is an extension of testing, at the team level. When a unit test fails, you are getting feedback on the quality of your own code. When a build fails, you are getting feedback on the quality of the whole team's code. So, unit tests are feedback on programmer-level code quality and builds are feedback on team-level code quality. 'Feedback on quality' is one definition of testing. Therefore, by this analogy, integration is team-level testing. A successful integration build means that your contribution is compatible with the other contributions which have been made in the repository. An unsuccessful integration build means you need to fix something.

This analogy puts things in a new light. For instance, just as we can see that TDD is a progression beyond basic unit-testing, we can also see that CI is a progression beyond the practice of daily builds. This is a useful analogy because it will show us how the factors involved in both TDD and CI will be similar in nature. For example, if more automation opens up a different style of programming with TDD, then more automation may open up a different style of collaboration with CI. Likewise, if TDD is more productive for you, then CI will probably be more productive for you as well, since they are both methods of speeding up feedback on code quality.

Well, by that analogy...
If the motivations for adopting TDD are the same motivations for adopting CI, then why aren't more people using CI? I think the problem is that the available tools do not fully support the ideal continuous integration scenario. When all we had was JUnit and a clunky IDE, unit testing wasn't widely adopted either, and there was no sign of TDD yet. Now we have IDEs with automated refactorings, advanced code-completion and code-generation, static code analysis with quick-fixes, and built-in support for testing frameworks (like JUnit and TestNG) in both the IDE and in other tools like Ant. All of these combined make productive TDD possible. Perhaps CI is in a similar early stage with its first major tool, the CI server, but not much else in the way of automation. Maybe someday soon we won't call it simply 'Continuous Integration', but we'll have a more advanced term for it like 'Integration Driven Development', or combine it with TDD and call it 'Feedback Driven Development'.

What would this ideal version of continuous integration be like? The dream goal is that there is always a complete, up-to-date, working version of the entire software product. Whenever a good change is submitted to the repository, the change is automatically incorporated into the final system -- no programmer interaction should be required except to commit code. Whenever a bad change is submitted, the programmer responsible for the bad change is immediately notified and every effort is made to help the programmer locate and fix the source of the problem. Furthermore, the effect on the other programmers in the team should be minimized as much as possible. Ideally, the code in the repository would never be broken.

Broken Build Syndrome
Today, the situation is not so rosy. Most CI servers do little more than provide a report (email, IM, web, etc.) when the build fails. They may also provide a web interface to keep track of the status of the builds, which is good, but not yet at the level of tool support that I'm imagining. Don't get me wrong, the benefits of a CI server are much better than even a Daily Build practice, but they don't go quite far enough to achieve that 'next level', as TDD is the 'next level' beyond basic unit testing.

One of the biggest problems with today's CI servers is what happens when things go wrong. I call it broken build syndrome. Somebody broke the build, the build hasn't been fixed yet, and it holds many other people back, since they can no longer rely on the repository's codebase. Builds take a long time to run, typically. On a medium or large team, broken build syndrome will happen, even if you have a CI server, because of this time lag. Sure, the CI server sends out a report detailing the problems with the build, but is it always easy to figure out from the report what needs to be done to fix it? Not always. And before you can find the problem, someone else has checked in their own bad code. They get a report too, but they think you broke the build so they don't realize they also need to fix it. As a result, the build remains broken much longer than necessary, and basically confusion and frustration spread through the whole team. This is just one of the many ways broken build syndrome can happen.

Should we blame the people involved? Not really. People make mistakes, so our systems should adapt to the people, rather than expecting people to act perfectly. If we draw our inspiration from TDD, we see that the way to solve this problem is to provide better tool support, automating those tedious things that are error-prone, and providing better visibility for those problems that do get through the cracks.

TeamCity
This is actually one of the primary motivations behind TeamCity -- to bring Continuous Integration to the 'next level', with features aimed at minimizing the problems and time wasted by broken build syndrome. Some of the features we already have are:

Remote Run and Delayed Commit - which perform a complete build without submitting code to the repository, so if the build breaks nobody else will be affected. With Delayed Commit, if the build is successful, the code will be committed to the repository automatically.
A Distributed Build Grid architecture - allowing many machines to run builds simultaneously, making continuous integration more continuous, without slowing down machines that are in use by your team members.
A rich web interface for monitoring and administrating builds - which provides detailed (but well-organized) information about all builds
A team-oriented (rather than tool-oriented) perspective on builds - providing useful metaphors like 'taking responsibility' for a broken build so that everyone on the team can instantly know whether or not someone is fixing the build
Tight IDE integration - allowing such things as jumping directly from an error-report to the exact line in your IDE where the test failed, as well as many other features. (Currently supports IntelliJ IDEA and Visual Studio 2005. Eclipse support is expected by the end of March 2007, and NetBeans support is on the way soon after.)
Server-side code analysis and code coverage - allowing time-consuming analysis to be performed regularly and all team members to benefit by viewing the results online or by fetching the results right into their IDEs

Conclusion
Even though there is a lot of room for improvement in tool support for continuous integration, the benefits of CI over the more-common practice of daily (or weekly) builds is very large. If you have already adopted test-driven development, then you really have no excuse -- CI is a natural extension to TDD, and the same reasons you chose to adopt TDD are the same reasons you should adopt CI.

If you haven’t taken a look at TeamCity, check it out here.

Or test drive TeamCity online, without a download, here.

Cool New Demo of Ruby Support in IntelliJ IDEA

2007-02-08T17:37:00.000+01:00

If you like Ruby, you're going to like this. If you like IntelliJ IDEA, you're going to like this. Check out this cool demo of the new Ruby plugin for IntelliJ IDEA.

So far, this is a beta-quality release of the plugin, so don't be expecting all the bells and whistles... yet. JetBrains is serious about this, though, so expect to see much more coming in the future. The demo shows some of the features that the plugin already supports, like:

On-the-fly syntax and error highlighting
Keyword code completion
Reformat code according to your style settings
TODO comment support
Structure-aware features such as structure view, goto symbol, etc.
RDoc support

This is great on so many levels. Combining Ruby and IDEA just makes sense to me, considering they share a lot of similarities in terms of philosophy. Both Ruby and IDEA try to help programmers be more productive by being smart, flexible, and intuitive, and even more so by getting out of the way and letting the programmer do what the programmer needs to do. And although this demo only shows Ruby support, don't think we've forgotten about Rails. Support for Rails already exists in the Ruby plugin and we will be expanding it as we go.

I think the big advantage IDEA will bring to Ruby developers will be the code-level intelligence and usability that IDEA is famous for in the Java and web languages (Javascript, HTML, XML, CSS, etc.). It will bring not just structure to the project (as any IDE should), but also new capabilities as well. For instance, refactoring, intelligent navigation and code searching, on-the-fly static code analysis (problem/error highlighting in the code), and intention actions (quick fixes). For Ruby/Rails developers who already appreciate productivity, they will surely appreciate how these features will help them to become even more productive than they are now.

Eclipse FUD: eWeek has no shame

2006-09-20T16:09:00.000+02:00

Just when you thought the IDE wars were over, irresponsible reporting fans the flames. How can the editors of eWeek even consider this article to be worthy of publishing? At best, the author Daryll Taft has absolutely no clue about the topic he is reporting on. At worst, it is pure FUD (Fear, Uncertainty, and Doubt). Here's why:

1) The article doesn't even link to the survey it quotes, which is a red flag in my opinion. You have to ask yourself, Why? Does the author want to make it difficult for readers to check his sources? Here's the link to the survey so you can see it for yourself (and participate if you like): http://www.tezaa.com/view/Your_favourite_IDE

2) The article correctly reports that the survey in question is 'grassroots', or a 'straw poll', which basically means it's unscientific. I can handle that; sometimes informal polls can still give an interesting picture of general opinion. However, the author fails to mention that at the time he took the numbers from the poll, there were only about 350 respondants, even though the poll has been running since June. For an internet poll, that number is really tiny and easily skewed.

3) Likewise, the author fails to mention that the poll options didn't even include some of the more popular IDEs in use today. There were only a small smattering of options, not at all representative of the real marketplace. The only recognizable IDEs listed were: Eclipse, NetBeans, Visual Studio, Dreamweaver, and Zend Studio. I had to add my favourite, IntelliJ IDEA (quite popular in the Java world), myself! And this poll has been running since June!!! I'm sure fans of other IDEs (a good example being JDeveloper) will shortly add their options too.

4) The author goes on to give a heavily one-sided 'analysis' of Eclipse's position in the market, heavily quoting Mike Milinkovich, and NO ONE ELSE. As such, Milinkovich's snipes at Sun go virtually unanswered. Particularly sinister are the veiled accusations (that a smiley does not excuse) that Sun might 'astroturf' the survey, casting unjustifiable suspicion on Sun's ethics. We should question eWeek's ethics for posting this article in the first place. Does Mike have your marionette strings, Daryll? This kind of yellow journalism is unacceptable. How about taking some responsibility, please?

This article is not news, and does not belong in the news section of a supposedly reputable news source. eWeek should be ashamed.

Yes, Eclipse probably does dominate the IDE market in terms of popularity, and I have no problem with that fact being reported far and wide, as long as it is reported fairly and open-mindedly, based on reputable sources. And you know what? The IDE popularity war is long over. Been there, done that. The much more interesting story is that there is a lot of really cool innovation still going on in the IDE market. Friendly competition is the new thing driving the industry. Real innovation is interesting. Flakey posturing is boring.

(Full disclosure: I am currently employed at JetBrains, makers of IntelliJ IDEA, which competes with Eclipse. This post is not a diss on Eclipse, it's a diss on eWeek.)

IntelliJuei

2006-01-20T20:53:00.000+01:00

I thought the caption for this photo on Flickr was hilarious:

And then I realized he has dual widescreen monitors. DROOOL. I don't even have one widescreen monitor. I should look into that.

Now or Never

2005-11-09T16:40:00.000+01:00

For several years, I've had a particular software product idea in mind, but always figured it would be one of those things where you're 50 years old and go, "Yep, that was a really good idea. Someone could have taken that idea and built a good solid product out of it and probably have gotten rich. Yep, too bad no one did it." Man, that would really suck if that was me when I turn 50. Well, it turns out that no one else has run with this idea, and the market window is still open, but closing. I guess it's now or never, and I decided to take a chance and go for it. So, I recently quit from JetBrains and I'm now working out of my apartment on the new product. (I owe at least some inspiration to Paul Graham's essays on startups.)

Working at JetBrains was great and I take away a better understanding of what it takes to make a great software product. It was great to work with such talented people, and to participate in the IntelliJ community with all it's fantastic people. I'll still be participating, just in a different way, and maybe a little less often. And I'll always be a fan of JetBrains and its products.

It's funny, almost every single person I tell about this has the exact same question, "So, can you say what product you're building, or is it a secret?" I think the whole 'stealth mode' thing is bogus. If your startup idea is so easy to copy that you have to keep it a secret, then I think you're in for a rough ride with the competition. I think it's much more sensible to refine your 'pitch' with people who are curious, but don't really care one way or the other. On the other hand, this blog is quite public, so revealing too much could alert the real competition that they should be wary. On the third hand, if the idea is good enough, the competition is likely to be complacent and scoff at your idea rather than take it seriously. So, with that in mind...

The product is a software tool for pharmaceutical companies to build dynamic sales presentations with. Kind of like a cross between Powerpoint and Excel. There, that should appease the casually curious without giving away our 'secret sauce'. :-)

Why Are Continuations So Confusing, and What Do They Really Do?

2005-10-31T22:52:00.000+01:00

I recently watched a video trying to explain, in simple terms, what continuations are. The quick answer was "Continuations are just the remaining work to be done." WTF?! I had been wondering what the heck continuations were, but this answer gave me absolutely no clue. Oh! Of course! The remaining work to be done! It makes complete sense now. Unfortunately, this is one of those explanations that only makes sense if you already understand what is being explained. Kind of like 'a Java classpath is just the set of paths where all your classes are'. Completely useless to you if you don't already get it. Even the examples in the video confused me. I sort of got it, but not really. So I started digging into Ruby to see if I could figure it out, given the sparse clues I already had, and you know what ... continuations are so freaking simple that it boggles my mind why it was so difficult to understand them. Correction: It doesn't boggle my mind; I know exactly why continuations are confusing. And so, I hope to once and for all cut through all the confusion and explain what continuations are, and how to use them, in actual simple terms.

What are continuations?
That's actually the wrong question to ask. The answer will probably confuse you more than necessary. The better question to start with is:

Why are continuations so confusing?
The answer is quite simple: Wrong metaphor. The word 'continuation' provides no clue as to what it does. In fact, it describes its implementation rather than its purpose. So, it is necessary for you to understand the implementation before you can understand the purpose. But for someone new to continuations, this is completely backwards! We want to understand what continuations are for before we understand how the implementation works. Could you imagine if a class' methods were called 'virtual table entries'? Or if floating point numbers were called 'exponentiated mantissas'? Of course, the implementation is important to understand to become an expert, but I shouldn't need to know exactly how an internal combustion engine works just to drive a car.

What do they really do?
You know, I'm not even going to bother calling them continuations anymore, as that's a complete red herring. I'm going to explain to you a brand-spanking-new concept called 'execution sites'. Execution sites allow you to specify (or mark) a point of execution in your code, and store a representation of that site in a variable so that you can return to the original site later. Not only that, but it allows you to pass information back to the original site, so that it evaluates to a different value. I'll explain how this works with some simple Ruby code. (Note that the code below will not work in plain old Ruby. It requires some simple definitions which I'll provide at the end of the article. You can, for now, pretend that this is 'wishful' Ruby, or Ruby-as-I-would-like-it. I'll also use some redundant syntax to make the code more natural to non-Rubyists.)

I need to be able to mark my execution site and store it in a variable, like this:

theSite = mark();

'mark' is a special keyword (again, not in real Ruby, but in wishful-Ruby) that captures the site of execution, wraps it in an object, and returns it. 'theSite' is simply a local variable where we store the site. Later on, we can return to the site by using the 'return' method of the site object, like this:

theSite.return();

Here's a 'hello world' type of program that uses execution site marking:

theSite = mark();
puts "Hello, World!"
theSite.return();

This code performs an infinite loop, outputting "Hello, World!" over and over. You may be familiar with labels and gotos from other languages, which allow you to do something very similar to this. Here's a simple script to demonstrate how gotos and labels work:

:theSite
echo Hello
goto theSite

"So, an execution site is like a goto label?" Sort of, but actually more powerful. First, you can store an execution site in a variable, array, object field, or whatever, so it is more like an object than a label. Second, labels typically are limited in scope, depending on the language. For example, you usually can't goto from one method/function to another. With execution sites, you can return from deep inside some arbitrary code, back to wherever the site was marked:

# Method definitions
def startloop
 startloopSite = mark();
 puts "Inside startloop";
 return startloopSite;
end

def endloop(startloopSite)
 puts "Inside endloop";
 startloopSite.return();
end

# Main execution path
theSite = startloop();
puts "Middle of the loop";
endloop(theSite);

This code will output "Inside startloop", "Middle of the loop", and "Inside endloop" over and over again. Notice that the main code execution path goes into startloop, marks the execution site, outputs "Inside startloop", and then returns the execution site. So, later, when endloop calls 'return' on the execution site, code execution goes right back inside startloop and outputs "Inside startloop" again. The site always returns to where it was marked, no matter where that is. Simple, but potentially much more powerful than a plain goto label.

The third major difference between labels and execution sites is that execution sites remember everything about where they were marked, whereas goto labels are more 'global' in this aspect. A label only knows where it is declared, but when you mark an execution site, it remembers how the execution path got there (such as the method call stack) and also what local variables have been declared up to that point. In essence, it stores the complete execution state in a little object so that you can return to that same state at any point in the future. Here's an example:

def remember(aValue)
 theSite = mark();
 puts "The value is " + aValue.to_s();
 return theSite;
end

siteToReturnTo = 2;

# Remember the values and execution state
firstSite = remember(1234);  # Line A
secondSite = remember("ABCD");  # Line B

puts siteToReturnTo;

# First go back to secondSite, then back to firstSite, then quit
if (siteToReturnTo == 2) then
 siteToReturnTo = 1;
 secondSite.return();
elsif (siteToReturnTo == 1) then
 siteToReturnTo = -1;
 firstSite.return();
end

This code outputs the following:

The value is 1234
The value is ABCD
2
The value is ABCD
1
The value is 1234
The value is ABCD
-1

The first two lines of output come from the first time the 'remember' lines were executed. Inside the 'remember' method, the parameter 'aValue' takes on different values depending on what was passed. Note that the execution site is marked inside the 'remember' method, so the site will remember the value assigned to the 'aValue' parameter, as each call to the method essentially creates a separate variable called 'aValue'. So, essentially, 'firstSite' remembers that 'aValue' is 1234, and 'secondSite' remembers that it is "ABCD". Not only that, but firstSite remembers that the 'remember' method call should return to Line A, and secondSite remembers that it should return to Line B. So local variables, the state of the call stack, and even the exact location in the code are all remembered when an execution site is marked.

When secondSite.return() is called, execution jumps inside the 'remember' method, where 'aValue' has the value "ABCD", and the 'remember' method will return to Line B. Hence, we get the fourth line of output, "The value is ABCD". By this time, our switch variable, 'siteToReturnTo' has been updated to cause firstSite.return() to be called. When this happens, execution jumps again into the 'remember' method, but this time 'aValue' has its original value of 1234, and the method call will return to Line A. (Note that firstSite and secondSite do not remember that 'siteToReturnTo' was initially given the value of 2. Sites remember the variables themselves not the values of the variables. The fact that 'aValue' exists as a local parameter inside the 'remember' method makes it act like two distinct variables, one for each method call, which happen to have the same name. It's a subtle distinction, and important to keep in mind. Those familiar with closures and code blocks in Ruby should have no trouble with this.)

Now, this is all fine and dandy, but doesn't this make execution sites seem like glorified gotos? In essence, that is very much what they are. Dijkstra's advice should be heeded: Goto Considered Harmful. Marking execution sites for the purposes of using them like gotos sounds to me like a recipe for spaghetti. I like spaghetti for a good meal, but not in my code! I really believe that execution sites have the potential to royally mess up your code, so I don't recommend using them without a very good reason. I would say that it is unlikely that most programmers will code directly with execution sites. Instead, it is more likely that they would be useful for specialized frameworks and services to give concise ways to express complex solutions to problems. However, that shouldn't stop you from playing around with them to get a solid feel for what they do. Hey, maybe you'll be the one writing that cool framework or service that uses execution sites.

What's the big deal?
There is one last capability of execution sites which I've been holding up my sleeve. I think this is what makes them truly powerful and useful, and worthy of taking the time to understand them. I'll be honest and admit that I personally can not think of very many practical uses for execution sites, although some very practical examples exist. I imagine that I'll start to see practical uses as my understanding improves and my imagination catches up with me (as happened to me with closures and macros). In any case, the final capability:

So far, you've seen that execution sites can mark a place in code execution that can be returned to at some later time. Wouldn't it be great if they could also return some useful information back to the original site? Then they could be used as a way to 'hold' a calculation until future information is available that can allow the calculation to 'continue' (Hmm, there's that word 'continue'.... I wonder if there's a connection to continuations? Patience, please. :-)

Maybe, in wishful-Ruby, it could look like this:

tryForBetter = true;
theSite = nil;
theCalculation = mark() { |site|
 theSite = site;
 # Do some work to get an initial value for the calculation
 initialCalculation = 3;
 theSite.return(initialCalculation);  # Line A
}

puts "The calculation is " + theCalculation.to_s();

if (tryForBetter) then
 tryForBetter = false;
 # We discover a better value for the calculation
 betterValue = 3.1415;
 theSite.return(betterValue);  # Line B
end

This usage of 'mark' is significantly different than the simple usage of 'mark'. In the simple usage, 'mark' returns the execution site itself:

theSite = mark();

In the new version, 'mark' returns a value, and the execution site is provided as a parameter to the accompanying code block. This syntax structure allows us to return different values in the future. The execution site is merely a book-keeping tool that we use to provide this capability.

The first time through the code, 'mark' captures the execution site, and then executes the code block. The code block is given the site object as a parameter, called 'site' in this example. We store the site object in the local variable 'theSite' so we can use it later. Then we return an initial value. This initial value becomes the value of the 'mark' expression. Note that the code block is only executed once, when the 'mark' expression is first evaluated. You can think of the code block as the initializer which performs book-keeping (storing the execution site object for future use), as well as producing an initial value for the 'mark' expression.

Thus, the initial value of 'theCalculation' is 3, because that's the value determined by the block, specifically by the expression theSite.return(initialCalculation) on Line A. So the first line of output is "The calculation is 3".

Since the site object is stored in 'theSite', we can essentially go back and change the value of 'theCalculation' by passing in a different value to return on Line B. Now 'theCalculation' gets the value 3.1415, and the second line of output is "The calculation is 3.1415". If we wanted to, we could keep using the site object to return successively better approximations of pi. This is admittedly a trivial example, but hopefully it will give you a spark to let your imagination consider the possibilities.

Summary

So that's it. An execution site provides three things: A way to mark a specific point in execution, including all the important context; an object which represents the execution site so you can store it, use it, abuse it, or what have you; and a mechanism to return back to the site mark, optionally returning some useful information.

"Wait a second, you've just told me about 'execution sites'. You just made that crap up. I want to know what continuations are, you jerk!"

Whoah, whoah, no need to be upset. It's very simple, really. A 'continuation' is an 'execution site'. You create continuations using a special command named 'callcc', which works exactly like the value-returning version of the 'mark' command, and you can return to the location of the 'callcc' by invoking the 'call' method on the continuation object. All I've really done is give better names to the concepts, 'callcc' becomes 'mark', 'continuation' becomes 'execution site', and the 'call' method becomes 'return'. Oh, and I also provide a simplified way to mark sites where you don't care about the return value and only want to capture a continuation (oops, I mean execution site). In fact, it's so simple there are only a few lines of Ruby code which will transform Ruby into wishful-Ruby:

class Continuation
 alias_method :return, :call
end

def mark &block
 if block != nil then return callcc(&block) end
 theSite = nil
 callcc{|s| theSite = s}
 return theSite
end

So, wishful-Ruby code that looks like this:

theSite = nil;
aValue = mark { | site |
 theSite = site;
}
...
site.return(someValue)

Looks like this in normal Ruby:

theContinuation = nil;
aValue = callcc { | cc |
 theContinuation = cc;
}
...
cc.call(someValue)

In other words, continuations are cryptic and nearly incomprehensible. Still not satisfied? Okay. Fine. A continuation is just a reification of execution context. Or, in 'simple terms', a continuation is just the remaining work to be done. But you already know that now, don't you?

Now if someone could just explain to me what monads are....

IntelliJ IDEA interview transcript

2005-09-27T19:36:00.000+02:00

By request, here's the transcript of my interview on the Java Posse podcast, about IntelliJ IDEA and the Java IDE market in general (Eclipse, NetBeans, etc.):

Java Posse: Hi, and this is Dick Wall, for the Javacast, interviewing Rob Harwood of JetBrains. Today we're going to be talking about IntelliJ IDEA, an alternative IDE to the big boys that are out there, in particular Eclipse and NetBeans, right now. Hello, Rob.

Rob Harwood: Hi there.

JP: Can you tell us a little bit about your background and experience? Are you, or have you been a developer, and what do you do at JetBrains?

RH: Yep. I've been a developer for six years. I had a computer science degree. Around three years ago, I was looking for a better Java IDE, because I was using -- I think it was -- JBuilder at the time, and I wasn't happy with it, and discovered IntelliJ IDEA by JetBrains, and I liked it so much I bought my own copy. Another thing that I should mention is that I was a fan of agile methodologies, and so when I saw IntelliJ IDEA, I was very impressed by it, and I wanted to find the company that made it and try to get a job with them. So that's what I did, and I joined JetBrains as a programmer. I did a little bit of work on IDEA itself, but I mostly did internal projects. And so, then I moved on -- just recently actually, I just moved on to what I would call technical marketing, which is I'm actually more of like an expert user, and I use that knowledge to help educate about IDEA.

JP: You sound like an American, but you're --

RH: No, I'm Canadian.

JP: Oh, Canadian, I apologize. But, you're living out in Prague right now, is that correct?

RH: That's right. Yeah.

JP: Okay, how do you like it out there?

RH: It's great, I like it here. It's a nice change from North America, I'll tell you that. It's a lot more relaxing out here, I would say.

JP: Yeah, I've heard that it's a very beautiful city, actually.

RH: It is, yeah.

JP: So, can you sum up IntelliJ IDEA? Tell us a little bit about what sets it apart from the competition, like Eclipse and NetBeans.

RH: Okay, well, it's a Java IDE. But I think I should give a little bit of history, to kind of set the stage, in case some of your listeners aren't familiar with it. So, around 2000 or 2001, Java IDEs were kind of standard, and Sergey Dmitriev, who is one of the three founders of the company, decided that he wasn't quite happy with the situation. He had previously worked at TogetherJ. And so he wanted to create a new IDE that had much better code search, code navigation, and also something called refactoring, which I hope most of your listeners know about. It's being able to modify code without changing its behaviour, to improve its design. So, in fact, Sergey and two other founders joined together and they finished writing this IDE, and it was the first IDE with the Extract Method refactoring, which is what Martin Fowler calls 'crossing the refactoring Rubicon'. So, it had a little gathering of, kind of, fans, I would say. And in fact it won a Jolt Award one year, and then the next year, I think, it won the Jolt Productivity Award. And so, based on this and its success, other IDEs started to add refactoring and all these other productivity features. So the thing that sets IDEA apart is that it's focused specifically on developer productivity. And I usually say that productivity is achieved, in this case, with intelligent features and usability. And the difference is that IDEs like NetBeans and Eclipse, they actually start out as application platforms, plug-in platforms, and the IDE is kind of like the showcase application for it. So they start out as platforms and build an IDE on top of that, whereas IDEA is the other way around. It starts with the IDE, a heavily integrated IDE, and it builds out modular parts of it as we find ways to do that. So, the motivation is different, and also the architecture is different. Eclipse and NetBeans start from the basis of modularity, and IDEA starts from the basis of integration and adds modularity as it's needed. For instance, for adding plugins for version control systems, and now we have a new Language API for adding support for different scripting languages, and that kind of thing. So we have a modular architecture, but it's not from the modular side. It's not starting from modularity.

JP: Okay. Do you think there are any other major strengths of IDEA worth mentioning at this point at well?

RH: Well, definitely. I haven't really gone into much detail yet. So, I would say the primary things are based around usability and intelligence -- and again this goes back to productivity. We add features when we see that it will add to developer productivity. So, good examples of that are: Code navigation, for navigating your Java classes and XML files, and all that; code assistance, like code completion and generating code like constructors and getters and setters, and things like that; also, especially refactoring, which IDEA has very complete refactoring. There is also a fairly new feature in the last couple of years, is static code analysis, primarily the code inspections and on-the-fly error highlighting, which is something that is not really well known yet, but I think in the coming year or two, people will start to see the advantages of this feature. And also IDEA is heavily integrated for J2EE and web applications, as well as other things, but I mean I could just go on forever, so I think I'll leave that.

JP: Right. What do you think, if anything, the weaknesses are in IDEA?

RH: Well, it depends on your perspective, so I'll pick a couple of perspectives. One is, let's say, performance. It's not a text editor. It's a full-blown IDE. So, in some ways we trade off performance for things like building caches of information so we can do intelligent code searches, and highlighting of errors and potential errors, and that kind of thing. So, in some ways we're trading off raw performance for usability and intelligence. But, on the other hand, we treat performance as a usability feature, so if performance is not good enough, we definitely address that. So what you end up with is a well-performant IDE, but it's not going to be able to handle huge files, like 5 megabyte files, or something like that. It's not a raw text editor.

JP: Okay.

RH: And also the other one that I should mention is extensibility. As I said, we start from integration and we build in modularity as we go along. So, IDEA doesn't have as many plugins as other IDEs, but it does have a lot of built-in features. The other thing is that, because we're building in modularity piece-by-piece as we go, I would have to admit that sometimes the documentation is not that great for the Open API that we have. It can be difficult for someone to get started. However, we're looking into that. We have someone dedicated to working on the documentation, and we have already built -- it's a plugin development kit to help you kick-start your plugin development for IDEA.

JP: Yeah, as a developer, I would say that the documentation is never good enough for anything.

RH: One more thing, just to be fair, I think I should mention, to compare to NetBeans and Eclipse, the two obvious ones are: It's not open source, and it's not free. That would be a weakness, but, you know, it's a trade-off, right?

JP: Right. I think we're going to hit that a little bit later in the interview a little more anyway. Okay, so heading back to the main topic here. I guess the big gorilla in Java IDE space right now has to be Eclipse. Many people seem to think NetBeans is the main competitor to that, albeit somewhat smaller in terms of market share, right now. Why do you think that is, and why do you think that IDEA is not a bigger force in the marketplace right now?

RH: Yeah. So, Eclipse is definitely the gorilla. And by gorilla I'm using the terms coming straight out of Geoffrey Moore's popular books Crossing the Chasm and Inside the Tornado. You can see this in pretty much any industry. You get kind of a breakdown of who's the big heavyweight, and who are the two or three competitors who are providing alternative choices. Usually, the main one is called the gorilla, which is the most popular, the default choice, the one that has the most support from the community. But there's always competitive choices, and these are actually called chimpanzees, in Geoffrey Moore's terminology, or chimps. So, I would have to say, we are the adaptable and intelligent chimp in competition with the 800 pound gorilla. And the reason for that is pretty much that we started out as -- it's like the two guys in the garage kind of story, except this time it was three people in Prague. We started out from pretty much nothing, and all of our marketing, up until recently, let's say, a year or two ago, has been through word of mouth. So, people telling other people that they like it, and get their friends on it, and show it to their friends, and that kind of thing. Whereas, something like Eclipse or NetBeans, which is backed by a large company, they have the capabilities to provide a lot of extra support like extra websites and marketing money and ads in various magazines, and whatever. So, that would be one of the main reasons. The other one obviously is cost. And the third one is obviously open source, the fact that NetBeans and Eclipse are open source. So they have the kind of default attraction to most programmers.

JP: Okay. I think one more possibility, certainly one that I hear spoken about a lot, is a lot of people like Eclipse because of SWT. Now, I'm not going to go into my own views on this particular one, but that does seem to be a draw to the Eclipse platform, is the SWT IDE construction toolkit. Does IDEA have any kind of SWT compatibility, and what do you think of SWT compared to Swing?

RH: Well, I gotta say, this is somewhat of a religious topic, and to be honest, I don't have a lot of experience in GUI development, so I won't really provide my opinion on SWT or Swing. What I can say is what I see from the marketplace. I see SWT as kind of like the C# versus Java. So C# made a big appearance, and had a lot of interesting features, and for a while it was a little bit embarrassing for Java. But the thing is, Java didn't really stand still. Sun updated it to cover the big differences. You know, it's like competition; when you have no competition, things kind of stagnate, right? So, C# is providing competition for Java, and in the same way, SWT is providing competition for Swing. And I think that -- Personally, I think that Swing is so deeply embedded all over the world, and in so many projects, and so deeply embedded in the core JDK that I don't see SWT as -- I think it's probably going to slow down in its popularity, and I think Sun will update Swing to compete more with SWT. For me personally, the advantages of SWT that are promoted, like for instance operating system fidelity, and speed, and all that kind of thing. For me, those aren't that important because it's possible to build good interfaces in both of them. And I think both NetBeans and also IntelliJ IDEA are good examples of that. They both have good interfaces, and, you know, I'm biased, but IntelliJ IDEA blew me away when I first saw it, and it's written entirely in Swing. So, for me the most important thing is usability. Can you build a usable interface with it? And the answer is yes to both of them. So, that's what I think, basically. In terms of IDEA's support for SWT, it's basically a class library, so you can definitely write SWT applications in it, but there's no specific support like a GUI builder or anything like that. We have a GUI builder, but it currently only works with Swing.

JP: Okay. Staying on the UI for a minute, the upcoming -- I don't know if you've seen this, but the upcoming NetBeans 4.2 has a UI builder in it called Matisse, and that's based on something called the Natural Layout Manager. Have you looked at these at all, and do you think that Natural Layout Manager support, similar to NetBeans will be included in a future release of IDEA?

RH: Yeah, in fact, I had heard about it, but I hadn't looked at it until you sent me the questions. So, I did, I looked at the demo. I didn't download it, I didn't try it myself, because again, I'm not really experienced enough to evaluate a GUI builder type of thing. But it appears to me that Matisse seems to be targeting ease of use compared to hand coding code. And I think that's a good idea, because the weakness of Swing, and probably even SWT, again I might not be accurate there but -- I'll just say with Swing then -- the weakness of Swing is that to get a decent UI requires a lot of work, you know, hand coding. That's why people use GUI builders, but the GUI builders recently have mostly been kind of just adjuncts to hand-coding, whereas Matisse seems to be targeting more like a quick, usable GUI builder, in comparison to say VB or some form builder from Microsoft. I think that's good, and I think it's needed. I was quite impressed by the demo. I would say that when we add support for third-party tools, we do it in a pragmatic manner. So, if there's a good use case for adding some feature to IDEA, we add it. And usually that means that there's some customers who are asking for it, and some special integration would significantly increase developer productivity. Also, the tool should be fairly stable, and kind of like a de facto standard, usually. So, if something, some tool, meets those criteria, we'll definitely add it to IDEA. If it doesn't, then we do have an Open API, and someone else, some third party, could add it as well, as a plugin. For example, IDEA comes with JUnit support, because JUnit is the de facto standard for unit testing. We don't have built-in TestNG support, but a few IntelliJ community members, Mark Derricutt and Hani Suleiman, they wrote a plugin for TestNG, which is a competing unit testing framework. Also, IDEA comes with Ant, because that's the de facto standard build tool, but say Maven requires third-party plugins. So, basically what I'm saying is, if there's sufficient support for Matisse from the community and it's a solid tool, et cetera -- I think right now it's a pretty early tool. So, I can't see in the short term that we'll be directly adding support for it. But, you know in the long term, we might. Also, we do have our own GUI builder, and we'll probably be taking 'lessons learned' from Matisse and applying it to our own GUI builder, as well. But I mean, there's nothing stopping us from adding support for Matisse, whether or not that is just the Natural Layout, or whether it's the actual GUI tool itself, it's hard to say.

JP: Okay. As listeners will know, we've had -- in the course of the previous Javacast episodes, we've had some pretty extensive discussions on component-based development versus, I guess, traditional, more editing-based development. I just wondered what yours and JetBrains' stance on the component based development model is. And is it a focus in IDEA? Is it likely to become a focus in IDEA?

RH: I think when I originally heard the Javacast that I had responded to, I was probably a little bit confused about what you meant by component-based development and I think I took the wrong interpretation. What I think, actually, is that, when Brandon says 'component-based development', I think he means a couple of things. I think he means -- there's basically three things. One is pluggability. What's a component? It's almost like a plugin, right? The other one is kind of like the wizard-like functionality or the usability -- you know, providing a tool to help you get past the set-up configuration. The other one is kind of like the big tool that does it all for you. For instance, Sun Java Creator Studio, which is a tool for getting beginners, and experienced folks as well, but basically to provide all this support for you. So, in terms of that, I'll answer three different questions. What is IDEA's focus on all three of those situations? So, again, it comes back to the pluggability, where, yes, we do have an Open API, but that's not our number one priority. Our number one priority is being the best tool for Java and J2EE development. And in that sense, we are not really component-based, and that's what I originally had thought Brandon meant when he was talking about that.

JP: Right.

RH: But, in terms of the other two, which is the usability, you know, being able to click Next, Next, Next, like Brandon was talking about. That is basically a major feature of IDEA, being able to quickly and easily do things like creating a new class, or you know, just anything. We try to build in as much usability as possible in our tool. However it is more for like hand coding, right? So, in terms of the big tool that does everything for you, that's not what IDEA is about. So, our wizards -- I think we only have one or two. We have a project creation wizard, and I think there's another one, but I can't think of what it is. So, we don't really have wizards so much as like dialog panels that help you quickly do something, and it's all keyboard supported, so you quickly do something like extracting a method, or adding a parameter to the method, or something like that. So, in terms of the big tool, that does everything for you, IDEA's not going to become that. But we do have another product called Fabrique, which we're working on, and it's idea is similar to the Sun Java Creator Studio for helping to make web application development easier to do by using a tool, as opposed to something like a framework like Rails or Struts, or something like that, which is supposed to help you in terms of productivity by providing tools for hand-coders. But this one is more for quickly developing using a GUI tool to help you do websites.

JP: Okay. Alright, let's move into some of the more fun stuff, architecture in particular. IDEA has strong support for J2EE and EJBs. Can you talk a little bit about that?

RH: So, in fact, IDEA 4, I believe it was 4, started to introduce support for J2EE, and IDEA 5 has really made that its major focus -- this is the latest version of IDEA. First of all, in IDEA 4, we had EJB configuration tools to help you with that. There was support for some refactoring, for renaming things. There was some support for JSP, and HTML and XML, but it wasn't quite integrated. So what we did was -- IDEA 5 has a lot more support, especially on the web development side, especially with JSPs and embedded CSS and JavaScript and HTML and the JSP 2 expression language. What we did to do that is we introduced a Language API, which allows anyone to develop plugins for any language, and you can add support for some refactoring, code navigation, finding usages, and highlighting usages, and syntax highlighting, and all sorts of stuff -- and inspections, and that kind of thing. We did that, that was a major undertaking for IDEA 5, and that will be the foundation for our future J2EE development support. We also have support for WebLogic and Tomcat integration built-in, and there are others available, and you can add support for any generic web app server. I think there's some JSR to cover the compatibility there, and we follow that spec. And I think that's about it.

JP: Great. What do you have now, and what do you have planned for EJB 3.0, the upcoming EJB spec, in IDEA?

RH: Well, we haven't decided yet. A lot of our developers are on vacation right now. But we will definitely support the EJB 3 spec. And the question is really, what exactly, how exactly we'll support it. I would have to say, or guess, that it will include some EJB-aware refactorings and navigation and configuration, helping you with the different annotation, and providing inspections about the proper usage of EJBs, and that kind of thing. So, this is a work in progress, and I don't know, is the spec even finished yet? I'm not aware of that.

JP: It's getting pretty close. It's in the final draft stages and stuff like that. JBoss and Oracle both have preview editions out there to mess with right now, but it's not finished yet.

RH: Well, when it solidifies, we'll definitely look into how we can support that. It will definitely be part of IDEA.

JP: We also had Bruce Tate on for a really fun interview in the last episode, and he was pushing alternate simplified frameworks like Spring and Hibernate, in that. I wonder, does IDEA have any support for that? Are there any plugins that allow you to do Spring and Hibernate and alternative frameworks in IDEA?

RH: This has currently not been a primary focus of IDEA. We do have some small support for Spring, which I can't recall exactly what it is, but we do have some small support for Spring. I think it's some sort of reference linking, being able to navigate, or something. I'm not sure exactly. But there are third-party plugins. All of them are free, that I can think of. For instance, there's Live Templates for Hibernate, for writing your XDoclet tags. There's a couple of plugins for Spring. One is Spring Console, which I think works in any IDE. The other one is called IdeaSpring, which can be downloaded directly from IDEA's plugin manager, and that offers some features like configuration and navigation like jumping to declarations and for ref and alias tags, and that kind of thing, and auto-scroll from source. And that's being developed, also I think that's from someone in our IntelliJ community, has developed that.

JP: Great. Actually Bruce spoke very highly of IDEA. That's his IDE of choice. I just thought I'd throw that in. We had a brief conversation prior to the interview about that, and he really likes what you guys are doing.

RH: Oh, I should mention that I met Bruce Tate at JavaOne 2004. He was there, he had his book, Better Faster Lighter Java, and he signed a copy for me. So that was fun.

JP: Oh great. He's a nice guy, great guy to talk to actually.

RH: Yeah, he's great.

JP: Okay, so you've mentioned a couple of times that IDEA does refactoring very well. Can you give a couple of brief examples of refactorings that are possible in IDEA, but not in other IDEs like Eclipse.

RH: Okay. It's kind of a case of, you know, if you compare feature by feature, then in most cases, Eclipse has many of the features IDEA has. But that's not what keeps people coming back to IDEA. It's not a feature list thing. I really believe that it's not so much about feature lists anymore. It's more about usability, and productivity. There are a couple IDEA-only refactorings, but I'll just briefly mention them, because I don't think that's the key to understanding what IDEA's about. So a couple are: Change Class Signature, if you have a generic class and you want to change the type parameters, the order of the parameters, or how many there are, et cetera. There's Safe Delete, which is being able to delete any class or any file you want to delete, without -- it checks first if there's references. There's being able to Replace Method Code Duplicates, so if there's a method existing in your class, and then many parts of the class also duplicate the functionality of that method, you just call this refactoring and it will replace all of those parts with a call to the method instead. There's Extract Superclass, which allows you to create a class in between two classes in a hierarchy very quickly. But I think that's not really the important difference here. The difference that I think is most important is how usable and how productive are these refactorings. So, the major differences there that I see is in, say, Eclipse, that if you have errors in your code, let's say you have a minor syntax error in some method, you can't rename that method. If you have a missing semicolon or something. You have to fix all the errors and then you can do your refactoring. For me, that is a major difference. You really have to try it to see what I mean, because if I just talk to you about it, it doesn't seem to sound very important, but so many times I've tried to use Eclipse, and I just get completely frustrated when there's some minor error somewhere, that I forgot to finish typing a name, but I want to extract some variable or method or something, and it won't let me do it. It says you have to fix the errors first. It completely gets me out of my flow, and I have to think in a different context, I have to switch contexts. Also, Eclipse is a little bit more unsafe than IDEA. For instance, you can't always undo refactorings, and when you can, sometimes it requires you to undo in every file the refactoring that was effected. Often times, you need to manually fix code after refactoring in Eclipse. We have some examples of that, but I can't think of them off the top of my head. We have more mature refactorings, like for instance Move Method. Move Method will handle cases such as inner classes in IDEA, where that is not handled properly in Eclipse.

JP: Okay.

RH: So, basically what I'm saying is that, it's not a matter of, you know, checking off, feature by feature and saying "Oh, this feature list is longer than that one," because that's not what's really important. What's important is, when you're developing in your day-to-day, you know, everyday programming time, that you want it to be as productive as possible. You don't want to be wasting time trying to fix the IDE's problems. The IDE should be fixing your problems. So, what else is there? Yeah, there's some other minor differences, but really it's the productivity that I think should be emphasized.

JP: Okay. I think that probably covers the majority of the next question I had, which was the question about the difference between -- or the benefits of static code analysis versus the automatic compilation on save that Eclipse has, and I think that probably rounds that off, unless you've got anything you want to add to that.

RH: Actually, I don't think it covers it at all, really.

JP: Oh, okay.

RH: This is one of these, kind of -- what do you call it? Like a 'diamond in the rough' feature. Unless you've seen it, it's really hard to explain what's going on. But I'll try to explain as best as I can. So, IDEA has 500 static code analysis, let's call them modules, or features. So, compiler errors are one thing. Eclipse, when you save, it automatically compiles, it lists certain errors. Most of those are compiler errors. Eclipse has about 30 other errors that it will -- not necessarily errors, but problems, that it will show up. But IDEA has 500, and these cover such a wide range of topics. It's not just possible errors, but it's things like internationalization issues, JUnit issues, J2ME issues, performance issues, serialization, threading, all sorts of stuff. And on top of that, it has some really great stuff, like there's a new inspection for highlighting in your code possible NullPointerErrors. We use a special annotation for that, for Java 5. It does things like code style issues. So it helps you highlight instantly in your code if you're violating some naming convention. Or say you're in one package, and you accidentally use a class in another package, and your project design has been set up by your team in such a way that you're not supposed access that package from the other package. That's a package dependency violation. So we have an inspection that will highlight that automatically. You just configure the package dependency rules that you want to set, and it will highlight that. Also it will show you a lot of redundant code things, like redundant if statements. This loop doesn't do anything, or redundant assignments of variables. So if you say like, a = a;, which sometimes happens when you intended to assign a field the value of some parameter, and you say 'field a equals a', but you forgot to put this.a, so it'll highlight that problem. And there's so many others, that it's just really -- this is one of the killer features of IDEA, and you really have to try it and see it to understand how it helps. What the basic benefits of this is that it drastically reduces common errors. It won't find major design errors, but it will find some design errors, like I said with the dependency violations, but also some class abstraction issues, or if you have encapsulation problems, like if you're exposing too many fields or something like that. It also helps you with things like migrating to Java 5. For instance it'll highlight for loops that are using the old style for loop and show you that you can replace this for loop with the new type of for loop. And in fact you can do it just by hitting one key and pressing Enter and it will automatically replace it for you. So a lot of these inspections are also attached with what's called a Quick Fix, which is different than the Eclipse Quick Fix. First of all it highlights in your code, and the Quick Fix will let you quickly apply whatever solution is suggested. First of all you reduce common errors, second you help improve your design, and the great thing about this is you do it as you go. So, you're working on your class, and you see all these things highlighted, you just clean up as you go. It's kind of like refactoring as you go. It's just something you should do as a continuous process. So, instead of waiting once a week and having a code review, you can have an 80% code review all the time, and then once a week you can have a code review to cover the rest of the 20% that automated code inspections can't handle. So, it saves you time, saves your time in code reviews, saves you time dealing with errors. I would say this is IDEA's killer feature, at this point.

JP: Okay. I have seen some capabilities from PMD analysis plugins available for other IDEs, but I do think, from the sound of the description you just gave, it does go a fair bit further than those. That's good.

RH: Yeah. The difference is, PMD does have more checks than Eclipse, but IDEA's is more complete, and PMD I don't believe it has quick fixes. It certainly doesn't have as many as IDEA's has. And IDEA's, it's all built into the editor, so these things work with all sorts of various things that PMD only, I think, only works on Java classes. For instance, IDEA's works in HTML files, and JSPs. You get all your same inspections in all your JSPs, if you have any scriptlet code in there. Also, it has CSS inspections. I could go on and on.

JP: Okay. Now we're going to move into the section of the interview where I've written some questions down that I kind of want to get some answers to as well.

RH: Sure.

JP: These will be a little more off the wall. But first of all, a particular interest of mine right now is scripting languages for the JVM. This is something I've found to be really very productive in recent projects. Particularly, Groovy is one that I've latched onto for its excellent XML and SQL support. I know there's a Groovy plugin for IDEA, because I was looking around recently to see what kind of capabilities it had, but at the moment it seems like it's limited mainly to syntax colouring and basically invoking the Groovy compiler. Are there any plans, do you know, to beef up scripting support for Groovy or other scripting languages? In particular, one of the things that I'm still waiting for from any IDE is a really good debugging solution for Groovy. So, any plans to do anything like that?

RH: Yeah. Our current plans are to support JavaScript as much as possible. And we provide this Language API, as I mentioned before, to allow other people to write plugins for other languages, and someone in our community has written the GroovyJ plugin, and it's more than just highlighting. I believe it also has code completion, and brace highlighting, and navigating between references, and this kind of thing.

JP: Oh, it may have moved on a little bit, since last I last looked at it. That's great.

RH: I think it has. It's using quite a lot of the Language API. And we're going to open up more of the Language API as we go, as we're able to make it more modular. Definitely, Groovy is going to be a big upcoming -- it's kind of like the competitor to Ruby on the Java side. So I think it's going to become pretty popular, and this will definitely be a major thing that we'll support. Basically, we'll be looking for people to write language plugins and have them give us feedback and tell us what problems they're having with the Language API, and what capabilities they need, and this kind of thing. So, we'll be developing the Open API, and other people will be using it. And we'll be using JavaScript as our internal test case for that. So, in terms of Groovy itself, as far as I understand it, Groovy classes are transformed into Java classes.

JP: Basically, the thing that really attracts me about Groovy is you can take virtually unmodified Java code and execute it under Groovy. But then you can start dropping out a lot of the type safety and using more of the dynamicism and stuff like that. But it also compiles up to Java classes. That, coupled with the good XML and SQL, are kind of the reasons I really like that particular scripting language right now.

RH: Right. So, in terms of that, I think there's the possibility -- and I was talking to Eugene Zhuravlev, who is one of our main developers, and he was telling me -- that if Groovy can generate debug info that meets the JSR 45 specification, then we can definitely add debug support to it. Now, it might not be possible right away in version 5, but we'll be definitely looking into this. It's something pretty important, I think, to this kind of support for these languages. So, you'd be able to set breakpoints and step over Groovy code, just like you would in JSP, for instance. We're definitely looking into that -- other languages. We're also looking into supporting XML-specific languages. There are so many different dialects of XML. I don't know if we've planned this specifically, but we're thinking of planning support specifically for XML languages to make it easier to create your own XML languages and provide IDE support: Refactoring, navigation, highlighting, and all that stuff, code folding, everything --

JP: Great.

RH: Reformatting. Other language that are possible are Python, Ruby. Regular expressions, I think we already have a plugin for that. XPath, we already have a plugin for that. And your own custom languages.

JP: Excellent. I look forward to that, seeing what happens there. Okay, we're going to get into an area where I've gotten myself into a little bit of trouble recently -- not just with you, a number of people have emailed me on this one. As a hobbyist developer, I work on the occasional small side project, and generally whatever I create -- saying I release it under the GPL is probably a bit grandiose, I usually push it out, let's see if anybody's interested, and it's GPL'd. It doesn't usually release as much as whimper and die. Anyway, given that, what options are open to me for using IDEA? Could I use the non-commercial license, and what would I have to do in order to use it?

RH: Okay. We do have an open source license, and there are some restrictions on it. First of all it has to be non-commercial open source, meaning it's not for profit, and also it has to meet the open source definition, it has to have a dedicated website, and an active community. As a hobbyist, it's not likely you're going to have a dedicated community if you just start right away.

JP: Right.

RH: It's not as broad as it could be, but it is available. I think at least 60% of the Apache -- is it Apache projects? I'm pretty sure. You can check our website. We have a page dedicated to that. Approximately 60% of the Apache projects using Java are using this open source license. And hundreds of other projects as well. And it's easy to apply, you just go to the website, you provide some information, and you get a one year renewable license for all the members of your project. But in terms of a hobbyist, we currently do not have a simple non-commercial license yet. I have considered that, and I'm kind of torn between the two possibilities as to whether or not it would be a good idea for our company in the long run to have a cheap, or a free. non-commercial license for everybody. But anyway, we're looking into that. In fact, I just read the other day an editorial by Rick Ross from Javalobby, who talks pretty closely about this subject. It was interesting to read his opinion, which was basically that it would be bad to do that, but I don't know, I'm torn. In my opinion, it could be a good idea, but we have to look into that.

JP: Okay. So basically the other option here is to actually -- for my hobbies, is to stump up the full price of $500. Given that, let's say I've got $500 and strictly this is, you know, for my own use, it's for messing around within my spare time. I have the choice of buying some hardware -- I actually went through this recently. Both my AMD 64 bare-bones kit and the Mac Mini I purchased recently came to about that amount. Can you make a case for me buying IDEA instead of one of those? Can you lay it out for me?

RH: Okay. So, in my personal opinion, that's really not an issue. $500? Yeah, it's a lot of money, but I mean, I enjoy programming and I want to use the best tools possible. So, in my personal opinion -- in fact, I did this when I was working at my previous company, I bought a copy of IDEA because my boss wouldn't buy it. I bought it with my own money, and I used it because I didn't want to use the other tools that were out there at the time. So finally my boss comes along and says, "You're using this? Isn't your evaluation expired?" I said, "No, I bought my own copy." And he's like, "Oh really? It's that good?" And I said, "Yeah, it's really that good." And so, he ended up pitching for licenses for the rest of the team. But anyway, that's my own personal experience. In terms of the general population, I would say that -- well, first of all there's one thing I should mention. It's not always $500, because we do occasionally, I think twice a year, we have a promotion for a Personal License, basically exactly what you're talking about, for half the price, so it's about $250, which, I don't know, that's really not a lot of money. And anyway, even if that is a lot of money for you, you can think of this analogy, which I mentioned to you in the email before. If you're a hobby bicyclist, and you decide -- you have a choice, you can ride in the city on a simple, cheap city bike, or you ride rough and fast on a mountain bike in the wilderness. You have a choice, what do you want to do? Some people are content riding in the city. They don't have a need to go on rough and fast terrain, right? So, that's an option, you can go for that. But, you know, you shouldn't expect -- just because there are city bikes that are out there that are cheap, or even used, you shouldn't expect bike makers, who make high-performance mountain bikes to make them cheap, just because there's cheap competition out there. What I would say is that, you have an option with IDEA. You have an option to try it for 30 days, see if you like it. And if you don't like it, you don't have to buy it. Or if you don't have the money, you don't have to buy it. It's kind of like, if you're happy with your city bike, and somebody says, "Here, you can try this mountain bike for 30 days for free. You don't have to buy it." Now the choice is, are you going to take that offer, or turn it down just because it has a price tag on it if you decide to buy. Personally, it would be a no-brainer for me. I would try it, because I like riding bikes -- or I like programming, and I want to see what the best tools out there are. Even if it's just to do some research for my professional job. I want to at least know what's out there. I try NetBeans, I try Eclipse, I try JBuilder, I try the other IDEs, and then from that knowledge I can pick the one that I like the best, and the one that suits me the best. So, that's how I would council people who are deciding. Try the IDEs, you can try them all free, and pick the one that you like the best. The other thing is that it's kind of like buying a Mac versus buying a Windows PC. People pay a little bit of extra money for a Mac. Why do they do that? It's because they enjoy using it. Even if you are just buying it for your own personal use, a lot of people they choose to buy a Mac because they prefer it. That's my opinion. I think that usability is a feature worth paying for, even if it's only for your own personal use. This is not a $5000 thing, it's not a $10,000 thing. It's only $500 and if you catch the yearly specials then you can get it for cheap for $250. And the last thing I'd like to say about this is that I think the reason I enjoy programming is because of something called flow, the mental state called flow. Your listeners can look it up on the C2 wiki, that's the original WikiWiki. It talks about this mental state you get in when you're highly focused, and even athletes have a thing called 'in the zone', which is very similar. You know, when you're deep in a problem in programming, and you're just chugging along, and you're just churning out code. It really is an enjoyable experience, and I think that's worth a little bit of my money to get that. And this is one of the things that IDEA focuses on, making programming so fluid and productive that you can get in flow, and you can stay in flow. It doesn't get in your way. It provides simple features that you can use at your whim. It gives you more control over the code. The more control you have, the more you can get into flow. It's like a programmer high. It's like a drug, in a way. It think this is why we have such loyal fans, because this is what it focuses on. It doesn't focus on being some platform for everything but nothing in particular, it focuses on being a Java IDE so you can get right in there and do your coding.

JP: I would just very gently offer a slight counterpoint on this one, my own personal feelings on it. Being the kind of developer that I am within the company I am, I always have a list of things as long as my arm that I've got to sit down and research at some point. And just knowing that if I do decide to use it, I am going to have to pay this fee, it just shuffles it down the list there a bit. I'm constantly searching for more time to learn new frameworks and new things that can help my job. This is one of those, it's not the only one. It just kind of shuffles it down the list. I think for me, something for personal use, and I am talking about personal non-commercial use -- I don't think $500 is out of line at all for anything that is corporate-used. In fact most frameworks, or most tools, cost a lot more than that. But for personal use, I've probably got a cut-off of about $100 maximum. I kind of look for the $50 to $100 -- it doesn't matter if it lacks things like full team capabilities, or stuff like that, for personal use. It's just I want to be able to get into it at a slightly more comfortable level. Personally, I find $500, I can get some pretty good hardware with that. Maybe it's just me, but I don't think I'm the only one out there. That's what I guess I'm trying to get across there.

RH: No, I agree. For some people it's not worth it, because that's their own personal feelings about it. And the only thing that I would say is, make that an informed decision. Try it, because it's free to try it. And while you're trying it, there's no obligations. There's nothing stopping you from trying it.

JP: Okay. Moving on, is there any kind of direct customer, or potential customer, feedback or forum, where developers can come and talk to you about what's available and maybe ask for stuff that they'd like to see in IDEA?

RH: Yeah there is, and in fact this is actually one of the big things that makes IDEA what it is today. We have a fairly large community. It's not as big as Eclipse, or -- I'm not sure about the NetBeans size -- but it's a fairly large community, it's customers, people who are just trying IDEA. And we have two websites. One is called intellij.net, and the other one is intellij.org. I would suggest, if anyone is interested, to go to intellij.net first. There's also, of course, for our customers we have full support. We have a dedicated support page for that, and a dedicated team for that. But the community is really the big factor here, that I would like to talk about. We have an interesting development process. Remember I mentioned I was a fan of -- I still am a fan of agile methodologies, like Scrum and Extreme Programming, and you know, I wanted to know how does this company develop this product, because it was developing features really super-fast, and they were good features, and it was very impressive. And I think to a large extent we are able to maintain that kind of turnaround. So I wanted to know, how does this company develop its software. So that's one of the reasons I joined the company. As it turns out, the method we use is called the Early Access Program, and we have a dedicated website for that, it's under the intellij.net website. We have forums and newsgroups that go along with this. Anyway, the Early Access Program -- basically what you do is, as we're developing the next version, you can get free licenses. Anyone can get a free license, as we're developing the next version. There's no strings attached. We do ask that you try to submit bugs and everything. We do tell you that it's not going to be perfect. It's not going to be fast, because we sacrifice performance while we're developing new features; we tune up the performance near the end. But what we end up with is a large community of people who are trying IDEA everyday, trying the new versions, and submitting reports, not just bug reports but feature requests, and we listen to them. So, if there's enough support for a feature request, we'll put it in. And in fact, a lot of the time it can happen very quickly, within a couple of weeks sometimes -- or within a few days sometimes. So, this is a very important -- I can't stress it enough -- it's a very important factor in why IDEA is what it is today, because we have a lot of people who use it all the time, and are really testing it, pounding it, trying it, and giving us feedback. And the important thing is that we listen to the feedback, and we make the changes, and post new builds every week or two, or sometimes every few days depending on the situation. So, yeah, we do have ways that you can get in touch with other people who are using IDEA, ask questions, get support. I would say go to the website and you can find it from there, jetbrains.com or intellij.net.

JP: Great. Thank you. Okay, well that's really the end of the questions I've got. Is there anything else you want to talk about, concerning anything, Java development in general, or IDEA, or anything like that?

RH: Yeah. This is a thread that's been going through my mind for quite a while. I listened to Bruce Tate's interview and, you know, he's talking about 'beyond Java', what's coming up. His attitude is that you shouldn't settle for the status quo. Just because the J2EE and EJB is "the way you should do it" doesn't mean that's the way you should do it. You should look for other alternatives out there. So, there's a lot of really interesting, exciting stuff coming up. Not just in the Java space, but in the entire development space. Things like Ruby on Rails, Groovy, even C# and .Net. There's so many new things that are coming up. We're working on something called Language Oriented Programming; I won't go into that, but it's an interesting thing. So, I'd just like to say that I think that people should not settle for the status quo. Raise your expectations. See what's out there. Just because you're doing something a particular way right now, you know, there might be a better way of doing it. So, you know, go out and look for alternatives. You might be pleasantly surprised.

JP: Actually, one more question has occurred to me here. I thought about writing this one down, never put it in there. I noticed that both you guys and the NetBeans team are based in Prague. It just seems an unusual coincidence, that. Do you guys have food fights and lob things at one another, or is there any kind of story behind that, or is it just coincidence?

RH: Hmm, I'm trying to think of the history now. I believe it's a coincidence, because Sergey Dmitriev was in Prague, he was working for TogetherJ, and he split off and started JetBrains, or IntelliJ at the time. And I think the NetBeans guys were independent. And the funny thing is -- oh no, I'm sorry, I'm thinking of something else. Yeah, the NetBeans guys are independent, and I'm not sure how their history -- like how they started and everything, but apparently some guy started it, and Sun picked it up. It's just independent.

JP: Okay.

RH: But, you know what, I've never met any of them. In fact, most of our development goes on in St. Petersburg now. It started here, but most of the development is in St. Petersburg, Russia.

JP: Okay. Well, thank you very much, Rob. That was an excellent interview, and hopefully it will be up fairly shortly, certainly in the next week.

RH: Thanks a lot, Dick.

Java Posse Interview: IntelliJ IDEA

2005-09-22T18:02:00.000+02:00

In this interview with Dick Wall of the Java Posse, I discuss the IDE marketplace and how IntelliJ IDEA competes versus Eclipse, NetBeans, and JBuilder.

Other topics include SWT vs. Swing, component-based development, and new features of IDEA 5.0 such as web development support, the Language API, code inspections and highlighting, etc.

New Java podcast! The Java Posse

2005-09-21T17:00:00.000+02:00

Dick Wall, who co-hosted JavaCast, has started a new podcast all about Java. The Java Posse plans to avoid the catastrophic fate of JavaCast by raising the Bus Number from 1 to 3. Dick is joined by co-hosts Tor Norbye (Sun), and Carl Quinn (Google), all of whom have access to keep the show going without any problems.

Assuming everything goes well, this is going to be huge for the mainstream Java community. Podcasts are a great way to keep up with all the news in the industry, and the Java industry is quite big. JavaCast went from nothing to 40,000 subscribers in a month. I predict the same or better for the Java Posse. As the guy in charge of content for JavaCast, Dick has shown that he's got his finger on the pulse of the Java world. And I like the way he's willing to express his opinions without simply echoing the hype and buzz phrases that can dominate many other Java-related sites and news sources.

The interview segments on JavaCast were great, too, and Dick plans to keep that going in the Java Posse, with the difference that interviews will be separate mp3 files from the news segments. When I had my interview with Dick about IntelliJ IDEA 5.0, I was very impressed with his questions. He wasn't afraid to ask the tough questions about IDEA versus Eclipse and NetBeans, and about the whole IDE industry, and where IDEA stands there.

I can't wait for the first episode. With (at least tacit) support from Sun and Google, this is the Java podcast to listen for.

JavaCast Growth Phenomenal

2005-09-01T18:18:00.000+02:00

Important update: In one of those ironic twists, shortly after I posted this, Brandon Werner completely lost interest in the JavaCast and took down the whole site, so many of the links below won't work. Dick Wall, the co-host, has contacted me and is in the process of starting his own podcast about the Java world. Assuming he keeps at it (which I think he will, based on his enthusiasm), my prediction simply transfers over to his podcast, since it will be the only Java-based podcast at this time. I expect that within about one month, he will have 20,000 to 60,000 subscribers, depending on how well he can manage promotion and infrastructure. Finally, the interview I had with Dick will appear on his show instead.

I never really understood podcasting until I found The JavaCast. How could this show come out of nowhere to reach over 40,000 subscribers in a barely more than a month? The more I think about it, the more it makes sense to me.

Basically it comes down to this: Newspapers are about broad audiences, blogging is about narrow audiences. Similarly, radio is about broad audiences, podcasting is about narrow audiences. (I guess that leaves then next logical step as vidcasting vs. television? Can't wait till the technology gets easy enough to just throw together a video interview. That would be wickedly cool.)

I heard an interview with Robert Scoble, on the awesome IT Conversations site, and he crystalized the idea in my head. People are itching to hear information relevant to their own personal interests in a timely manner.

Also, there's the issue of costs. Instead of requiring a hugely expensive studio and broadcasting license, which forces you to seek a large audience to make up the costs, you can just set up some free software on your own personal machine and do informal interviews and discussions with whoever the hell you want. There's no need to justify any costs, except perhaps the time it takes to edit the recordings. Almost anyone can do their own podcast for any particular interest they may have.

So, while podcasting as a phenomenon will be huge, the podcasts themselves will not likely have huge audiences. Well then, how do you explain JavaCast's huge audience? The answer is simply that there is currently no other podcast dedicated to Java, and the Java 'niche' is quite huge. I expect JavaCast's audience will continue to grow at a huge rate until some competitors appear, at which point, the audience will segment further into specific Java topics like Java EE, client side, security, or whatever.

In the mean time, I recommend checking out the JavaCast. The latest episode has a great interview with Bruce Tate about web development technologies, and what's possible 'beyond Java', which is the topic of his upcoming book. I met Bruce briefly at JavaOne 2004, and he signed my copy of Better, Faster, Lighter Java. Cool guy.

I just finished recording an interview with Dick Wall of the JavaCast, about IntelliJ IDEA 5.0, and how it compares to Eclipse and NetBeans. That should be coming up in one of the next episodes.

IntelliJ IDEA 5.0 RC1 Released: Get a Free Taste!

2005-07-19T19:45:00.000+02:00

The countdown has begun. The features are frozen. All that's left are bug fixes and performance tuning. Check out IntelliJ IDEA 5.0 for yourself in the Early Access Program.

(Note: The "What is the Irida project?" page is out of date. The official list of new features is here.)

JetBrains sparks a new era of programming with the first public EAP of MPS

2005-06-16T21:55:00.000+02:00

From JetBrains:

"After months of intense development, it's finally here! The new language workbench code-named the Meta-Programming System (MPS) has been opened to public review, in JetBrains' renowned Early Access Program (EAP).

This new tool represents the future of software development, as expressed by Sergey Dmitriev's vision of Language Oriented Programming. Language Oriented Programming (LOP) is a style of programming in which specialized programming languages and environments are developed in conjunction with programs, giving more freedom and power to the programmer, ultimately making programming easier, more fun, and more productive.

Language Oriented Programming, and related initiatives, has been gaining momentum in recent months, with interesting developments by Microsoft, Intentional Software, Xactium, and several others. It is now clear that this is the right direction for software development to head into the future."

I've posted an article on JavaLobby, so you can join the discussion there.

Language Workbenches: The Killer-App for Domain Specific Languages?

2005-06-14T14:30:00.000+02:00

Martin Fowler gives an excellent pragmatic view of Language Oriented Programming and what he calls 'language workbenches' in his latest article. As usual, Fowler is somehow able to put big ideas into plain language.

The article is actually a collection of related articles, one of which shows an example of using JetBrains' research project, the Meta Programming System. For the 'big vision' of Language Oriented Programming, be sure to read Sergey Dmitriev's article.

Geoffrey Moore: Firefox is crossing the chasm

2005-05-25T01:00:00.000+02:00

Geoffrey Moore, author of Crossing the Chasm: Marketing and Selling Technology Products to Mainstream Customers, presented at the Open Source Business Conference 2005, titled Open Source Has Crossed the Chasm...Now What? (you can download or stream the talk for free, no registration required). In this talk, he briefly mentions Firefox:

Firefox, I think is in the chasm. You say, "Well, how is that possible? It's the hottest thing in the place." But it's hot with all the early adopters and I don't think it's crossed the chasm. ... By the way, getting to the chasm is progress. It really is. You know, people are into chasm denial, but the truth of the matter is, getting to the chasm means you have achieved a constituency in the early market that worked, but now the problem is you've got to make a transition, and what appealed to that first group of people will not be what appeals to the people on the other side of the chasm.

First of all, I think it says a lot about Geoffrey Moore that he's been thinking about Firefox and the rest of the open source world, to the extent that he put together such a talk for the Open Source Business Conference.

Secondly, this has important effects on Firefox's marketing efforts. They need to focus their message to the mainstream person. Find the pains they are feeling in web browsing and explain how Firefox eases those pains. "All gain, no pain." That's what mainstream people want to hear when they are considering adopting some new technology like Firefox. The cool features are still cool (like fast rendering, extensions, themes, etc.), but they need to remember that those features won't influence mainstream people nearly as much as the 'pain killer' features will (pop-up blocking, rapid security patches, no Active-X, etc.). Instead of leaving people thinking "Firefox may be slightly better than IE, but I'm happy with IE. It's good enough," they need to get people to see that "IE is painful, I need something better."

The talk is also quite interesting from the open source perspective. I highly recommend it. Slides are available.

Hello, IDEA!

2005-04-21T20:08:00.000+02:00

From the recent Java IDE discussions, it seems like there's a good portion of Java programmers who don't know IntelliJ IDEA, or simply haven't tried it yet. In this short screencast, I cover all the basics you'll need to get started using IDEA in about 10 minutes. Watch "Hello, IDEA!" No fancy tricks like my last screencast, this demo is simple and easy.

Do you have a friend or colleague who hasn't tried IDEA? Send them a link. I'll be posting more advanced feature-specific screencasts soon. Stay tuned.

Language Oriented Programming: Everything is a Language

2005-04-11T14:20:00.000+02:00

Some people don't 'get' Language Oriented Programming. It's a different perspective. Once you make the mental shift, everything starts to fall into place. Over the past few months, I've been looking at the software development world with LOP-coloured glasses, and I've come up with a quick zen-slap phrase which I hope will help shift your paradigm.

(If that last sentence made you think, "I hate the word 'paradigm'! It's a meaningless marketing buzzword," then read this before reading on below.)

Everything is a Language
Just as OOP introduced 'everything is an object', I propose for LOP that 'everything is a language'. Keep this in mind as you read about and discuss software, and suddenly things will look very different to you. But what the heck do I mean?

Programming is Communication
When you want to communicate an idea to someone, how do you do that? You use the tool that Homo Sapiens 1.0 has evolved over millions of years: Language. You'll speak, you'll make gestures. If you want the communication to last over time, you'll write it down in symbols. These days you can use fancy tools like keyboard, mouse, digital memory, and graphic display to write these symbols.

Now, when you want to instruct a computer, how do you do that? You write symbols using keyboard, mouse, digital memory, and graphic display. You're doing the same things, but instead of communicating ideas to people, you are communicating ideas to the computer. Now, of course, there are a couple of important differences, such as the fact that there are strict rules on which symbols are used and how they are arranged, and also the fact that the symbols have a very precise, concrete meaning (e.g. '2 + 2' actually performs a physical action in the computer to produce the symbol '4'). However, at the end of the day, a programmer's work primarily involves communicating to the computer via language.

The Editor is the Medium
Before I go into the examples, there is one important thing to know. Language does not exist without a medium. Spoken words require a mouth to speak, air to propagate sound waves, and an ear to listen. Sign language requires hands to make the signs, light to carry the image, and eyes to read the signs. Writing requires a pen, paper, and eyes. Programming requires a keyboard to type, an editor to accept the input, and a compiler or interpreter to execute the program. Take away any of these things, and communication is much more difficult.

Marshall McLuhan tried to emphasize this fact by saying that "the medium is the message". He, perhaps, overstated his case for emphasis. But the fact remains that the medium of language is an important, indispensable part of the language. So I will now put '2 + 2' together to state something that will likely bother some hard-core programmers: The editor is an important, indispensable part of the programming language. The editor is the medium of the programming language.

Examples
When you start to think 'everything is a language', you will start to see computer languages everywhere.

JUnit and TestNG
JUnit is the most popular unit testing framework, but there are many clones and variations. They are all languages. With a unit test, you attempt to communicate to your system that, when the environment is set up in this way, this is what you expect, and this is what actually occurs. But have you noticed how ugly it is to write a test that says "this method should throw this exception"? That is because JUnit is written in Java, and the only way to do this in Java is to wrap the method in a try/catch statement. JUnit is a language on top of Java. Notice how new frameworks such as TestNG try to modify Java (with annotations) to make writing tests more natural? That is because they want to be true languages.

EasyMock and jMock
The Mock Objects pattern is another language, and two popular frameworks again try to adapt Java into a mock-object language. EasyMock uses dynamic proxies to generate mock objects on the fly. But notice how you have to have this clumsy MockControl object to specify return values and exceptions? jMock goes further than EasyMock, allowing you to specify in a fairly natural way the expected inputs and outputs. But notice how you lose Java's language support for interfaces; instead you have to specify method names with Strings, making refactoring method signatures with an IDE more difficult. And while writing mock expectations may be fairly natural, it's actually not very natural at all; it doesn't look like a normal Java method call as it would with EasyMock. That's because both of these frameworks are languages on top of Java. I think it would be great if my editor allowed me to write out the expectations using special notation that isn't possible in Java, like this:

myObj.myMethod(obj equals expectedObj, date between startDate .. endDate) returns expectedResult;

XML this and XML that
Have you noticed the proliferation of all these XML dialects? Why is that? It's because XML gives you a standard and relatively easy way to invent your own languages. The parser is already built, all you need is a DTD for your syntax and to wire up the grammar to your Java (or other language) objects for your semantics. Ant is one example, but there are zillions more. Obviously, there is a need for the ability to easily create specialized languages. This is one of the primary forces behind Language Oriented Programming.

Struts, Spring, and Rails
Web frameworks are yet another kind of language we are seeing a lot of these days. Notice how Struts defines page navigation using XML, extends JSP with tag libraries, and provides special facilities with its class framework? I wonder why such a project as Struts Console exists, or the various IDE plugins. Could it be because Struts is a language? Spring wires up your application with a configuration script (hint: in its own specialized XML language). Rails rewrites entire classes, re-interprets method calls, and has dozens of other meta-programming tricks just to make your life easier. These frameworks are all attempts to work around the deficiencies of their host languages. Imagine the power that would be possible if they could be languages in their own right, with things like IDE support, refactoring, and whatnot. (I'm talking about LOP, people.)

Aspect Oriented Programming
Why isn't it popular? No IDE support. 'Nuff said.

Ruby, Python, PHP, and even JSP
Dynamic languages are on the rise. Why is that? Let's put on our LOP glasses. Static languages are great because you get lots of support from your tools. The compiler gives you lots of hints, and can do things like optimize your code. A smart IDE like IntelliJ IDEA can make judgments about code, allowing static analysis, refactoring, code completion, and navigation. But static languages also have some downsides. Every little detail has to be specified, sometimes more than once. Little errors can blow up in your face if you're not disciplined in your coding practices.

Dynamic languages make a trade-off. They try to be more flexible, and get out of the programmer's way, at the expense of losing some of the features of a static language. Sometimes, this trade-off is in the interests of the programmer. With more mature languages like Ruby and Python, the advantage is slowly tipping more and more in favour of dynamic languages. Wouldn't it be cool if you could have the power and flexibility of a dynamic language, with all the extra cool features of a static language, and a kick-ass editor to boot? Hmmm.

So...
Keep your eye out for this stuff. It's going to become more and more obvious to you. All you have to remember is that everything is a language.

Paradigm, Schmaradigm

2005-04-07T17:56:00.000+02:00

Let's clear something up. Yes, 'paradigm' has been hijacked by evil marketing forces. No, it is not a meaningless word. The problem is most people don't know what 'paradigm' means, so marketers are able to twist it and turn it and slap it onto any old crappy idea. If everybody knew what it meant, it would lose all its mysterious power, and marketers would give it up for some more fuzzy, vacuous word, like 'folksonomy'. So with that goal in mind, I'm going to briefly educate you on the real meaning of paradigm and immunize you against the marketing buzzword of the same name.

The meaning of paradigm I'm using here comes from Thomas Kuhn in his famous book The Structure of Scientific Revolutions. A paradigm is a set of assumptions that cause you to think about things in a specific way. For example, assuming that the Earth is the centre of the universe might cause you to think that there is inherent order in the universe, with everything in its place, and with Earth holding a special, exalted position. The four elements, earth, water, air, and fire naturally seek their proper place. The sun, moon, planets, and stars revolve in perfect circles around the Earth. This paradigm, for two thousand years, helped people understand the world.

No paradigm is perfect, and there will be anomalies that the paradigm cannot explain. In the beginning, the anomalies won't seem important, and people will ignore them, or make small exceptions or corrections in the paradigm to account for them. But over time, as understanding deepens, the anomalies will gain significance until they are too problematic to ignore any more. For example, astronomers observed that the planets didn't move in perfect circles, so they invented the concept of epicycles to try to correct their model. Eventually, the required epicycles became so messy that the geocentric cosmology reached a crisis.

When a crisis is reached, new paradigms arise to compete against the prevailing paradigm, and eventually a new, usually better one wins out by eliminating the anomalies of the old paradigm. This process is called a paradigm shift. For example, by considering that the Sun is the centre of the universe, and that orbits are elliptical instead of circular, the need for epicycles vanishes. (Some people use the term 'paradigm shift' to refer to an individual person's internal shift in viewpoint from one belief system to another. I confess I also use the term that way, but I only apply it to genuine paradigms, not just any viewpoint shift.)

There's another important aspect to paradigm shifts, which is the historical fact that paradigm shifts tend to be nasty, with the old-guard staunchly defending their tried-and-true paradigm, and the new generation brazenly promoting their new-and-better paradigm. Sometimes, the only way to complete the paradigm shift is to wait for the old-guard to literally die off! For example, the Catholic church had so much invested in the geocentric paradigm that it took two generations of scientists (first Copernicus, later Galileo and Kepler) to establish the heliocentric paradigm among the mainstream scientific community. And we all know what happened to Galileo. Thomas Kuhn called such messy scientific paradigm shifts 'scientific revolutions', and in fact, the Copernican paradigm shift is considered the Scientific Revolution since it is one of the major events of the Renaissance.

One last important feature of paradigms is that they are often mutually unintelligible, and trying to explain something in the context of one paradigm, when the other person holds a radically different paradigm, can cause huge misunderstandings and pointless arguments. People talk right past each other, saying things that make perfect sense to themselves, but are completely meaningless to the other person. You can imagine the different answers you would get from a geocentrist versus a heliocentrist when asked the question, "Why are we here?"

The word paradigm, when used in the sense of Kuhnian paradigm shifts and scientific revolutions, is a very powerful and useful concept. It can help you understand major events in the world, and to see the recurring structure in them. So, now that you understand the real meaning of 'paradigm', you can just ignore the clueless marketing drones who babble about 'optimizing your paradigm', and not get so worked up over this perfectly good and useful word.

IntelliJ IDEA Skeptic Learns to "Develop with Pleasure!"

2005-04-05T14:31:00.000+02:00

I couldn't pass on this classic. Blogger Doug reluctantly discovers TDD and IntelliJ IDEA. From "how do I create a new class?" to "living without it may be hard to do" in 4 days. Nice! My favourite part is the initial hard-core skepticism when he says "30 days is not long enough for me to evaluate" IDEA, followed by a somewhat unrealistic evaluation scenario: "It is resource hungry," he claims, "The box I'm using at the moment is a bit low on memory, only 256Mb... It's an HP e-Vectra I picked up at a computer auction for < $150 about a year ago." I mean, seriously! You can't expect to run a power drill on AA batteries. ;-)

Overall, I think Doug's experience is actually quite common. Switching IDEs can be time-consuming and mind-bending, especially if you've gotten deep into your previous IDE's habits and quirks. Each IDE has its own personality, and will take some getting used to. The most pragmatic approach is to keep your expectations realistic, have enough time and resources to give each IDE a fair shake, and then pick the best tool for the job. Different tools work better on different jobs, so it's good professional practice to know how to use multiple tools from your toolbox.

You download IDEA here, and JetBrains is currently offering a special personal license for half the regular price. Don't miss out.