4 ms·

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

by 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.

by tel 12y ago

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.