3 ms·

Loving that concept of the @ symbol. Sadly I don't see that scaling to enterprise large applications, where you have little clues about what's calling your libr

by keyle 13y ago

Loving that concept of the @ symbol. Sadly I don't see that scaling to enterprise large applications, where you have little clues about what's calling your library with what values. As opposed to telling us that 2 + 2 will indeed produce 4, research money should be spent on separating pure code from state, I/O, etc. in languages like C#. That would be a huge advancement forward and cutting down the cost of bugs around the globe. This is cool though.

seanmcdirmid 13y ago
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=179365 http://research.microsoft.com/apps/pubs/default.aspx?id=1793...
- keyle 13y ago
  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.
  - seanmcdirmid 13y ago
    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).
    - keyle 13y ago
      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.
      - seanmcdirmid 13y ago
darkxanthos 13y ago
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.

by keyle 13y ago

seanmcdirmid 13y ago

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=179365 http://research.microsoft.com/apps/pubs/default.aspx?id=1793...

keyle 13y ago
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.
- seanmcdirmid 13y ago
  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).
  - keyle 13y ago
    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.
    - seanmcdirmid 13y ago

darkxanthos 13y ago

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.