5 ms·

Is the Scala language simply too big? I tried to learn it once (years ago) and quickly found myself overwhelmed by the number of concepts. I remember feeling li

Is the Scala language simply too big? I tried to learn it once (years ago) and quickly found myself overwhelmed by the number of concepts. I remember feeling like 80% of power of the language could have been achieved with 20% of the complexity. The latest Java releases are somewhat proving this with functional interfaces and records.

MrPowers 6y ago
There are certainly folks that argue the language it too big. Here's a great talk arguing that a lot of language features should be eliminated and Scala should be made a functional programming language: https://www.youtube.com/watch?v=v8IQ-X2HkGE&t=1s&ab_channel=Scalape%C3%B1o https://www.youtube.com/watch?v=v8IQ-X2HkGE&t=1s&ab_channel=... I'm personally in the camp of "keep Scala huge and weird and multi-paradigm, but just make less breaking changes and focus all efforts on making the ecosystem more stable".
- lptk 6y ago
  Worth noting that the presenter of this talk has done a complete 180 on subtyping as he's now using subtyping and variance in the core of his flagship library ZIO. He realized it was sometimes better to use the language's strengths rather than denigrate them for "ideological" reasons. Also worth noting that Scala is not a "very big" language in any sense that I know of. It has a lot fewer features than C#, for instance. And probably a comparable amount to TypeScript.
chriswarbo 6y ago
I've been at a Scala shop for just over a year, and it's certainly the case that there's a lot of overlap between language features. Personally I prefer having to make judgement calls as needed, rather than being shoehorned into a one-size-fits-all approach (e.g. like Java's class-based, single-inheritance OOP). One thing I find encouraging is that Scala features may become deprecated (either explicitly or de facto) if an overlapping feature is added that works 'better'. Examples I've come across are Manifest getting replaced by TypeTag and implicit coercions getting replaced by implicit classes.
tpetry 6y ago
Had the same feeling many years ago when i wanted to learn it. Bought the book of some the main creator (?) behind scala and started to read and experiment with on a weekend. But every chapter was filled with many completely different ways on how to solve something. In the end i decided that scala looks really great, but will be really problematic in a team if everything can be done on so many different styles. It looked for me like someone wanted to add every existing language into one single language.
- thinkharderdev 6y ago
  I don't see this as a particularly bad problem in Scala tbh. Any language that is mature enough to be used for a large project will include many different ways of solving common problems. I'm old enough to remember listening to J2EE developers arguing endlessly about which GoF design patterns to use in which situations, usually resulting in using roughly all of them in one way or another so everyone could feel included.
  - dfgdghdf 6y ago
    But with the old GoF debates all of those patterns were built on a very small set of primitives. In fact, that's why the patterns were necessary! Scala combines (at least) 2 major paradigms into one language.
devonkim 6y ago
A lot of the problems with Scala echo many of the problems that people used to write about Perl codebases minus specific language quirks like typing and objects. The problem with complex, rich languages is that it doesn't guarantee anything about the wisdom of programmers to pick, choose, and abuse from the features that wouldn't be easily legible to future maintainers. Somehow Scala has a lot of the issues that I feared would have impacted Typescript by now (yet hasn't) so I'd be interested in comparing and contrast why Typescript isn't perceived as having the kinds of issues Scala does when on paper they sound similar in features and technical challenges. Having worked on a lot of legacy codebases both creating and inheriting I'm quite interested in practices that balance rapidly prototyping and deploying systems and gracefully degrading when projects lose people and funding. It seems tragic to see so much of the work of our lives thrown away so fast.
- tayo42 6y ago
  From a quick google search it looks like ts/js doesn't let you define custom operators like Scala does. Scalas implicit stuff is messy too. The original article mostly talked about libraries though
  - devonkim 6y ago
    Scala's operator overloading and implicits are known sharp edges (and don't get me started on XML literals) but the article doesn't mention those as hindrances for maintainability. Package dependencies are not necessarily a language issue and become more about conventions of its community. Comparatively, people aren't complaining about dependency problems in the Clojure, Java, and even Kotlin communities because everything's mostly been solved through the Maven dependency conventions that can depend upon JVM and compiler versions, too. In contrast, I'm not seeing much mention of this issue in Typescript except with the typesVersions and the Node ecosystem is mature at this point with known compatibility mechanisms. So I'm here scratching my head at the point issues denoted in the OP wondering if I missed something critical about what makes Scala so different in its ecosystem conventions that a community couldn't fix over years. Even Node.js managed to work something out via Yarn

