Editing HIDE (section)

== A Manifesto for hIDE 2.x ==

* Free Software, not based off proprietary IDEs
* Written in Haskell
* Extensable plugin-based design using hs-plugins (like lambdabot)
* Distributed development using darcs (again like lambdabot)
* Attractive UI using Gtk+ 2.x and the Glade visual GUI builder)
* Internal editor also written and extensible in Haskell, based on Yi
* Build system based on Cabal
* Integration with other tools, haddock, analysis and refactoring etc. through plugins
* Use the new GHC internal interface to provide tight integration with the editor and other parts of the IDE

BulatZiganshin: how about targeting competition with Emacs, VIM and other wide-spread IDEs/editors? i think now it's the right time to roll up Haskell-based killer app :)
DonStewart: I think we are doing this, yes, since Yi already attempts to provide emacs/vim/... interfaces

=== Development style ===

Now you may notice that I'm mixing features with implementation choices (eg using Gtk+). To justify this I would appeal to the open source idea to release early and the importance of getting a base platform working to gain momentum and mindshare. Therefore we should not necessarily try to generalise too much too early but to get the basics working quickly.

However the other thing to avoid is going all out for features and neglecting the structure and organisation of the code necessary to allow sustained growth. This is one of the main lessons we must take from hIDE 1.x. So the modular development by plugins is important to allow distributed and parallel development. So for example it needs to be possible to develop components and then swap them out later for improved versions. For example suppose we start by using an editor component based on the GtkSourceView widget, it should be possible to develop another editor component based on Yi while the default remains as GtkSourceView and to have them both plugins loaded at the same time. Then when the new component is deemed to be better then the default implementatin can be changed over. That way we do not need to hold up immediate practicalty by waiting for more advanced implementations.

=== Why now? ===

Because we have the technology and there is demand for tools to make writing and maintining Haskell code easier.

* We now have distributed development with darcs.
* We now have hs-plugins and the techniques for building fully dynamic modular applications. http://www.cse.unsw.edu.au/~dons/papers/SC05.html
* We now have the GHC interface so we can get really good integration with the compiler.
* We now have mature GUI libraries.
* We now have an editor written in Haskell being developed.
* There is a VisualStudio plugin being written and we don't want Free software for Haskell development to be left behind.
* The [[Haste]] developers demonstrated that it's possible to build an IDE shell in a couple months with inexperienced Haskell developers.

=== Why in Haskell? ===

* Because Haskell developers know Haskell and not elisp/Java/C++/COM/C#. Therefore we are only likely to be able to get Haskell developers to help out by writing extensions if they can do so in Haskell.
* It means we do not have to live with the requirements and limitations of IDEs that are primarily aimed at other languages or written in other languages.
* Let me repeat a point: The Haste developers demonstrated that it's possible to build an IDE shell in a couple months with inexperienced Haskell developers.