
Spreadsheet-like programming in Haskell - lelf
http://www.haskellforall.com/2014/06/spreadsheet-like-programming-in-haskell.html
======
thinkpad20
The article claims to be about the power of Applicative (and/or
spreadsheets?), but I've been writing Haskell for about a year and am
comfortable with all of the canonical Haskell abstractions including
`Applicative`, and this made basically zero sense to me. Beyond familiarity
with Applicative, the author also assumes the reader has facility with
Controller, Fold, Managed, View, the Pipes library, Lens, and a host of
functions I had never seen, such as last (not the Prelude version),
stdinLines, tick, and runMVC. Assuming this, he throws out the definition of
Updatable on top of that like it makes perfect sense ("just a Fold sitting in
front of a Managed Controller". Oh, well then.). Basically, two or three
paragraphs in and I am already completely lost. I don't even know what problem
it is we're trying to solve, and I have no idea what it has to do at all with
spreadsheets.

This is one of the downsides of Haskell; with so much emphasis on abstraction,
code often ends up being just that: so damn abstract that it's practically
inscrutable except to the very few who are familiar with what's going on. I
guess this article was written for an audience with very broad and detailed
knowledge of some complicated Haskell libraries -- meaning it's not so
important that anyone else be able to make head or tails out of what he's
talking about. Which is ok, but it does add to the impression that Haskell is
an exclusive club.

Also, this part sticks out as confusing: The type signature of `example` does
not include IO (unless Updatable has IO on under the hood), and yet the
language above suggests that it will change, i.e. that it is mutable:

> example will update every time lastLine or seconds updates, caching and
> reusing portions that do not update. For example, if lastLine updates then
> only the first field of Example will change. Similarly, if seconds updates
> then only the second field of Example will change.

Can someone clear this up for me?

~~~
gcv
I confess that I also do not understand the code in the article. (But I am
still only a student of Haskell.) I can only guess, based on my own work with
this idea of Cells-type programming, that the author means the following:

Suppose you have three data nodes, or cells: A, B, C, and D. A holds the value
5, B holds 3, C is defined as A+B, and D is defined as B*C. In a spreadsheet,
changing cell A will automatically update C, because C directly depends on A.
It will also update D because it transitively depends on B through C, and C
has changed. This library (and the Clojure one I mentioned in my other post)
lets you define data structures which behave the same way.

In a pure environment, you can emulate this using only functions. In a non-
pure environment, automatically updating values can be quite nice. You use
this to implicitly trigger linked behaviors. In a UI, this could mean changing
the state of several elements in response to some input without having to
explicitly say updateElementA(), updateElementB(), and so on.

~~~
thinkpad20
Thanks, yeah that's really helpful in getting a sense of the problem this is
attempting to address. I can definitely see why it's nice to have a simple (to
use) and compact API behind this. I wish that Gabriel had taken a similar
approach in explaining this library (start with a description of the problem,
then a high-level idea for a solution, then some specifics, etc). But
regardless, I have the utmost respect for Gonzalez, and give him props for
what looks like a(nother) great library.