MrPowers 6y ago

There are certainly folks that argue the language it too big. Here's a great talk arguing that a lot of language features should be eliminated and Scala should be made a functional programming language: https://www.youtube.com/watch?v=v8IQ-X2HkGE&t=1s&ab_channel=Scalape%C3%B1o https://www.youtube.com/watch?v=v8IQ-X2HkGE&t=1s&ab_channel=... I'm personally in the camp of "keep Scala huge and weird and multi-paradigm, but just make less breaking changes and focus all efforts on making the ecosystem more stable".

lptk 6y ago
Worth noting that the presenter of this talk has done a complete 180 on subtyping as he's now using subtyping and variance in the core of his flagship library ZIO. He realized it was sometimes better to use the language's strengths rather than denigrate them for "ideological" reasons. Also worth noting that Scala is not a "very big" language in any sense that I know of. It has a lot fewer features than C#, for instance. And probably a comparable amount to TypeScript.

chriswarbo 6y ago

I've been at a Scala shop for just over a year, and it's certainly the case that there's a lot of overlap between language features. Personally I prefer having to make judgement calls as needed, rather than being shoehorned into a one-size-fits-all approach (e.g. like Java's class-based, single-inheritance OOP). One thing I find encouraging is that Scala features may become deprecated (either explicitly or de facto) if an overlapping feature is added that works 'better'. Examples I've come across are Manifest getting replaced by TypeTag and implicit coercions getting replaced by implicit classes.

tpetry 6y ago

Had the same feeling many years ago when i wanted to learn it. Bought the book of some the main creator (?) behind scala and started to read and experiment with on a weekend. But every chapter was filled with many completely different ways on how to solve something. In the end i decided that scala looks really great, but will be really problematic in a team if everything can be done on so many different styles. It looked for me like someone wanted to add every existing language into one single language.

thinkharderdev 6y ago
I don't see this as a particularly bad problem in Scala tbh. Any language that is mature enough to be used for a large project will include many different ways of solving common problems. I'm old enough to remember listening to J2EE developers arguing endlessly about which GoF design patterns to use in which situations, usually resulting in using roughly all of them in one way or another so everyone could feel included.
- dfgdghdf 6y ago
  But with the old GoF debates all of those patterns were built on a very small set of primitives. In fact, that's why the patterns were necessary! Scala combines (at least) 2 major paradigms into one language.

devonkim 6y ago

A lot of the problems with Scala echo many of the problems that people used to write about Perl codebases minus specific language quirks like typing and objects. The problem with complex, rich languages is that it doesn't guarantee anything about the wisdom of programmers to pick, choose, and abuse from the features that wouldn't be easily legible to future maintainers. Somehow Scala has a lot of the issues that I feared would have impacted Typescript by now (yet hasn't) so I'd be interested in comparing and contrast why Typescript isn't perceived as having the kinds of issues Scala does when on paper they sound similar in features and technical challenges. Having worked on a lot of legacy codebases both creating and inheriting I'm quite interested in practices that balance rapidly prototyping and deploying systems and gracefully degrading when projects lose people and funding. It seems tragic to see so much of the work of our lives thrown away so fast.

tayo42 6y ago
From a quick google search it looks like ts/js doesn't let you define custom operators like Scala does. Scalas implicit stuff is messy too. The original article mostly talked about libraries though
- devonkim 6y ago
  Scala's operator overloading and implicits are known sharp edges (and don't get me started on XML literals) but the article doesn't mention those as hindrances for maintainability. Package dependencies are not necessarily a language issue and become more about conventions of its community. Comparatively, people aren't complaining about dependency problems in the Clojure, Java, and even Kotlin communities because everything's mostly been solved through the Maven dependency conventions that can depend upon JVM and compiler versions, too. In contrast, I'm not seeing much mention of this issue in Typescript except with the typesVersions and the Node ecosystem is mature at this point with known compatibility mechanisms. So I'm here scratching my head at the point issues denoted in the OP wondering if I missed something critical about what makes Scala so different in its ecosystem conventions that a community couldn't fix over years. Even Node.js managed to work something out via Yarn