My previous live programming language [1] focused on separating out state, but it was not very scalable from an expressiveness standpoint. I'm of the opinion today that state exists and we should deal with it in place as opposed to trying to factor it out. The approach I'm working on (with a programming model I call Glitch) seems very promising, but the proof will have to be in the pudding. Stay tuned!

[1] http://research.microsoft.com/apps/pubs/default.aspx?id=1793...

Thanks for your response. And I'm agreeing with you that state should be dealt with and not pushed out. I'm not advocating some harsher functional programming designs.

What I meant was there needs to be constructs that guarantees that "this is going to be pure" and that "state can live here, not there".

D-lang has a start I believe, with a "pure" keyword.

I find that, as an enterprise developer working on large code base, most of my time is chasing bugs of silly null pointer exceptions and objects that are in unexpected state causing issues. Separating the grok of the code from the state eventually helps. And sadly there is little research spent in there, which is direct value to developers.

Increasing the quantity of pure code (and enforcing it) per class will reduce costly bugs.

I am amazed with what you can do though. I've had my shot at designing a language and miserably failed multiple times... But this why I'm raving about it... You may be able to solve this global problem that I never could.

Even if we factor state into a monad and/or pass it in as a parameter, imperative updates still exist and must be dealt with! Try writing a type checker or even a parser with pure functions, and you get to a point where you are passing in your state from the top anyways (either as a monad or explicitly). Many interesting computations simply aren't pure.

> Separating the grok of the code from the state eventually helps. And sadly there is little research spent in there, which is direct value to developers.

I would argue that there is plenty of research in this direction in the functional programming community. This is what monads seem to be about, at any rate. The problem is that developers don't want to adopt these solutions because they are way too inconvenient or even unworkable from an expressiveness standpoint. So maybe we should look for a better way to temper state without throwing it into a ghetto...

> I am amazed with what you can do though. I've had my shot at designing a language and miserably failed multiple times... But this why I'm raving about it... You may be able to solve this global problem that I never could.

We will see; I went through my purity stage relatively early and am being extremely pragmatic these days. The secret sauce in my current approach is to have state, but limit how it can be updated: operations in Glitch must be undoable and commutatively ordered, which are huge restrictions but the result is very compelling (re-execution is possible AND re-execution can occur in arbitrary orders).

Glad we're on the same page. I think.

So state would be dealt with in a similar approach than the command pattern?

Sounds exciting.

I guess where I come from is the scare when a pure function gets littered with impurity much later on, and all we have to warn us is a unit test. No matter how big the comment is above the method, nothing stops a developer from sticking a global variable in it, and it's out the window.

This forces code reviews to be lengthy, etc. If on the other hand we had a @pure section and @everything_else section, I feel this would make things easier to reason about... We could also measure the % of pure vs non-pure code, as code quality. All of this in an object oriented language of course. I'm no fan of Haskell.

You might want to check out Koka [1], which includes an effect system to separate pure and effectful computation. I believe there is also a demo of it online [2].

[1] http://research.microsoft.com/en-us/projects/koka/

[2] http://www.rise4fun.com/koka/tutorial

What you mean is a non-deterministic programming language? Similar to SICP 4.3? But different and expanded? http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-28.html... Code where expressions has success and failure paths, where the failure simply is reversal?

I'm not sure if the initial use of this is large enterprise applications. It's a fairly unexplored paradigm it'll be interesting to see where this goes with a company like Microsoft exploring it.