5 ms·

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

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
  - thu2111 6y ago
    Lack of correct leadership. Java, Kotlin, C# and TypeScript are led by companies that want usage. Scala was and still is primarily an academic exercise. Same problems as with Haskell - the leadership are paid to add random optimised-for-sounding-clever ideas to the language, not design a language in the gestalt that optimises for user success. In particular TypeScript is not a research language and therefore the documentation, marketing, leadership etc doesn't strongly emphasise convoluted FP type theory. That means the sort of people who really want to go wild with that stuff stay away.
    - devonkim 6y ago
      Scala's origins at EPFL under Odersky does give it a disadvantage given the history of academic origin languages in industry. OCaml was made at INRIA and it seems to have suffered the fate of becoming a niche language and toolchain for industry programmers. The Limbo programming language from Plan 9 didn't get very far until it was re-adapted and re-imagined as Go which has obviously gotten a lot of adoption from industry. I'm not an either/or kind of person and don't see why a language suitable for academic purposes can't be broadly useful in industry, but I would also agree that leadership that has little background in certain use cases may not design and orient the language accordingly.

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
- thu2111 6y ago
  Lack of correct leadership. Java, Kotlin, C# and TypeScript are led by companies that want usage. Scala was and still is primarily an academic exercise. Same problems as with Haskell - the leadership are paid to add random optimised-for-sounding-clever ideas to the language, not design a language in the gestalt that optimises for user success. In particular TypeScript is not a research language and therefore the documentation, marketing, leadership etc doesn't strongly emphasise convoluted FP type theory. That means the sort of people who really want to go wild with that stuff stay away.
  - devonkim 6y ago
    Scala's origins at EPFL under Odersky does give it a disadvantage given the history of academic origin languages in industry. OCaml was made at INRIA and it seems to have suffered the fate of becoming a niche language and toolchain for industry programmers. The Limbo programming language from Plan 9 didn't get very far until it was re-adapted and re-imagined as Go which has obviously gotten a lot of adoption from industry. I'm not an either/or kind of person and don't see why a language suitable for academic purposes can't be broadly useful in industry, but I would also agree that leadership that has little background in certain use cases may not design and orient the language accordingly.