Having just presented a case for the possible rationality of the irrational decision of creating an Emacs-like IDE in Haskell, I wonder if we should not be even more irrational and contemplate the possibility of using Haskell to create a radically different kind of IDE. New technologies are often used to imitate and reimplement the artefacts of previous technologies. In my house, I have a gas-powered fireplace that goes out of its way to present itself as a Victorian coal-powered fireplace that in turn was just a clone of the wood-powered fireplace of yore. The killer application of natural gas as a home heating technology is not, however, fake fireplaces but rather something completely new and way more convenient: clean, reliable and affordable central heating. Emacs was designed in a very different age, with technical limitations and therefore design constrains quite different from the current ones: Individual versus collective development: In the 70/80ties, cooperative development meant having an expert spending months writing a program in C and then distributing the source on tape to a few hand-picked peers. These days we create whole encyclopaedias cooperatively combining the skills of both traditional academic experts and high school students with too much time on their hands. In the Emacs-age the emphasis was necessarily on supporting highly-skilled individual programmers. Now, it should be on supporting distributed, large-scale, communal development; keeping in mind that not all potential contributors measure 1000 milliOlegs or milliSimons on the Haskell IQ scale. Local versus ubiquitous access: In the 70/80ties, people were lucky to have access to a computer terminal, applications were naturally designed to be run and configured locally. These days we tend to have multiple computing devices and we expect to be able to access our data and software from everywhere. Local versus distributed execution: Application these days are often run in a distributed environment. Web applications for example are multi-tier with often one or more servers per tier. Simply copying the Emacs model might therefore not do much to address the needs of a different technological age. So where should we look for inspiration? Maybe not very far, the seeds of a possible revolution might have already been sown. LambdaBot, hpaste and hoogle as well as the Haskell Wiki and indeed even this mailing list can all be thought as elements of a cooperative, ubiquitous, customisable, zero-installation, distributed and integrated (that should be enough buzzwords for anybody) development system. What we need is to connect the dots and recognise the possibilities that might arise from an integration of all these tools in a World-Wide Functional Web. So, if we let our imagination loose and dream about an IDE for the Internet age, what would it look like? My personal dream goes a bit like this: Simon wakes up in the morning, with an idea for a new GHC extension to facilitate parallel computing. He starts up his Web Browser to access the Haskell Integrated Development Environment. Visually, it looks pretty much like Eclipse. He can choose among a set of customisable perspectives for development, editing, browsing, etc. Each perspective is composed by multiple views displaying different kind of data (Haskell modules, stack traces, etc). Internally the IDE is based on a 'remote functional application framework': a simple, flexible way of composing statically-typed functions in a networked environment. Functions (or possibly first-class modules) are made available on the Internet as source code and/or endpoints (opaque network-accessible implementations). Functions can take as parameters additional functions. The IDE window manager is one such function that takes as parameters the functions that implements the perspectives. In turn, perspectives take as parameters the functions that implement the views and so on recursively. The Haskell editor, for example, take as a parameter a set of String -> [HaskellSymbol] functions that are used to provide code completion functionality. One such implementation is provided remotely by the Hoogle search engine. Simon has also configured its IDE to use two different function compositions to compile its code, one is made of stable versions of the GHC modules (parser, Haskell to Core-Haskell translator, code generators) , another uses more experimental versions of the same modules. Being a social, well-meaning guy, Simon marks his new module as 'public'. It then immediately appears on the Haskell Code Wiki. The code Wiki is a combination of a classic Wiki, in the sense that it allows for unrestricted Web based editing, and a revision control system as it supports multiple branches per page and the definition of named sets of specific versions of multiple Wiki pages (know as “releases” in the pre-distributed IDE age). Oleg notices the appearance of Simon's module, as it appears in the “Current Haskell News” view of his Haskell Browsing perspective and in a matter of a few hours publishes on the Wiki a new implementation that demonstrates that a compiler extension is not really required as, making use of a clever Peano encoding of type-level delimited-continuations, he can provide the same functionality and then some with a 40 lines library running on top of the existing GHC compiler. The publishing of his code causes a great commotion and induces many would-be Haskell programmers to give up in desperation and go back to Visual Basic. Some are so intellectually humiliated that give up programming entirely and move into the used car sale business. Luckily, later in the day (PhD students do not wake up early), Neil makes available its version that has half of the functionality of Simon's, not to mention Oleg's, but is explained in plain English, requires only Haskell 98 and compiles under YHC. As he is fond of Windows, he also makes a point of replacing all the "/"s in the source code with "\"s. A few days later, Titto, a perpetual Haskell beginner, takes Neil's version, as it is the only one that he can almost make sense of, changes the "\"s back to "/"s and compiles it in his GHC-based environment. Titto runs a Web site that is implemented using the same remote functional application framework used by his IDE. The Web site is made of a set of function/modules (Web front-end, application server, persistence back end) distributed on top of a few servers, for performance and reliability. With a few clicks, he replaces one of the existing Web site modules with a new implementation based on Neil's parallel library and upgrade its system without any of his users noticing. Up to you now, what is your dream? Best, titto