[Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.

[Pasqualino 'Titto' Assini]

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