

Ask HN: Year in Review - matt1

With 2008 coming to an end it's important to reflect on what we've accomplished and more importantly, where we are going from here.<p>There was a post a few days ago about Mibbit's success (http://news.ycombinator.com/item?id=409643) that's a really great example of what a year of hard work can accomplish. One of the comments was that more people should post about their progress and I couldn't agree more.<p>With that in mind:<p>- What were you working on a year ago and where are you now? Lessons learned (especially for projects that didn't work out) are especially welcomed.<p>- Where do you hope you'll be a year from now?
======
baguasquirrel
I was working on a CAD program in OCaml a year ago. It was an interesting
exercise on what exactly _is_ state, and what needs state and what state isn't
(I'll post the program once I salvage my svn repo off the old HDD).

In short, I found that the most useful definition of state is a set of data
that is interrelated or correlated in some way, shape or form, but in actual
usage, those pieces of data interact weakly.

In terms of graph theory, if you were to say that we live in a purely
functional world, and all functions are bipartite graphs from one set of
points to another set of points, then "state" could be defined as those points
where the functions involved are _sparse_. Sparse can be defined as:

-most of the vertices involved are untouched in any given function -all of the vertices are involved in one function or another -all of the vertices are related in that you can reach one vertex from another by following the edges of the graph.

Using that definition of state, I found that it was easy to program everything
in a purely functional, no-side-effects paradigm, in OCaml, without using the
object system.

Furthermore, I found that the stateful bits tended to grow in an annoyingly
stateful manner, that is that they added edges to the graph at random (i.e. it
was hard to tell ahead of time what depended on what).

The difficulty in using named tuples to store state as such is that then all
the bits that need to modify state need to pass it around continuation style,
and it can be hard to know ahead of time when you want to be in the stateful
context or not.

Haskell beginners (like me) will understand this to be the "do I need to be in
the IO monad" problem. Indeed, the problem seems to manifest itself
differently in Haskell, but I am not sure of this yet because I'm still
learning Haskell.

Some hunches: \- I concluded that statefulness seems to be a function of what
you are building for. UI is stateful, but the backend work that supports it is
not.

-> Since the web's architecture enforces a client-server model, I argue that the whole statefulness debate is going to become moot for the backend supporting those services. Hybrid languages will be nice, but not really necessary.

\- Cellphones, with their need for a self-contained platform that can operate
somewhat independently of whether the connection is operating or not, may
benefit from hybrid languages.

~~~
matt1
Thank you for sharing -- unfortunately this thread wasn't as popular as I
imagined it would be... lesson learned.

