Re:A farewell note to a programming language
by lostcolony on Thursday December 04, 2014 @03:56PM
(#8701574)
"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.
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.