As you might have heard through the grapevine, or learned from Michael Snoyman’s blog, or from Gregg Lebovitz’ presentation at the Boston Haskell User’s Group, FP Complete is working on a Haskell IDE. Michael’s blog received a lot of comments and precipitated a reddit exchange; Gregg’s presentation sparked a lively discussion — both turned out to be excellent sources of ideas. I hope this will continue. We welcome any feedback, positive or negative, and we’ll try to incorporate it in our projects. So here’s another update and a look at what’s cooking in the FP Complete kitchen.
We started our work by researching existing solutions from which we are hoping to learn as much as possible. We looked at Haskell editor extensions, especially Vim and Emacs, and at existing Haskell IDEs like Eclipse FP, Leksah, and Yi. We also looked at what supporting functionality is readily available: the GHC API, Hoogle, Haddock, Hlint, and many others. So, really, the problem boils down to how to expose all this functionality to the user, and that leads us to the question of UI.
I am personally partial to Bret Victor‘s school of user interaction. His goals are very ambitious, most of them unfortunately out of our immediate reach. He has some great ideas about visualizing program execution and providing specialized domain-specific tools for development, which let programmers unleash their creativity. He also has some excellent insights into displaying information that is context- and history- sensitive. Some of his ideas were used in developing IDEs; in particular by Chris Granger in his inspirational Light Table project.
When designing an IDE it’s important to support natural uninterrupted workflow. Writing code requires tremendous concentration and any distraction is highly unwelcome. With training, some of us can shut off the world outside our cubicles, and even ignore our bosses, but when an annoying dialog pops up on top of the file you’re editing, your concentration goes down the drain.
In a good IDE you should be able to keep your eyes on the code and continue typing, no matter what. I have a theory that the failure to heed this requirement is the main reason why a lot of people still prefer to use editors like Vim or Emacs (not to mention Notepad) rather than GUI-based IDEs. Sometimes even taking your hand off the keyboard to use the mouse is an unwelcome distraction.
And yet, programming is never a linear task. It’s a process in which streaks of intensive typing are interrupted by bouts of information lookup and various digressions.
To make information look-up smoother, it’s important that relevant information be displayed and constantly updated depending on the current context. There is a whole spectrum of useful data that might help the developer, ranging from immediate at-your-fingertips autocomplete, or on-the-fly error highlighting, to the unobtrusive display of module information or the source code for a function whose name is under the cursor.
Browsing project files and external libraries is probably the most common activity in programming, so it’s really important to streamline this activity. As Bret Victor noticed, the less the user has to interact during this process the better. Eyes are faster than hands, so the IDE should be generous in displaying context information. The user can quickly scan it and focus on the relevant part. We plan on displaying this information in a dedicated area on the screen — the Info Area.
The need to digress arises, for instance, when you want to call a function that hasn’t been defined yet or is defined in another module that hasn’t been imported yet. The IDE should work for you whether you want to keep plowing through or stop and make a decision or take a short side trip. In the former case, the IDE should discretely add a work item to your to-do list; in the latter, it should display all the necessary information and present you with clear options. A common example is when you call a function that hasn’t been defined yet. The IDE may find it in one of the libraries that haven’t been imported into the current module. In that case the IDE will display the information about the module and the function, but it’s up to you to follow up immediately, or postpone the decisions for later. With one click you should be able to import the library; but if you don’t do that, it just goes on your to-do list.
We are in the advantegous position of developing an IDE for a single language — Haskell. (Actually, we’re going to support Yesod development, so we’ll also need HTML, CSS, and JavaScript editors.) But, being focused on Haskell, we can design the whole IDE around it. We can take into account Haskell’s module system, package system, exports and imports, granularity of definitions, the type system, and so on. Haskell programming is different enough from programming in other languages that fitting it into existing frameworks like Visual Studio or Eclipse is really hard.
We can also take advantage of the multitude of tools that have already been written for Haskell, like Hoogle, Haddock, Cabal, HPC, various profilers, etc. We can hide their quirks and expose them through natural unobtrusive user interfaces.
Last but not least, we rely on constant flow of ideas, encouragement, and support from the Haskell community, for which we are very grateful.
I have several blog posts planned. Recently I’ve been exploring the use of the browser as a GUI platform for Haskell. I will also continue with the Yesod tutorial, and talk a little about FP Complete innovative plans for providing Haskell education.
Subscribe to our blog via email
Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.
