In this blog I talk about some of the personal programming I do as a hobby. By trade I'm a Java and database developer but I've dabbled in Haskell, front-end development, etc. I'm currently working as an architect but still enjoy getting my fingers dirty in code!

Maybe we're just suffering from too much dispersion in the Haskell IDE space. We have plug-ins for the major IDEs, but none of them can probably called great (I know, some people positively hate EclipseFP, but for my defence I'll say I get much more bug reports and feature requests than pull requests, I probably need a course on "building a passionate programming community around your open source project"). They however have the massive advantage of being able to reuse a wealth of existing code (I can use the Eclipse Git plugin to work with Github, I don't need somebody to write the Haskell version). An IDE in Haskell like Leksah or something built on top of Yi would be amazing to showcase that you can do real applications in Haskell (since you still get people saying that Haskell is only for toying with), but then you need to build everything, which requires people (see note above on building a community). Then we have web based editors like the offering from FPComplete, but for developers to use them on real projects we need to think on how to package a web based interface and what it means for a development work-flow: I'm not sure developers would embrace developing using a browser. Of course we have plug-ins for the Unixy editors, emacs and vim, but if we want to open up Haskell to non hackers, maybe we need something more...

So can we continue like that and hope to have a few decent environments? Or shall we all agree on a direction and unite to provide the one true development environment for Haskell? Sometimes people say "Haskell is so different and advanced as a programming language, it needs a new type of editor/IDE". I don't disagree with it, but who has the vision of what the Haskell IDE should be?

Idea people are just like Apple fans. Blindly and religiously push their thing.

I use Eclipse (for Scala) for my day job. I use Idea some times. Some things are better! But some things are just bad. That's why Eclipse is my primary IDE even though that I use Idea "some times" for 6 years now.

I'm doing the most advanced Java re-factorings in Netbeans. Not Idea! Try to explain that to Idea people. I've tried a couple of times. It's a waste of time. You show them things they can't do in Idea. But they will not believe it.

Fashion plays huge role as well! You know what was _by far_ the biggest spike in Idea love I've seen in last six years? Dracula theme! Everybody excited! Really! It's the default colour scheme that's the difference!

Having all that said - Idea is really great IDE. Just not better that Eclipse. Something is better in one something in the other.

Having people cooperating on creating one or two IDEs instead of ten... the same for libraries... we may all be using Haskell for a day job by now. Unfortunately it's not the way it works. Most Haskell people will not work with you on Eclipse neither on Idea just because none of them is written in Haskell. If you gather 10 Haskell people and write _one_ IDE in Haskell you will not get in 10 years IDE as powerfull as EclipseFP is today. Eclipse ecosystem offers way much more than the git plugin ;-)

For the time being:Thank you for the EclipseFP! It's the best Haskell IDE out there hands down!

«So can we continue like that and hope to have a few decent environments »

At least you should continue with eclipse, it offers the best and most feature-rich haskell hacking experience. I will explain that.

«Or shall we all agree on a direction and unite to provide the one true development environment for Haskell? Sometimes people say "Haskell is so different and advanced as a programming language, it needs a new type of editor/IDE".»

People generally dont agree on one direction as it comes to editors and IDEs. Some people like a rich and complete programming environment like eclipse offers, others hack in vim.

Please consider the following. If all haskellers suddenly would agree on what a real haskell coding environment should be and started to write it, you will have one that is able to compete with eclipse in about 10 years.Do you want to wait for that?

People even don't know what an haskell ide should contain. There are only very wild ideas by now. Of course we will see some experiments, the succesfull ones could be integrated into eclipsefp.

Of course, the community has lots of bright people, but there is no way they could magically rebuild an ecosystem like eclipse that has been developed for more then 10 years by hundreds of people.

The take from fpcomplete on this subject is a bit too enthousiastic. To be fair, that project is doomed. They have no change to build a system for real world developmentinterfacing with revision control, database systems, build management, remoting, etc

They might come up with an editor with syntax higlighting and some cool features.I think its good to keep an open eye for innovations in places like those, but eclipsefp is definitively the future.

If fpcomplete would have thought a bit longer about what the software engineering process involves, they would have acknowledged that.

Be sure that what is below your hands is definitively the tool for haskell hacking for the year to come. :)

I think EclipseFP is fantastic. Not only is it very functional (har har), but I think it's a major selling point for Haskell among the very large community of developers that are accustomed to working in a full-fledged IDE. I gave a presentation on Haskell the other day to a .NET user group. It was very well received and a major portion of the credit for that goes to EclipseFP. If I had used a text editor + GHCi for the talk, I'm sure all the wonders of Haskell would've fallen on deaf ears.

