4 ms·

What are you doing running a company that uses Scala without having people who largely know the stuff already, though? Regardless of how quickly some newbie lea

What are you doing running a company that uses Scala without having people who largely know the stuff already, though? Regardless of how quickly some newbie learns, the senior folks should already know all that stuff, or at least most of it. If they don't, that's the actual problem.

Kamq 4y ago
As someone who works on a legacy scala codebase, Scala's an easy language to get into this situation with. Scala's flexible enough that the old lisp pitfalls apply (though not nearly to the extent of lisp). That is to say, learning the language itself doesn't necessarily mean you're going to have any sort of grasp on a particular codebase, or even a different part of the same codebase. There's a particular style of scala that involves bringing in and stringing together dsls. Which is both extremely powerful, and can make code completely unreadable to someone who doesn't know that exact combination of packages. If you're not careful, your bus-factor is 1 and even the other seniors won't have any idea what's going on right away.
- noisy_boy 4y ago
  > There's a particular style of scala that involves bringing in and stringing together dsls. Which is both extremely powerful, and can make code completely unreadable to someone who doesn't know that exact combination of packages. This is main point which, more often than not, turns out to be a negative for Scala (there could be specific circumstances where this may be a big positive but, usually not). The rule of thumb for me for Scala code is, only follow constructs/idioms/style mentioned in the Scala Book[0]. Most of the time, everything else is unnecessary trouble. [0]: https://docs.scala-lang.org/overviews/scala-book/introduction.html https://docs.scala-lang.org/overviews/scala-book/introductio...
  - Kamq 4y ago
    > there could be specific circumstances where this may be a big positive but, usually not I mean, I think that those circumstances would be a solo passion project. I still think scala is a beautiful and expressive language. But I think that expressiveness actually inhibits collaboration. If you're expressing novel thoughts in a novel way, you've added syntactic overhead to the already significant conceptual overhead. So, yeah. Quite personally rewarding, but I can't recommend it for a work project in good faith after having worked in it. Enterprise projects should probably use java/kotlin if they want to be on the jvm, or go/python/js if they don't.

Kamq 4y ago

As someone who works on a legacy scala codebase, Scala's an easy language to get into this situation with. Scala's flexible enough that the old lisp pitfalls apply (though not nearly to the extent of lisp). That is to say, learning the language itself doesn't necessarily mean you're going to have any sort of grasp on a particular codebase, or even a different part of the same codebase. There's a particular style of scala that involves bringing in and stringing together dsls. Which is both extremely powerful, and can make code completely unreadable to someone who doesn't know that exact combination of packages. If you're not careful, your bus-factor is 1 and even the other seniors won't have any idea what's going on right away.

noisy_boy 4y ago
> There's a particular style of scala that involves bringing in and stringing together dsls. Which is both extremely powerful, and can make code completely unreadable to someone who doesn't know that exact combination of packages. This is main point which, more often than not, turns out to be a negative for Scala (there could be specific circumstances where this may be a big positive but, usually not). The rule of thumb for me for Scala code is, only follow constructs/idioms/style mentioned in the Scala Book[0]. Most of the time, everything else is unnecessary trouble. [0]: https://docs.scala-lang.org/overviews/scala-book/introduction.html https://docs.scala-lang.org/overviews/scala-book/introductio...
- Kamq 4y ago
  > there could be specific circumstances where this may be a big positive but, usually not I mean, I think that those circumstances would be a solo passion project. I still think scala is a beautiful and expressive language. But I think that expressiveness actually inhibits collaboration. If you're expressing novel thoughts in a novel way, you've added syntactic overhead to the already significant conceptual overhead. So, yeah. Quite personally rewarding, but I can't recommend it for a work project in good faith after having worked in it. Enterprise projects should probably use java/kotlin if they want to be on the jvm, or go/python/js if they don't.