3 ms·
I think one of the points you're getting at here is that there's many different ways to solve a problem in Scala, versus something like Python. It's definitely
by tmcneal 13y ago
I think one of the points you're getting at here is that there's many different ways to solve a problem in Scala, versus something like Python. It's definitely true, as can be seen when comparing a codebase like Lift (https://github.com/lift/lift https://github.com/lift/lift) with Play (https://github.com/playframework/playframework https://github.com/playframework/playframework). Both are two MVC frameworks written in Scala but have vastly different coding styles.
The company I work for is a Scala shop, and we've found success in codifying our coding style using the Scalastyle linter. The combination of a linter and peer code reviews has been very helpful for us in figuring out which language constructs and libraries we use and which we shy away from.
- cygwin98 13y agoSounds like what C++ shops used to do: enforcing a subset of C++, prohibition on anything else. However, each shop has its own subset.
- pron 13y agoYou've done a very sensible thing. Yet, I'm pretty sure that most if not all the features you've decided to use are found in Kotlin. I'm not saying you should use Kotlin, as it's not ready. I'm bringing it up to demonstrate that what people want from Scala and what its designers had in mind are two completely different things. What people want from Scala is Kotlin, but what its designers built is a Java-Haskell hybrid with macros. And there's a bigger problem. Do you shy away from Scala collections? Because I have no idea how the types works there, I didn't want to spend who knows how many hours just to understand how a simple list is coded, and I certainly wasn't going to use something I couldn't understand. So while you may easily understand your own code, I don't know if your team understands this simplest, most basic of libraries.