4 ms·

> EDIT: of course this is good; such a language would be beyond nightmarish. By which i mean c++ or scala. Then go and compare the same code in go and Scala an

by idobai 11y ago

> EDIT: of course this is good; such a language would be beyond nightmarish. By which i mean c++ or scala. Then go and compare the same code in go and Scala and see which is more "nightmarish". You see Scala as a complex language because you need to learn something before you use it while go is almost the opposite - you may get it in an afternoon and create repetitive, boilerplatish and unmaintanable mess.

mlvljr 11y ago
This Scala maintainer disagrees, as we know: https://www.youtube.com/watch?v=TS1lpKBMkgg https://www.youtube.com/watch?v=TS1lpKBMkgg
duaneb 11y ago
> You see Scala as a complex language because you need to learn something before you use it No, I see Scala as a complex language because—much like C++—each library uses its own curious dialect. There is no community consensus on the balance between the object-oriented and functional. It's a mess, albeit a mess I'd prefer over most other languages. But dealing with implicits, language changes between versions, and "default" trait implementations (e.g. `val foo = Set()` is a simple example) makes me consider the language nightmarish.
- idobai 11y ago
  > each library uses its own curious dialect That's the point of high-level languages - to create effective DSLs... > There is no community consensus on the balance between the object-oriented and functional. We mix it - there is neither functional nor oop camp at Scala, only objecto-functional - which makes our life easier with decent type and modular systems. >But dealing with implicits What's so hard about implicits? One of the easiest feature in PLT. It means to do things implicitly - implicitly waiting for a parameter, implicitly converting something or implicitly extending types with methods. > language changes between versions That's the point of versions - to release changes. And no, there aren't as many breaking changes to destroy your workflow if you didn't use any type-level magic. > and "default" trait implementations (e.g. `val foo = Set()` is a simple example) val foo = Set() means foo is an empty Set - why does it bother you? It helps to abstract your code and removes unwanted specializations. If you want to use concrete types nothing gonna stop you from that.

by idobai 11y ago

mlvljr 11y ago

This Scala maintainer disagrees, as we know: https://www.youtube.com/watch?v=TS1lpKBMkgg https://www.youtube.com/watch?v=TS1lpKBMkgg

duaneb 11y ago

> You see Scala as a complex language because you need to learn something before you use it No, I see Scala as a complex language because—much like C++—each library uses its own curious dialect. There is no community consensus on the balance between the object-oriented and functional. It's a mess, albeit a mess I'd prefer over most other languages. But dealing with implicits, language changes between versions, and "default" trait implementations (e.g. `val foo = Set()` is a simple example) makes me consider the language nightmarish.

idobai 11y ago
> each library uses its own curious dialect That's the point of high-level languages - to create effective DSLs... > There is no community consensus on the balance between the object-oriented and functional. We mix it - there is neither functional nor oop camp at Scala, only objecto-functional - which makes our life easier with decent type and modular systems. >But dealing with implicits What's so hard about implicits? One of the easiest feature in PLT. It means to do things implicitly - implicitly waiting for a parameter, implicitly converting something or implicitly extending types with methods. > language changes between versions That's the point of versions - to release changes. And no, there aren't as many breaking changes to destroy your workflow if you didn't use any type-level magic. > and "default" trait implementations (e.g. `val foo = Set()` is a simple example) val foo = Set() means foo is an empty Set - why does it bother you? It helps to abstract your code and removes unwanted specializations. If you want to use concrete types nothing gonna stop you from that.