4 ms·

The ST monad would like a work with you :)

by tel 12y ago

asdf1234 12y ago
Pervasive use of ST, or almost any monad for that matter, leads to serious problems in Scala since you basically have to use trampolines and take a massive performance hit. It's also extremely verbose to do it correctly. It's a good solution in Haskell though.
- runT1ME 12y ago
  This is FUD. You often don't need trampolines and there are better solutions than trampolines.
  - asdf1234 12y ago
    It's debatable whether abusing Free is a better solution. Either way, programming like this is disgusting in Scala and comes with tons of caveats compared to Haskell.
lostcolony 12y ago
Which doesn't help the imperative programmer who is having to interact with functional code. And an ST monad makes no sense unless you're interacting with imperative code (obviously, hence your bringing it up), which means you already understand what imperative is, and are still having to convert your immutable structure to a mutable one, for the imperative code to operate on, and to recognize it will be modified in place; to use the ST monad the functional programmer already has to understand imperative programming. It also seems like it would fail to encapsulate the side effects an imperative function may have, since that function is able to interact with state elsewhere, that isn't actually encapsulated. I.e., the ST monad makes sense when dropping into update-in-place for performance reasons, but when there are side effects that are not ensconced within the monad (remember, the function you're calling was written by an imperative programmer, in a language that allows side effects outside of a monad; not Haskell), the ST monad does nothing to make it functional, and oh crap, now your functional programmer has the same problems as an imperative programmer, in having to figure out WTF this function just changed in some other imperative chunk of code, in some other process or object or whatever. So given imperative and functional paradigms, even using the ST monad, if the functional code is to call the imperative, and the imperative is to call the functional, both the functional and the imperative developers have to understand the other paradigm, -and- deal with the considerations of both. You've upped the complexity of your system considerably.
- tel 12y ago
  It doesn't allow free crossing between an (imperative + mutable) world and a (value-centric + immutable) world, no. It, instead, allows for clear boundaries to be set between the two and each to be embedded into the other. The ST monad also does exactly restrict the scale of effect of mutability which can occur. It's not a license for the imperative programmer to do whatever they want---it's a license for them to solve problems in the way they prefer within a particular ensconced region. If you want, you can write a program where everything lives inside of a giant ST monad layer. You always do this if you replace ST with IO, in fact. Each bit which can be made purely functional will be embedded into this monad and, for sake of sanity and testing, those functional bits ought to grow and grow. But it doesn't really demean the IO/ST segment. An imperative programmer can live happily there without much trouble at all.
  - lostcolony 12y ago
    "It doesn't allow free crossing between an (imperative + mutable) world and a (value-centric + immutable) world, no. It, instead, allows for clear boundaries to be set between the two and each to be embedded into the other." I wasn't saying you couldn't set boundaries; you have them implicitly simply by dint of the fact that in Scala, mutable/immutable is based on the type, and the type system is enough to enforce that. But now you have a performance penalty being introduced based on who works on a given part of the code, and one that can easily compound. "It's not a license for the imperative programmer to do whatever they want---it's a license for them to solve problems in the way they prefer within a particular ensconced region." But for the imperative programmer to know what not to do he/she has to understand functional coding, and choose to eschew certain techniques that might be viewed as acceptable from a purely imperative perspective. Please note, I didn't say you -can't- do it. Just that it's asking for trouble, and that either you have to understand both paradigms or you suffer a performance penalty (converting from mutable to immutable and vice versa). And that if you ever want to touch someone else's code you have to be familiar with the paradigm. Not proficient, but enough to realize what you have to do to be able to interact with it properly/safely, that that requires a broader depth of knowledge on the part of each team member than if you picked one paradigm, and that leaving them to know only their paradigm will not work. The imperative person has to figure out higher order functions, working with immutable data structures, etc, to make use of some of the stuff the functional guy has written, and the functional guy has to be comfortable with destructive updates, side effects, etc, to be able to make use of what the imperative guy has written. Yes, they both can interface with the other, but what they have to know is much broader, and every time they interact you risk bugs and performance penalties that you'd not have if you picked one paradigm alone.