------
mtford
I know a few of the investment banks have this kind of thing internally,
implemented as a DAG:
[http://en.wikipedia.org/wiki/Directed_acyclic_graph](http://en.wikipedia.org/wiki/Directed_acyclic_graph).
Cool stuff.

~~~
agumonkey
Many reactive dataflow programs are DAG based (at least most major 3D/CGI
packages are). Simple and powerful.

~~~
seanmcdirmid
My reactive programming language can handle cyclic dependencies; DAGs are too
inexpressive for general use (e.g. iterative computations). Getting that to
work correctly is kind of scary though (especially when non-monotonic change
is also supported).

~~~
a-saleh
What language would that be? I have skimmed through your papers, and they seem
interesting, but can't find any downloads to play with :-)

~~~
seanmcdirmid
Yinyang still. I want to release something soon, but need to find a purpose
for it; right now it's just fly by night language design. I was also thinking
about porting the editor to mono.cairo so more than just win users could play
with it (going to javascript is a no go given no multithreading with shared
memory).

------
gcv
I wrote something similar for Clojure:
[https://github.com/gcv/dgraph](https://github.com/gcv/dgraph)

~~~
dkersten
I don't know enough Haskell to really know what the article is talking about,
but to my very untrained eye, the idea also seems a little like this Clojure
library:
[https://github.com/tailrecursion/javelin](https://github.com/tailrecursion/javelin)

------
judk
Whenever I have tried spinning up a GUI on Haskell, I have always met with
disaster. I think only a native (not Virtual Machine) Linux installation is
the only hope, and that still is tricky.

Frustrating.

~~~
creichert
Have you tried HsQML?
[http://hackage.haskell.org/package/hsqml](http://hackage.haskell.org/package/hsqml)

------
cwyers
Looking at the example video provided I feel like I must be missing something;
it doesn't really resemble a spreadsheet to me.

~~~
mpweiher
Yep. That's something I see a lot when looking at stuff from the FP community:
map a commonly used term onto something that is easy to do with FP, losing
almost all relevant properties. Then claim how the ease of doing <commonly
used term> in FP shows the superiority of the FP approach.

~~~
davorak
Do you have any examples I can look at?

------
lifeisstillgood
I have two takeaways from this - first is that spreadsheets are an accessible
metaphor, and grok'able by many for whom coding as we know it is too long and
hard to learn.

So on the surface I think the superficial thrust of this is rather blunted.

But, and it's a really big but, software is the new literacy. And it is long
and hard to learn to read and write, but we force our children to do it as a
society because of the orders of magnitude benefits.

And so the same will become true of software - but not at the paltry
expressive level of say, pg's Blub language - but at something Haskell is
trying for.

I say there are three kinds of stages of sophistication for a person or a
company - not coding, automating and compiler.

We want our children to be operating at the compiler level - so we want them
to be using the languages Haskell will evolve into.

Now where did I put my copy of SICP?

Edit: Blub language not Blah...

------
Haskellwhen
I am eager to learn a new paradigm, haskell look interesting but reading the
post make me thing that a great language needs someone great at explaining the
core concepts, ideas and problems. Haskell for all seems to be a
contradictions because to be understood by all is expensive in time and
effort. Hope to learn more about haskell.

~~~
klrr
Learning Haskell is a deep rabbit hole. Make sure you decide when it is
enough, there's _tons_ to learn and you can't be an expert on everything and
_you don 't have to_ programming in Haskell.

------
tremols
I am experimenting with something similar for a java web framework
[https://github.com/constructo/chemflow](https://github.com/constructo/chemflow)
. Its kind of sketchy right now but achieves the spreadsheet-like programming
nicely.

~~~
tremols
To ellaborate a bit further, I don't know haskell but I can agree that the
authors code doesn't look like spreadsheet programming.

My approach is inspired by join calculus which is centered on the concept of
waiting on a set of signals/cells to trigger a reaction (I ignore the
concurrency capabilities of join calculus which make it a bit more complex).
It seems to me that FRP takes the long route to achieve this since its focused
on event handling.

Anyhow, this can be easily achieved with a simplified cactus stack where each
stack "frame" holds a reference to its parent so that it notifies its parent
when its value is set, then when all of the stack frames are ready the
procedure associated to it is triggered.

This type of stack has some interesting capabilities including memory friendly
infinite recursion and compound-key data structures. I believe that it has
potential for artificial intelligence and the development of modern dataflow
languages.

------
eddyparkinson
Web App builder: Turning the idea upside down, this helps smart non
programmers create software with a spreadsheet. www.cellmaster.com.au (I only
have a few early adopters).

------
transfire
A really great example of why Haskell will be forever relegated to academic
circles.

~~~
ColinWright
Why do you say that? Your comment seems to be entirely negative, and you seem
to have seen something that I haven't. Please can you expand on it?

In particular, the cynical part of my mind wonders if it's simply because you
can't read the code, and because of that haven't really bothered to follow the
argument. I'm sure you must have deeper reasons that that, and I, for one,
would appreciate an explanation of your reasoning.

~~~
msie
As a newcomer to Haskell may I offer an explanation: the article is full of
jargon and thus hard to follow.

~~~
Gabriel439
Author here: the concept of `Applicative`s is unique to Haskell and has no
parallel in other programming languages. This makes the post difficult to
write to a broad audience. Instead, I just tried to show the neat things you
could do with `Applicative`s to try to entice people to learn more about them.

~~~
yummyfajitas
I don't think it's unique to Haskell. The Scalaz library for Scala also
provides Applicative:

[https://github.com/scalaz/scalaz/blob/scalaz-
seven/core/src/...](https://github.com/scalaz/scalaz/blob/scalaz-
seven/core/src/main/scala/scalaz/Applicative.scala)

Do they differ in some drastic way? (Note: I'm not super familiar with the
Haskell version.)

~~~
Gabriel439
Oh, I wasn't aware Scalaz had applicative. Then I stand corrected.

