
Haskell on a Horse: a new web framework based on arrows and continuations - dons
http://haskell.on-a-horse.org/
======
w1ntermute
_To deal with high demand, the server is being restarted once a minute._

Wow, they really are trying to imitate Rails.

------
waqf
"Haskell on Horseback" would have more of a ring to it.

~~~
jamesbritt
Haskell on Horse would be more addictive.

(Actually, calling something $Foo$ on $Bar$ puts me off. It suggests the
developers are not starting out looking at what makes the base language unique
in its own right, and will likely make poor design choices from wanting to
mimic something from a different, incompatible, realm.)

~~~
Scriptor
I'm pretty sure they're referencing the Old Spice commercials and the
similarity to 'Ruby on Rails' is only coincidental. The framework itself looks
nothing like Rails.

~~~
jhpriestley
I haven't actually seen those commercials. The name is a pun of "Ruby on
Rails".

I intended the name to draw a contrast, not to suggest a similarity! The
metaphor of 'rails' is that ruby development is sped up by being kept on a
particular track ('convention over configuration') - there is also a
connotation of industrial strength, power, etc. A person on a horse calls to
mind the opposite characteristics: exploratory, unconstrained, human.

~~~
dons
Oh, I had also assumed you were referring to the Old Spice commercials. So
sclv's comment made no sense? ...

[http://www.reddit.com/r/programming/comments/cuq2u/haskell_o...](http://www.reddit.com/r/programming/comments/cuq2u/haskell_on_a_horse_a_new_web_framework_based_on/c0vf545)

~~~
jhpriestley
Well, I found his comment pretty funny, but I had to google it first to figure
out what he was talking about.

------
alttab
Does this support templating, data models, etc? How far removed is this from a
"traditional" MVC web framework and how can on-a-horse be applied in real
business? Does it have built-in support for ajax responses, dynamic partial
rendering etc?

~~~
davidw
I'm ok with proof of concept sort of things - everything has to start
somewhere. However, I think that having an idea of what it'll eventually be
good at helps. Haskell seems to be fairly performant... what else? Concise? I
suppose, although I can't read it enough to tell what it's even doing.

~~~
jerf
The following is my synthesis of current trends; I do not necessarily believe
it entirely and I'm not completely advocating it.

One of the recent focuses in the functional world has been composition. Object
orientation promised us the ability to have components that could be easily
strung together to make programs. It has basically failed. We have OO
frameworks and libraries, and we have little tiny OO containers, but the
levels inbetween have not manifested the way they were "supposed" to. And even
to the extent that libraries and frameworks have succeeded, they often don't
play well together. In particular, if you use my preferred definition of
"framework" vs. "library", which is that the framework calls you and you call
the library, it verges on the impossible to use two frameworks simultaneously.
That is to say, you can not compose two of them together.

If you say "Why would you want to do that?", the answer is really simple: You
want features from both. You're probably so used to the idea that this is
impossible that you've completely internalized it and can't hardly even think
about why you might want to do that without rebelling at the thought of how
obviously impossible that would be. But there's no fundamental reason why this
should be.

So, the Haskell functional community has been kicking around ideas about how
to provide truly compositional components. It is absolutely true that there
are libraries and frameworks already in existence, but they often don't
_compose_ well. The parts are very large and they often are built on
assumptions that either can't be satisfied simultaneously, or can only be
satisfied with great effort. This looks like one person's stab at solving the
problem.

If it sounds like I'm handwaving, to some extent I am. Functional-style
composition is hard to wrap your head around if you've been programming in OO
for long enough that you think in native OO, and I am not aware of generally
accepted terminology for this. It goes both down to a much finer granularity
than you are used to in OO (example: a monad is actually this little three-
line snippet thing that has been refactored out of all of the implementations
of monads, and it's a refactoring at a level so weird and subtle it is weird
to come at it if you're not used to it), and ideally up to that middle level
that OO is missing. It seems to be a relatively new focus in the community.
The goal they are shooting for is to cover that middle ground a lot more
richly than OO frameworks have. And again, I emphasize, it is not that OO
frameworks like Django have _no_ composition; it is that it is limited in ways
that are hard to even see if you've adjusted too much to the OO ways of
thought. I also want to highlight that this is a _goal_ ; there's no guarantee
this is actually possible on the web, but there are some aspects of Haskell
that may make it easier to do in that language that any other, in particular
the rigid focus on purity everywhere. (On the other hand, getting the strong
types to play together well can be a challenge too; with such strong typing as
there is in Haskell you have to get the types _exactly right_ or, virtually by
definition of "exactly right", you will be mandating wrong behavior or ban
safe behavior, with the mandates and bans being much stronger than in
languages with weaker type systems.)

On the web, we have special challenges in that an "atomic element" of a web
page may consist of HTML that is generated based on a call from a database and
a bit of this file over here, depend on a CSS rule being in the page, require
certain Javascript which may itself be generated from some data pulled from
some other IO source, may require additional images, and so on and so on.
Moreover, for performance reasons you need to be able to do things like
control where the <script> tags appear _exactly_ , you don't want to include
40 CSS files, one for each of the 40 individual components that a page happens
to have. And the community would like to make it so you have compile-time
assurances that the website has all necessary resources in it, so for instance
you can use strong typing to "assert" that the CSS a given component requires
is statically verified to exist. For one small bit of this, Google for "type-
safe url handling" for some discussion about how to make one small part of
this process type safe. Oh, and when all is said and done, it would be nice if
the types were still humanly-comprehensible. :) Working all of this to some
sort of compositional framework is going to be a challenge.

So, if you go back and look at the page having gotten through that wall of
text, I think it might help you work out what the author thinks is interesting
about an otherwise obviously-trivial "web framework". The "more complex
example" is the meat of the idea, in which some simple components are wired
together compositionally to produce a hierarchal expression manipulator, which
would take much more code in most other frameworks. (Though of course being
perfectly possible.) Of course by no means is this a manifestation of
everything I said above, I see no work on the things being composed with their
JS or CSS resources, and so on. This is more like a first step towards what I
described in the previous paragraph, not the completion by any means.

I don't know that anybody has spelled all these ideas at once; like I said,
this is my synthesis and you are getting it through my biases. But I thought
it might sort of answer your question.

~~~
alttab
You put into words what I couldn't put my finger on about functional
programming. With my introduction to ruby and prototype (over C), I'm finally
understanding the mathematical-monadic-compositional aspect to functional
programming that makes it so powerful.

Its not even what you do with it - its the emergent behavior that makes it so
compelling.

Basically what I think you've summed up (but in less words) is that this is a
proof-of-concept or a building-block for much more sophisticated examples,
showing real approaches of building complex and powerful (especially the UI
based expression analyzer) web applications with amazingly little code.

