4 ms·

> Declarativeness is a property of code which subsumes what professional developers typically refer to as functional and purely functional code. While real wor

by aikah 12y ago

> Declarativeness is a property of code which subsumes what professional developers typically refer to as functional and purely functional code. While real world applications don't allow us to solely rely on declarative code to solve all of our problems, we can embrace its positive qualities and learn to overcome its shortcomings by following two basic approaches: embedding and extending. I like the balanced conclusion. So as I understand it,languages like Haskell(which I dont know) wrap states into a type that can be passed to pure functions right?is that what monads are about? A bit like promises in javascript where the developpers wraps an eventual outcome into an object and can reason about his code without worrying about what the value will be or even if the value will be at all? More generally,how one does remove side-effects from OO code?since objects are statefull,or is the solution not using OO at all?

sqrt17 12y ago
A more paradigm-neutral notion of declarativity is that you separate intent (the function or relation that your program is to compute) from execution (the shoveling of bits that goes on in the actual execution of the program). For example, SQL or LinQ are declarative fragments embedded in an otherwise imperative/OO language, since you specify the intent, and behind the scenes, the database's query optimizer or the LinQ API can do all the optimizations they like because you've specified your intent and not a concrete plan for execution. In Haskell, treating state as data to be passed around has the advantage that you can also fork the state if you want to try out alternatives (i.e., search). Which means, you don't remove side-effects from OO code. You institute a contract between some provider of a declarative framework (that allows you to specify intents) and the consumer of said framework (who is supposed not to poke around in any state that the framework works on). I.e. state is seen in functional programming as undocumented API calls in imperative programming. In rare cases you need them, but you want to only use them where you actually get an advantage out of it, because it's bound to get in your way at some point if you're not careful.
mp8 12y ago
> So as I understand it,languages like Haskell(which I dont know) wrap states into a type that can be passed to pure functions right? I would restate this as: "In Haskell you write a description of a stateful computation." The "State Monad" is really just the illusion of mutable state, provided by passing the underlying state to each described computation. Actually-mutable state is possible with things like IORef, but these are impure.
- mbrock 12y ago
  You could also say it's just an implementation of mutable state. The "State" type and its operations are just a few lines of simple Haskell code. The implementation uses parameters and return values to thread state between functions. It's just a simple abstraction of a simple pattern of programming. It uses a monadic interface, which is convenient and gives you some syntactic sugar, but there's nothing magical about it. From the Haskell point of view, so called "actually-mutable" state is on the other hand deeply magical, because it lets you do exotic things like having one thread modify a value in another thread. And that's possible through things like IORefs. But it should be avoided as much as possible.
  - mp8 12y ago
    Really I just wanted to point out that the State Monad is not actually hiding any "real" mutation anywhere, nor is it related to the IO Monad- I was confused on this point for some time when learning Haskell.
seanmcdirmid 12y ago
Haskell actually lacks named state (in its safe world), meaning state is just a value to be passed around and returned. You can then index off of this state, but these names are then qualified. OOP is all about naming: objects encapsulate state, have identities if they are aliased, are thought of by humans in terms of nouns, have ontological is-a and has-a relationships, and so on. If it is just referential transparency you are after...then there are solutions for OOP (that also don't involve monads), but it requires a different programming model: http://research.microsoft.com/apps/pubs/default.aspx?id=211297 http://research.microsoft.com/apps/pubs/default.aspx?id=2112...
deleted 12y ago
[deleted]

by aikah 12y ago

sqrt17 12y ago

A more paradigm-neutral notion of declarativity is that you separate intent (the function or relation that your program is to compute) from execution (the shoveling of bits that goes on in the actual execution of the program). For example, SQL or LinQ are declarative fragments embedded in an otherwise imperative/OO language, since you specify the intent, and behind the scenes, the database's query optimizer or the LinQ API can do all the optimizations they like because you've specified your intent and not a concrete plan for execution. In Haskell, treating state as data to be passed around has the advantage that you can also fork the state if you want to try out alternatives (i.e., search). Which means, you don't remove side-effects from OO code. You institute a contract between some provider of a declarative framework (that allows you to specify intents) and the consumer of said framework (who is supposed not to poke around in any state that the framework works on). I.e. state is seen in functional programming as undocumented API calls in imperative programming. In rare cases you need them, but you want to only use them where you actually get an advantage out of it, because it's bound to get in your way at some point if you're not careful.

mp8 12y ago

> So as I understand it,languages like Haskell(which I dont know) wrap states into a type that can be passed to pure functions right? I would restate this as: "In Haskell you write a description of a stateful computation." The "State Monad" is really just the illusion of mutable state, provided by passing the underlying state to each described computation. Actually-mutable state is possible with things like IORef, but these are impure.

mbrock 12y ago
You could also say it's just an implementation of mutable state. The "State" type and its operations are just a few lines of simple Haskell code. The implementation uses parameters and return values to thread state between functions. It's just a simple abstraction of a simple pattern of programming. It uses a monadic interface, which is convenient and gives you some syntactic sugar, but there's nothing magical about it. From the Haskell point of view, so called "actually-mutable" state is on the other hand deeply magical, because it lets you do exotic things like having one thread modify a value in another thread. And that's possible through things like IORefs. But it should be avoided as much as possible.
- mp8 12y ago
  Really I just wanted to point out that the State Monad is not actually hiding any "real" mutation anywhere, nor is it related to the IO Monad- I was confused on this point for some time when learning Haskell.

seanmcdirmid 12y ago

Haskell actually lacks named state (in its safe world), meaning state is just a value to be passed around and returned. You can then index off of this state, but these names are then qualified. OOP is all about naming: objects encapsulate state, have identities if they are aliased, are thought of by humans in terms of nouns, have ontological is-a and has-a relationships, and so on. If it is just referential transparency you are after...then there are solutions for OOP (that also don't involve monads), but it requires a different programming model: http://research.microsoft.com/apps/pubs/default.aspx?id=211297 http://research.microsoft.com/apps/pubs/default.aspx?id=2112...

deleted 12y ago

[deleted]