3 ms·

Not really. If you check google trends now you can see that it _surpassed_ Scala after the Google announcement and while it was a bump in trends if you extrapol

by edem 9y ago

Not really. If you check google trends now you can see that it _surpassed_ Scala after the Google announcement and while it was a bump in trends if you extrapolate the trend it you can see that it will surpass Scala within a year. Higher kinded types in themselves don't have any business value so I don't see why it can't be displaced by Kotlin or Clojure. I don't see any "anti-intellectual hostility" either. Actually I'm working on a library which wraps Clojure's STM and persistent data structures. I like how Clojure works much more (you can opt-in to any extra features Clojure has to offer and they are not forced on you) compared to Scala. Clojure is a clean language with a very powerful and useful philosophy behind it, Scala on the other hand has a lot of tacked-on features and the whole language lacks consistency and philosophy (thus it lacks direction as well).

lmm 9y ago
> Higher kinded types in themselves don't have any business value They make it much easier to fulfil business requirements in a clear, maintainable way (and mean there's a huge space of libraries available to help with that), which is what programming is all about. > I like how Clojure works much more (you can opt-in to any extra features Clojure has to offer and they are not forced on you) compared to Scala. What exactly is "forced on you" in Scala? > Clojure is a clean language with a very powerful and useful philosophy behind it, Scala on the other hand has a lot of tacked-on features and the whole language lacks consistency and philosophy Clojure has a clean design as far as it goes, but the design is so spare that to do anything practical in it relies heavily on macros. That's a legitimate language design philosophy and I'm glad there are languages that pursue it, but I don't find it makes for maintainability in the long run; macros are too powerful to be able to reason about code that uses them, so for a maintainable codebase your macros need to be restricted to a subset of what's possible - and to be able to maintain that it would be better to standardize more restricted alternatives that cover the important use cases. What Scala features would you say are tacked-on? I find it very coherent, with just a few powerful, orthogonal features - it's not quite as minimal as Clojure, sure, but it feels like it's got a lot fewer special cases than Kotlin or any number of modern languages. The libraries some people have written are a lot more... variable, but that's not a sign of issues with the language - if anything it's the opposite.
- edem 9y ago
  > They make it much easier to fulfil business requirements in a clear, maintainable way Same stands for dsls, macros, multimethods, I can mean any feature in any language. HKTs are just one tool of many. > What exactly is "forced on you" in Scala? Any built-in language feature. For example no matter what I do `implicit` will be a reserved keyword and the language will make use of it. I can't opt out. In Clojure on the other hand there is [spec](https://clojure.org/guides/spec https://clojure.org/guides/spec) for example. If I want it I import it and all of its features are defined in terms of Clojure itself. The whole language feature is a library. I can add [the language itself](https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0 https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0) as a library to my project (which is what I do with Kotlin) and use all of its features like the STM, or persistent data structures. Can you do the same with scala? I doubt it. > Clojure has a clean design as far as it goes, but the design is so spare that to do anything practical in it relies heavily on macros. [...] macros are too powerful to be able to reason about code that uses them That's why Clojure has spec. It solves the reasoning problem. It is also incorrect to assume that you can't do anything practical without macros, it is quite the opposite. You can do anything without them but there are some special cases where macros are useful. You can read any lisp textbook and you will see this in every one of them. If you write any lisp code then you have to know that for your first few projects you will overuse them, then you might learn where they are really applicable. Name some special cases in Kotlin which are problematic. I can't name a single one from the top off my head despite the fact that I use the language for more than a year.
  - lmm 9y ago
    > Same stands for dsls, macros, multimethods, I can mean any feature in any language. HKTs are just one tool of many. Would you say those features have no business value then? I've met enough business problems that were best modelled with HKT that I don't believe a language without an equivalent feature could be as effective. > Any built-in language feature. For example no matter what I do `implicit` will be a reserved keyword and the language will make use of it. I can't opt out. Almost all languages have some keywords. But yeah, implicit is a language-level feature. It's got a very high power-to-weight ratio though; it has valuable use cases (typeclasses, extension methods, the magnet pattern) that couldn't otherwise be done in plain old code, unless all those things were their own language-level features. > In Clojure on the other hand there is [spec](https://clojure.org/guides/spec https://clojure.org/guides/spec) for example. If I want it I import it and all of its features are defined in terms of Clojure itself. The whole language feature is a library. I can add [the language itself](https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0 https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0) as a library to my project (which is what I do with Kotlin) and use all of its features like the STM, or persistent data structures. Can you do the same with scala? I doubt it. Plenty of Scala things are libraries, you absolutely can import the scala standard library and use its collections, its async implementation or the like from another JVM language (though they may not be terribly idiomatic there). I don't really see the distinction you're drawing? > Name some special cases in Kotlin which are problematic. I can't name a single one from the top off my head despite the fact that I use the language for more than a year. Nullable types are a special case that doesn't compose properly (null is expected to be used for errors but if you write generic code that does that and then one of the values you pass in is null then you've got a bug), and a special case in the syntax (can't write your own type that allows ?. if you want to e.g. include a reason-for-failure message). Platform types for Java interop are a special case (you can't always pull out repeated calls to a Java method into a utility method without changing the meaning). Extension methods are a special case (can't use them to implement an interface). Operators are a special case (can't have an interface that requires them).

