[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
tittoassini at gmail.com
Mon Jun 18 10:01:14 EDT 2007
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
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
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
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
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
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
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?
More information about the Haskell-Cafe