5 ms·

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 ge

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.
  - the_af 5y ago
    I think calling Hibernate "a wrapper around JDBC" is overreaching. A wrapper brings to mind (at least to me) this idea of a thin layer, mostly a simple translator between two worlds, but in this case there's tons of added complexity and pitfalls on top of JDBC, and there's the whole ORM deal with attending object-relational impedance mismatch, the whole "ORM is the Vietnam of Computer Science", and a completely different can of worms!
  - pjmlp 5y ago
    Writing higher level abstractions for ease of use in same language as the platform is written on, and creating wrappers just because it looks "ugly" to do direct FFI calls to the host language isn't really the same thing.
- fulafel 5y ago
  In Clojure(Script) it seems to be a net positive because of the curation effect - the community generally has good taste in picking the good parts of the JVM/npm ecosystems and packaging those to for wide use. For example the de facto standard logging library doesn't use log4j but can interop with Java logging stuff and presents the same interface on both ClojureScript and JVM. (Also many Java libraries have imperative APIs for no good reason, and it's sometimes the wrapper can present a functional interface)
  - pjmlp 5y ago
    The reason being that they are older than Java 8, and not everyone buys into functional styles. Even on .NET, with LINQ having been introduced in .NET 3.5, there might come up some PR discussions that I will just give up and rewrite the code to the expectation level of the audience.
the_af 5y ago
Note Robert Harper, the author of Existential Type and one of the big names in ML, has a bizarre crusade against Haskell. I find it weird that so many of his articles seem to be lashing out against (the internet perception) of Haskell, almost a popularity contest between ML and Haskell, when the adoption of either language is marginal and could use some cooperation between the two, instead of framing it as a zero-sum competition. ML and Haskell are allies, not enemies. This obsession is a shame, since Robert Harper is obviously an intelligent person. I remember some of his feuds with people from the Haskell community were... embarrassing. Most feuds are embarrassing. The proglang community could do with fewer of those. I don't remember Simon Peyton Jones ever speaking ill of ML, for example. There's an example to follow!

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.
- the_af 5y ago
  I think calling Hibernate "a wrapper around JDBC" is overreaching. A wrapper brings to mind (at least to me) this idea of a thin layer, mostly a simple translator between two worlds, but in this case there's tons of added complexity and pitfalls on top of JDBC, and there's the whole ORM deal with attending object-relational impedance mismatch, the whole "ORM is the Vietnam of Computer Science", and a completely different can of worms!
- pjmlp 5y ago
  Writing higher level abstractions for ease of use in same language as the platform is written on, and creating wrappers just because it looks "ugly" to do direct FFI calls to the host language isn't really the same thing.
fulafel 5y ago
In Clojure(Script) it seems to be a net positive because of the curation effect - the community generally has good taste in picking the good parts of the JVM/npm ecosystems and packaging those to for wide use. For example the de facto standard logging library doesn't use log4j but can interop with Java logging stuff and presents the same interface on both ClojureScript and JVM. (Also many Java libraries have imperative APIs for no good reason, and it's sometimes the wrapper can present a functional interface)
- pjmlp 5y ago
  The reason being that they are older than Java 8, and not everyone buys into functional styles. Even on .NET, with LINQ having been introduced in .NET 3.5, there might come up some PR discussions that I will just give up and rewrite the code to the expectation level of the audience.

the_af 5y ago

Note Robert Harper, the author of Existential Type and one of the big names in ML, has a bizarre crusade against Haskell. I find it weird that so many of his articles seem to be lashing out against (the internet perception) of Haskell, almost a popularity contest between ML and Haskell, when the adoption of either language is marginal and could use some cooperation between the two, instead of framing it as a zero-sum competition. ML and Haskell are allies, not enemies. This obsession is a shame, since Robert Harper is obviously an intelligent person. I remember some of his feuds with people from the Haskell community were... embarrassing. Most feuds are embarrassing. The proglang community could do with fewer of those. I don't remember Simon Peyton Jones ever speaking ill of ML, for example. There's an example to follow!