by edem 9y ago

lmm 9y ago

> Higher kinded types in themselves don't have any business value They make it much easier to fulfil business requirements in a clear, maintainable way (and mean there's a huge space of libraries available to help with that), which is what programming is all about. > I like how Clojure works much more (you can opt-in to any extra features Clojure has to offer and they are not forced on you) compared to Scala. What exactly is "forced on you" in Scala? > Clojure is a clean language with a very powerful and useful philosophy behind it, Scala on the other hand has a lot of tacked-on features and the whole language lacks consistency and philosophy Clojure has a clean design as far as it goes, but the design is so spare that to do anything practical in it relies heavily on macros. That's a legitimate language design philosophy and I'm glad there are languages that pursue it, but I don't find it makes for maintainability in the long run; macros are too powerful to be able to reason about code that uses them, so for a maintainable codebase your macros need to be restricted to a subset of what's possible - and to be able to maintain that it would be better to standardize more restricted alternatives that cover the important use cases. What Scala features would you say are tacked-on? I find it very coherent, with just a few powerful, orthogonal features - it's not quite as minimal as Clojure, sure, but it feels like it's got a lot fewer special cases than Kotlin or any number of modern languages. The libraries some people have written are a lot more... variable, but that's not a sign of issues with the language - if anything it's the opposite.

edem 9y ago
> They make it much easier to fulfil business requirements in a clear, maintainable way Same stands for dsls, macros, multimethods, I can mean any feature in any language. HKTs are just one tool of many. > What exactly is "forced on you" in Scala? Any built-in language feature. For example no matter what I do `implicit` will be a reserved keyword and the language will make use of it. I can't opt out. In Clojure on the other hand there is [spec](https://clojure.org/guides/spec https://clojure.org/guides/spec) for example. If I want it I import it and all of its features are defined in terms of Clojure itself. The whole language feature is a library. I can add [the language itself](https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0 https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0) as a library to my project (which is what I do with Kotlin) and use all of its features like the STM, or persistent data structures. Can you do the same with scala? I doubt it. > Clojure has a clean design as far as it goes, but the design is so spare that to do anything practical in it relies heavily on macros. [...] macros are too powerful to be able to reason about code that uses them That's why Clojure has spec. It solves the reasoning problem. It is also incorrect to assume that you can't do anything practical without macros, it is quite the opposite. You can do anything without them but there are some special cases where macros are useful. You can read any lisp textbook and you will see this in every one of them. If you write any lisp code then you have to know that for your first few projects you will overuse them, then you might learn where they are really applicable. Name some special cases in Kotlin which are problematic. I can't name a single one from the top off my head despite the fact that I use the language for more than a year.
- lmm 9y ago
  > Same stands for dsls, macros, multimethods, I can mean any feature in any language. HKTs are just one tool of many. Would you say those features have no business value then? I've met enough business problems that were best modelled with HKT that I don't believe a language without an equivalent feature could be as effective. > Any built-in language feature. For example no matter what I do `implicit` will be a reserved keyword and the language will make use of it. I can't opt out. Almost all languages have some keywords. But yeah, implicit is a language-level feature. It's got a very high power-to-weight ratio though; it has valuable use cases (typeclasses, extension methods, the magnet pattern) that couldn't otherwise be done in plain old code, unless all those things were their own language-level features. > In Clojure on the other hand there is [spec](https://clojure.org/guides/spec https://clojure.org/guides/spec) for example. If I want it I import it and all of its features are defined in terms of Clojure itself. The whole language feature is a library. I can add [the language itself](https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0 https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0) as a library to my project (which is what I do with Kotlin) and use all of its features like the STM, or persistent data structures. Can you do the same with scala? I doubt it. Plenty of Scala things are libraries, you absolutely can import the scala standard library and use its collections, its async implementation or the like from another JVM language (though they may not be terribly idiomatic there). I don't really see the distinction you're drawing? > Name some special cases in Kotlin which are problematic. I can't name a single one from the top off my head despite the fact that I use the language for more than a year. Nullable types are a special case that doesn't compose properly (null is expected to be used for errors but if you write generic code that does that and then one of the values you pass in is null then you've got a bug), and a special case in the syntax (can't write your own type that allows ?. if you want to e.g. include a reason-for-failure message). Platform types for Java interop are a special case (you can't always pull out repeated calls to a Java method into a utility method without changing the meaning). Extension methods are a special case (can't use them to implement an interface). Operators are a special case (can't have an interface that requires them).