That being said, I do not like Eclipse. It has a lot of great functionality, but the organization of things makes very little sense to me. Charitably, I would say that this is probably because I lack experience with Eclipse (EclipseFP is the only thing I use it for). But if I'm to be honest, I feel that a lot of Eclipse is plainly and objectively wrong. If I found something anywhere near as functional as EclipseFP for another IDE, I would probably drop Eclipse/EclipseFP like a hot potato.

By the way, I understand that we're pretty much stuck with the EclipseFP moniker now, but I think it's too bad. I heard about EclipseFP long before I understood what it was. Why not EclipseHaskell? Was that taken?

Thanks people for the good words about EclipseFP, I tend to get only bug reports, which is more depressing.Daniel, I didn't choose the name. I think at the time it was started it was envisionned that the same plugins would provide support for OCAML as well as Haskell, but this didn't pan out. I'll have no problem changing the name. We could do a survey... HEclipse? EclipseHaskell? I'm easy...

For me IDEA is a bit closer to Visual Studio. I used VS for more than a decade and I really dislike using any other IDE. I do occasionally use IDEA as part of some consulting work.

That being said I strongly dislike Eclipse and would probably never use anything based on it. Very little of it makes sense to me. It is unlikely I will ever invest the time to make myself productive in it. Our company uses vim with ghcmod for haskell development and that is unlikely to change. I tried Leksah at the beginning but at this point we use our own build system so we would need to integrate it into whatever we would use.

In looking at the EclipseFP feature list I am not sure what its advantage would be. Before moving to vim I was pretty sure that you needed an IDE to build software, now vim with plugins has worked out just fine.

All this is just personal taste and some people do like eclipse. However it is passionately disliked by many people. I have never met someone who actually used EclipseFP.

My own sense is that haskell isn't going to to be made or broken by its IDE. There are too many other challenges that developers must overcome to be productive. Personally I would prefer something lighter weight like SlickEdit to a full blown IDE but others will have their own view points.

JP, thanks for mentioning us in your blog. We will be coming out of the gate with many of the important features you mention. It is the first commercial Haskell platform for developing, building, and deploying applications into the cloud. Not only does it interface with revision control systems, but it has its own build manager, and is more integrated than "remoting". Our product is more than an IDE, it includes a Haskell Application Server that is deployed to the cloud today and soon will support deploying behind the firewall. We don't want to give too much away, but it has IDE features that go beyond plugins, such as tight compiler integration providing continuous compile, and live error checking and type display. And there are more features on the way.

In a few weeks we will be releasing an open beta so get ready to sign up and try it for yourself. Watch our site for more details as we post them.

After repeatedly trying to use Haskell for small personal projects and small to medium projects for work, I'd say that for Haskell I want an IDE that does more than those of conventional languages, or at least as much. Due to the sheer amount of implicit stuff like inferred types, and the amount of control structures expressed as functions rather than specialized syntax, there has to be a lot of editor assistance for quickly understanding or writing (and indenting) the code.

EclipseFP largely fits the bill of a conventional IDE, but its the details that I find annoying and keep me from using it. Some are EclipseFP, like bits of lag when typing with large files, or icons that don't go away when I leave Haskell perspective, or the hoogle/doc system which only sometimes work and rarely gives me what is relevant. Others are with eclipse, like the somewhat incomplete vim mode, or the clunky, laggy, and slow interface.

And then I go and try to fix some of the bugs and I am confronted with a complex weaving of Java code, and I have to learn how ten different factories interrelate and how they plug into Eclipse itself... its all rather overwhelming.

these things might have improved lately, I haven't used eclipsefp in a few months.

Unknown, I'll readily accept that EclipseFP is a bit of a kludge, and a bit rought on the edges. There's only so much one man can do in his free time, and we're limited for performance by the fact that we use external tools like cabal and buildwrapper, so there's always a delay and a price to pay. If there was a better way to bridge the GHC API and the Eclipse API (compiling GHC to Java?) it would be better, but I just don't have the bandwidth to achieve that.Gregg, thanks for chiming in, I'm looking forward to see what you guys can offer in this space!

Haskell is too important (and difficult) to leave potential users with the uphill battle of having to learn eclipse AND haskell at the same time.It's 'obvious' what a good Haskel IDE looks like, and it's not eclipse. It's a web based clone of Sublime Text with integrated GIT, hlint and cabal.IMHO!(as a vi(m) user of 30 years standing)

