4 ms·

Having been primarily a Scala dev for the last 12 years I feel like people have slowly lost their minds over what pragmatic FP in Scala should be. People are w

by weego 5y ago

Having been primarily a Scala dev for the last 12 years I feel like people have slowly lost their minds over what pragmatic FP in Scala should be. People are willingly recreating the Java situation of 'I don't know the project yet but I know we need Spring!' with these ridiculous libraries from Haskell zealots for no obvious benefit. The ergonomics of this lib out of the box are literally worse for no reason, and worse than most other existing logging libs, because of it

foobiekr 5y ago
As an observer of this exact phenomenon, I suggest that it is due to the culture that comes with scala. In any given scala-centric organization, there's going to eventually be someone who has mastered the art of talking High Scala. Unless there is someone equally skilled on both dimensions (persuasion and SW eng), and unfortunately, someone approximately as senior, then there is an interative game where added abstraction and complexity become the primary way to distinguish yourself as a "real" engineer. This happens outside of scala shops, and I've seen it there, too, especially in C++ shops, but scala seems to attract these people.
- the_af 5y ago
  Erik Meijer, one of the early practitioners and contributors of Scala, and a coauthor of Odersky's Coursera courses on Scala, believes that "Mostly Functional Programming Doesn't Work" [1] Note it's "mostly functional" that doesn't work, not functional. He believes you have to go all in to reap its benefits, other way you're just deluding yourself with another faddish "miracle cure". All of the above are Meijer's opinions, I'm just the messenger. I know Odersky doesn't share these opinions. My own opinion: I'm unsure. Though I wonder, these days if you're not a strong FP advocate, and instead look to Scala as an improved Java, why not use Kotlin instead? [1] https://queue.acm.org/detail.cfm?id=2611829 https://queue.acm.org/detail.cfm?id=2611829
  - pjmlp 5y ago
    Erik Meijer has also brought FP into .NET via VB, a couple of years before Scala was relevant, or F# started to actually matter. So in a sense, he also tried a miracle cure before changing his mind.
    - the_af 5y ago
      I don't count it against him that he changed his mind. Changing his mind through experience makes sense to me :)
- flowcont 5y ago
  I'm at one of such organisations and you have concisely described the situation.
darksaints 5y ago
This problem with the scala community exists because it is composed of two different philosophical schools of thought. There's the ML camp, which is where we get all of the awesome pragmatic features of the ML family of languages (Martin Odersky has been very clear that Scala is philosophically an ML-family language). And then we get the Haskell camp, which rightly determined that the Haskell ecosystem was terrible. But instead of adopting an ML mindset of pragmatic functional programming, they decided to bring along their puritan religiosity with them and make the Scala ecosystem terrible too. The funny thing about Scala's pure functional programming ecosystem is that in its quest to make all programs pure in the sense of not having side effects, they pollute the entire ecosystem with hordes of incompatible dependencies, which need all sorts of bullshit adapters to make them play nice with each other. A far cry from what most people think of with the word "pure". To quote one of the best essays on the ML philosophy: > My point is that the ML module system can be deployed by you to impose the sorts of effect segregation imposed on you by default in Haskell. There is nothing special about Haskell that makes this possible, and nothing special about ML that inhibits it. It’s all a mode of use of modules. > So why don’t we do this by default? Because it’s not such a great idea. Yes, I know it sounds wonderful at first, but then you realize that it’s pretty horrible. Once you’re in the IO monad, you’re stuck there forever, and are reduced to Algol-style imperative programming. You cannot easily convert between functional and monadic style without a radical restructuring of code. And you are deprived of the useful concept of a benign effect. https://existentialtype.wordpress.com/2011/05/01/of-course-ml-has-monads/ https://existentialtype.wordpress.com/2011/05/01/of-course-m...
- pjmlp 5y ago
  Add to it the disease that all guest languages suffer from creating idiomatic wrappers instead of just directly calling into the rich ecosystem of the existing platform.
  - darksaints 5y ago
    That's true to some extent of the native language as well. Hibernate, for example, is a java(-bean) idiomatic wrapper on top of JDBC. Same goes for Log4J being a wrapper of java.util.logging, etc. Not quite the same thing as what Scala or Clojure have done, but far from just sticking to the basics. It's one thing to build a wrapper on top of a comprehensive standard library, and another thing altogether to build what is essentially an alternative standard library.

