5 ms·

I found your experience closely mirrors mine with scala. At my current shop we write mostly ruby and scala. The ruby code between developers looks much more uni

I found your experience closely mirrors mine with scala. At my current shop we write mostly ruby and scala. The ruby code between developers looks much more uniform than the scala code I believe due to the fact that while trying to please everyone scala hasn't yet developed much of "the scala way". I do hope this changes as I really enjoy scala. Currently my team is experimenting with style/punting tools like stylecop to try to bring a little consistency to our code. Too early to say how it will work out but I would love to hear from others how you try to bring a team style to a code base that will happily let a fully functional developer, a fully object oriented developer, a straight imperative developer, and someone who believes in mixing these things all work side by side. Mentally by giving up the possibility of nothing you have to learn everything which means loading a lot of the scala compiler up into your brain before even trying to read a bit of anyone else's code.

lostcolony 12y ago
Mixing an imperative developer with a functional developer? That's asking for trouble. You'll have to be converting between mutable and immutable data structures anywhere the two interact. Or forcing the imperative developer to be largely functional due to the immutable data structures everywhere that prevent him from using imperative approaches. Or forcing the functional developer to write in a largely imperative style due to the mutable data structures that prevent copying from being efficient, and can be mutated any time they pass out of his/her code. Or to put it another way; Scala as an idea may be fine; you can mix imperative and functional together, by picking which data structure and approach for a given problem is 'right'. But in a team environment? Touching someone else's code in a particular paradigm means you have to be familiar with, and expect, that paradigm. You can come up with a team that agrees on what paradigm everything must be written in (and that can be anywhere on the continuum), but you can't mix and match and expect developers to not have to learn every paradigm in use.
- tel 12y ago
  The ST monad would like a work with you :)
  - 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.
- lmm 12y ago
  Not "everything"; each codebase needs a particular style sure, but the great advantage of Scala is that your skanky 5-minute scripts and your carefully engineered five 9s backends can each be written in an appropriate style, and share the same libraries where that makes sense.
  - lostcolony 12y ago
    Imperative Bob needs to fix a bug in Functional Dave's code. Or just call it from his imperative code with an appropriate data structure. Or write a module for Functional Dave to call. All of those require being familiar with the functional paradigm, or a data type conversion. And vice versa. Sure, for code that doesn't interact, or that does only through an interface not defined by the language (i.e., through the OS, through sockets, whatever), the issues in style don't exist, and Scala kinda makes sense as a "single language that tries to be all things to all people". But on a shared codebase, with a 'team style', per the OP, that allows people to use what they're most familiar with...mixing paradigms is going to cause problems, and will force each dev to learn each paradigm in use. Please note I'm not saying there's no benefit to mixing paradigms, or that a language that includes multiple paradigms is bad, but rather that by allowing more paradigms the codebase you increase the breadth of knowledge necessary to work on that codebase, such that letting people stay in their comfortable, single paradigm bubble is impossible, at least if you want them directly interacting with the code written by someone else in a different paradigm.

lostcolony 12y ago

Mixing an imperative developer with a functional developer? That's asking for trouble. You'll have to be converting between mutable and immutable data structures anywhere the two interact. Or forcing the imperative developer to be largely functional due to the immutable data structures everywhere that prevent him from using imperative approaches. Or forcing the functional developer to write in a largely imperative style due to the mutable data structures that prevent copying from being efficient, and can be mutated any time they pass out of his/her code. Or to put it another way; Scala as an idea may be fine; you can mix imperative and functional together, by picking which data structure and approach for a given problem is 'right'. But in a team environment? Touching someone else's code in a particular paradigm means you have to be familiar with, and expect, that paradigm. You can come up with a team that agrees on what paradigm everything must be written in (and that can be anywhere on the continuum), but you can't mix and match and expect developers to not have to learn every paradigm in use.

tel 12y ago
The ST monad would like a work with you :)
- 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.
lmm 12y ago
Not "everything"; each codebase needs a particular style sure, but the great advantage of Scala is that your skanky 5-minute scripts and your carefully engineered five 9s backends can each be written in an appropriate style, and share the same libraries where that makes sense.
- lostcolony 12y ago
  Imperative Bob needs to fix a bug in Functional Dave's code. Or just call it from his imperative code with an appropriate data structure. Or write a module for Functional Dave to call. All of those require being familiar with the functional paradigm, or a data type conversion. And vice versa. Sure, for code that doesn't interact, or that does only through an interface not defined by the language (i.e., through the OS, through sockets, whatever), the issues in style don't exist, and Scala kinda makes sense as a "single language that tries to be all things to all people". But on a shared codebase, with a 'team style', per the OP, that allows people to use what they're most familiar with...mixing paradigms is going to cause problems, and will force each dev to learn each paradigm in use. Please note I'm not saying there's no benefit to mixing paradigms, or that a language that includes multiple paradigms is bad, but rather that by allowing more paradigms the codebase you increase the breadth of knowledge necessary to work on that codebase, such that letting people stay in their comfortable, single paradigm bubble is impossible, at least if you want them directly interacting with the code written by someone else in a different paradigm.