Nicholas, your "obvious" IDE makes a lot of sense, and hopefully that's along the lines of what FPComplete will deliver. But I know for example some users of EclipseFP that use Subversion as their source control. They get a free plugin for that in Eclipse which they can use in EclipseFP. Who's going to develop that in your IDE?

I personally don't buy VCS integration as a major selling point for an IDE. There's a lot of people (me included) who'd rather use the command line or stand alone applications for version control manipulation than an IDE plugin. Similarly, I don't buy the "existing plugins" pitch in general. I've used IDEA and Eclipse, and aside from the VCS plugins (ironically), the other user developed plugins (say, the box-highlighting or vim plugin for eclipse) just feel very rough and half baked.

I like the idea of a web-based interface. Especially if it comes with things like full keyboard control and general extensibility. The backend that powers it should support a fully isolated (chrooted) environment for packages and dependencies. Something like c9.io but for haskell, and less buggy.

@nicholas hart: Something lightweight in the spirit of Sublime or LightTable would be the key. You can't make everybody happy with.Just like Yiding, I really don't see the point of having VCS integrated in the IDE: for git e.g. you have tons of good front-ends (I was a git commandline nazi until I encountered SourceTree), what's the problem with having it as a separated window?

I think most people expect 5 things from their IDE: live building & checking, full autocompletion, quick navigation in code and doc, debugger and refactoring.For Haskell, they will also expect some quick way to see a value's type.And if you want it to be really solid it should also be tolerant to code that doesn't compile in another part of the file.Everything else (deployment to app servers, dependencies handling, etc.) affects interoperability so should be made through external tools (with possibly a _thin_ layer to be able to use them through shortcuts in the IDE) or else it'll be by default a behemoth and you'll be constraining people in one workflow and forbid people working on the same project to use the environment they prefer.(Just how many times have I told people to stop using the Eclipse builder and to use Maven, so that other people are not constrained with Eclipse!)

So tools, tools, tools... are actually what we need. Tools like ghc-mod for instance, which is just some editor-specific glue away from being usable through shortcuts. A generic Haskell refactorer tool would be very useful for instance.

I'm not against a web-based environment, but it shouldn't be imposing specific technologies on me for annex tasks (VCS for instance).

Yves, what you say is interesting, I suppose this was the idea behind Scion, and also behind my own buildwrapper packages: provide services an IDE may need, hiding the complexity of using the GHC API, etc... FPComplete did talk about this kind of approach (see https://github.com/fpco/haskell-ide/wiki)

I completely agree on the need for a functionally rich, stable and well-supported IDE in the Haskell community.

I know that a lot of devs are perfectly happy with an editor, a command line, and a collection of other tools that may or may not have integration in their editor of choice.

We are using Haskell in our commercial software development activities with developers who are used to having a modern IDE as part of their world. We also use Java, so Eclipse isn't such a bad fit, but I would completely agree that quality and experience of Eclipse leaves a lot to be desired.

Eclipse seems very bloated and tries to be all things to all people. It should be great that it has such as large and vibrant community, but generality is a hard things to accomplish and Eclipse is very complex/sophisticated.

I've used Leksah quite a bit and really wanted to believe in it as a 'native' IDE focused on Haskell. Unfortunately, it doesn't seem to have enough of a developer team to really push it forward right now. Maybe that will change.

Eh I'm late to the party, but in hearing all of the responses I would think the "obvious" answer is starting with an IDE that has good plugin principles and is basically a shell. To be fair I think that is what Eclipse tries to satisfy, but as many have stated, not everyone has the JVM language skillset to contribute. I'm not sure how much Frege could add, perhaps interested parties could learn enough Scala to be helpful. I'm not sure what the answer is.

But a shell that can basically load whatever plugin environment that's desired, so if you want just a REPL with some code completion ... great. But if you want something that will more tightly integrate with an existing infrastructure then that could be a possibility.

Eh I'm late to the party, but in hearing all of the responses I would think the "obvious" answer is starting with an IDE that has good plugin principles and is basically a shell. To be fair I think that is what Eclipse tries to satisfy, but as many have stated, not everyone has the JVM language skillset to contribute. I'm not sure how much Frege could add, perhaps interested parties could learn enough Scala to be helpful. I'm not sure what the answer is.

But a shell that can basically load whatever plugin environment that's desired, so if you want just a REPL with some code completion ... great. But if you want something that will more tightly integrate with an existing infrastructure then that could be a possibility.