by weego 5y ago

foobiekr 5y ago

As an observer of this exact phenomenon, I suggest that it is due to the culture that comes with scala. In any given scala-centric organization, there's going to eventually be someone who has mastered the art of talking High Scala. Unless there is someone equally skilled on both dimensions (persuasion and SW eng), and unfortunately, someone approximately as senior, then there is an interative game where added abstraction and complexity become the primary way to distinguish yourself as a "real" engineer. This happens outside of scala shops, and I've seen it there, too, especially in C++ shops, but scala seems to attract these people.

the_af 5y ago
Erik Meijer, one of the early practitioners and contributors of Scala, and a coauthor of Odersky's Coursera courses on Scala, believes that "Mostly Functional Programming Doesn't Work" [1] Note it's "mostly functional" that doesn't work, not functional. He believes you have to go all in to reap its benefits, other way you're just deluding yourself with another faddish "miracle cure". All of the above are Meijer's opinions, I'm just the messenger. I know Odersky doesn't share these opinions. My own opinion: I'm unsure. Though I wonder, these days if you're not a strong FP advocate, and instead look to Scala as an improved Java, why not use Kotlin instead? [1] https://queue.acm.org/detail.cfm?id=2611829 https://queue.acm.org/detail.cfm?id=2611829
- pjmlp 5y ago
  Erik Meijer has also brought FP into .NET via VB, a couple of years before Scala was relevant, or F# started to actually matter. So in a sense, he also tried a miracle cure before changing his mind.
  - the_af 5y ago
    I don't count it against him that he changed his mind. Changing his mind through experience makes sense to me :)
flowcont 5y ago
I'm at one of such organisations and you have concisely described the situation.

darksaints 5y ago

This problem with the scala community exists because it is composed of two different philosophical schools of thought. There's the ML camp, which is where we get all of the awesome pragmatic features of the ML family of languages (Martin Odersky has been very clear that Scala is philosophically an ML-family language). And then we get the Haskell camp, which rightly determined that the Haskell ecosystem was terrible. But instead of adopting an ML mindset of pragmatic functional programming, they decided to bring along their puritan religiosity with them and make the Scala ecosystem terrible too. The funny thing about Scala's pure functional programming ecosystem is that in its quest to make all programs pure in the sense of not having side effects, they pollute the entire ecosystem with hordes of incompatible dependencies, which need all sorts of bullshit adapters to make them play nice with each other. A far cry from what most people think of with the word "pure". To quote one of the best essays on the ML philosophy: > My point is that the ML module system can be deployed by you to impose the sorts of effect segregation imposed on you by default in Haskell. There is nothing special about Haskell that makes this possible, and nothing special about ML that inhibits it. It’s all a mode of use of modules. > So why don’t we do this by default? Because it’s not such a great idea. Yes, I know it sounds wonderful at first, but then you realize that it’s pretty horrible. Once you’re in the IO monad, you’re stuck there forever, and are reduced to Algol-style imperative programming. You cannot easily convert between functional and monadic style without a radical restructuring of code. And you are deprived of the useful concept of a benign effect. https://existentialtype.wordpress.com/2011/05/01/of-course-ml-has-monads/ https://existentialtype.wordpress.com/2011/05/01/of-course-m...

pjmlp 5y ago
Add to it the disease that all guest languages suffer from creating idiomatic wrappers instead of just directly calling into the rich ecosystem of the existing platform.
- darksaints 5y ago
  That's true to some extent of the native language as well. Hibernate, for example, is a java(-bean) idiomatic wrapper on top of JDBC. Same goes for Log4J being a wrapper of java.util.logging, etc. Not quite the same thing as what Scala or Clojure have done, but far from just sticking to the basics. It's one thing to build a wrapper on top of a comprehensive standard library, and another thing altogether to build what is essentially an alternative standard library.