The ST monad would like a work with you :)

by tel 12y ago

The ST monad would like a work with you :)

Pervasive use of ST, or almost any monad for that matter, leads to serious problems in Scala since you basically have to use trampolines and take a massive performance hit. It's also extremely verbose to do it correctly. It's a good solution in Haskell though.

runT1ME 12y ago
This is FUD. You often don't need trampolines and there are better solutions than trampolines.
- asdf1234 12y ago
  It's debatable whether abusing Free is a better solution. Either way, programming like this is disgusting in Scala and comes with tons of caveats compared to Haskell.

lostcolony 12y ago

Which doesn't help the imperative programmer who is having to interact with functional code. And an ST monad makes no sense unless you're interacting with imperative code (obviously, hence your bringing it up), which means you already understand what imperative is, and are still having to convert your immutable structure to a mutable one, for the imperative code to operate on, and to recognize it will be modified in place; to use the ST monad the functional programmer already has to understand imperative programming. It also seems like it would fail to encapsulate the side effects an imperative function may have, since that function is able to interact with state elsewhere, that isn't actually encapsulated. I.e., the ST monad makes sense when dropping into update-in-place for performance reasons, but when there are side effects that are not ensconced within the monad (remember, the function you're calling was written by an imperative programmer, in a language that allows side effects outside of a monad; not Haskell), the ST monad does nothing to make it functional, and oh crap, now your functional programmer has the same problems as an imperative programmer, in having to figure out WTF this function just changed in some other imperative chunk of code, in some other process or object or whatever. So given imperative and functional paradigms, even using the ST monad, if the functional code is to call the imperative, and the imperative is to call the functional, both the functional and the imperative developers have to understand the other paradigm, -and- deal with the considerations of both. You've upped the complexity of your system considerably.

tel 12y ago
It doesn't allow free crossing between an (imperative + mutable) world and a (value-centric + immutable) world, no. It, instead, allows for clear boundaries to be set between the two and each to be embedded into the other. The ST monad also does exactly restrict the scale of effect of mutability which can occur. It's not a license for the imperative programmer to do whatever they want---it's a license for them to solve problems in the way they prefer within a particular ensconced region. If you want, you can write a program where everything lives inside of a giant ST monad layer. You always do this if you replace ST with IO, in fact. Each bit which can be made purely functional will be embedded into this monad and, for sake of sanity and testing, those functional bits ought to grow and grow. But it doesn't really demean the IO/ST segment. An imperative programmer can live happily there without much trouble at all.
- lostcolony 12y ago
  "It doesn't allow free crossing between an (imperative + mutable) world and a (value-centric + immutable) world, no. It, instead, allows for clear boundaries to be set between the two and each to be embedded into the other." I wasn't saying you couldn't set boundaries; you have them implicitly simply by dint of the fact that in Scala, mutable/immutable is based on the type, and the type system is enough to enforce that. But now you have a performance penalty being introduced based on who works on a given part of the code, and one that can easily compound. "It's not a license for the imperative programmer to do whatever they want---it's a license for them to solve problems in the way they prefer within a particular ensconced region." But for the imperative programmer to know what not to do he/she has to understand functional coding, and choose to eschew certain techniques that might be viewed as acceptable from a purely imperative perspective. Please note, I didn't say you -can't- do it. Just that it's asking for trouble, and that either you have to understand both paradigms or you suffer a performance penalty (converting from mutable to immutable and vice versa). And that if you ever want to touch someone else's code you have to be familiar with the paradigm. Not proficient, but enough to realize what you have to do to be able to interact with it properly/safely, that that requires a broader depth of knowledge on the part of each team member than if you picked one paradigm, and that leaving them to know only their paradigm will not work. The imperative person has to figure out higher order functions, working with immutable data structures, etc, to make use of some of the stuff the functional guy has written, and the functional guy has to be comfortable with destructive updates, side effects, etc, to be able to make use of what the imperative guy has written. Yes, they both can interface with the other, but what they have to know is much broader, and every time they interact you risk bugs and performance penalties that you'd not have if you picked one paradigm alone.