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
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.
Designing the 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
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
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
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
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
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.
In the Pipeline
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.
Do you like this blog post and need help with DevOps, Rust or functional programming? Contact us.