4 ms·

I can't believe Odersky still uses the grammar line count as proof that Scala is not complex. By that criterion, Brainfuck is the simplest language in existence

I can't believe Odersky still uses the grammar line count as proof that Scala is not complex. By that criterion, Brainfuck is the simplest language in existence. As for the implicit aspect, we already have a way to pass implicit parameters to functions: fields. These have the advantage to actually be visible, injectable, and their semantics can't change just because you modified one import line.

fnl 9y ago
Would class fields not be a solution based on mutable state? Isn't that exactly the problem Odersky addresses in the beginning that your state can get mutated while your transaction is ongoing?
- fnl 9y ago
  Indeed, Guice even recommends not to use (static) final fields. https://github.com/google/guice/wiki/Injections https://github.com/google/guice/wiki/Injections
  - hota_mazi 9y ago
    I was talking about regular (instance) fields, not static ones.
    - fnl 9y ago
      Right. "class fields" as opposed to "instance fields" had me confused.
- hota_mazi 9y ago
  Not necessarily. These fields can be references to immutable objects. Note that Dotty's implicit approach is similar in that respect, it doesn't prescribe anything in terms of mutability/immutability. But we've already gone down the path of implicits, they are the #1 complaint about Scala, the #1 reason why the compiler is so slow and one of the main reasons why people say that Scala code can be very hard to reason about. I can't believe Odersky is doubling down on the implicit approach with Dotty. He just seems to be stuck in a language design corner and not willing to look at other ways to approach this problem. It's programming language design myopia.
  - fnl 9y ago
    Sadly, I agree on your beef about implicits. They are a nice idea, but are far to easy to abuse to "hide" poor design.
  - doikor 9y ago
    Implicit parameters are one of my favorite features of the language. I think most of the ambiguity comes from the days when IDEs couldn’t tell you what implicit was being used. I see the implicit functions as a great addition to the language making certain kind of code much easier to reason about. Personally most of the “wtf is going on here” comes from implicit conversions and usage of symbols (both of which have thankfully gone out of style for the most part)
    - hota_mazi 9y ago
      > Implicit parameters are one of my favorite features of the language. The real question is: does the team you work with share your love of implicits? Implicits are fun to use but they lead to code that's very hard to follow, so it's not uncommon to come across people who love them but these same people don't always realize the kind of code they are writing until way later.
      - doikor 9y ago
        There is some learning curve for people not familiar with Scala (not enough Scala developers in the market here so we have to "train" new developers often) But in general I haven't heard that many complaints outside of the few places where we use them for type level programming (Shapeless. Where most of the complaints are related to compile times). But the goal is usually to hide this behind some library or easy to understand type class instance and using implicits and shapeless to automatically derive the instances. In general all the type class based stuff relies on implicits to be really useful and haven't really heard any complaints related to that pattern from anyone once they actually understand what type classes are and what they are used for. Almost all the other use we have for implicits is automatically passing some context around in the app. This is things like RequestContext traveling down through the app and transmitting it to the next service in the chain. Basically only used so you don't have to be manually passing it around all the time. (another common example of this is passing ExecutionContext around. Or the ctx: Context in scalac that Martin mentions which appears 2600 times. If having it as implicit parameter 2600 times is pain think about having to manually fill it in) Implicits conversions is something we try to say away from if possible (there are some valid use cases for it but be careful with it)
s4vi0r 9y ago
This is a ridiculous strawman. Brainfuck has a tiny grammar, yeah, but its deliberately designed so as not to be readable. It also has an odd method of execution (I.e. your program is a big tape of memory and you manipulate the cells to do stuff) that makes doing anything worthwhile impossible to reason about, especially with the opaque syntax added on top. Scala neither has opaque syntax (see: many/most new languages borrowing its name:type format, smartly choosing [] over <> for type parameters, etc) nor does it have some weird execution model. Its a perfectly reasonable metric to use when talking about a normal/popular language, especially when people who don't even use the language complain about it being bloated and compare it to C++ which has a grammar twice the size of Scala. I really wish people would stop spreading FUD over these kinds of things :/
- superlopuh 9y ago
  Why do you prefer [] to <> for type parameters?
  - simon_o 9y ago
    It is superior for readability and parsing, and combined together with ident: Type, you have a very consistent syntax (unlike other languages with generics, where you define e.g. generic methods one way, but call them in another).
- nine_k 9y ago
  > languages borrowing its name:type format To be honest, this format was first introduced by ALGOL around 1960. It does make more sense, though, compared to C's.

fnl 9y ago

Would class fields not be a solution based on mutable state? Isn't that exactly the problem Odersky addresses in the beginning that your state can get mutated while your transaction is ongoing?

fnl 9y ago
Indeed, Guice even recommends not to use (static) final fields. https://github.com/google/guice/wiki/Injections https://github.com/google/guice/wiki/Injections
- hota_mazi 9y ago
  I was talking about regular (instance) fields, not static ones.
  - fnl 9y ago
    Right. "class fields" as opposed to "instance fields" had me confused.
hota_mazi 9y ago
Not necessarily. These fields can be references to immutable objects. Note that Dotty's implicit approach is similar in that respect, it doesn't prescribe anything in terms of mutability/immutability. But we've already gone down the path of implicits, they are the #1 complaint about Scala, the #1 reason why the compiler is so slow and one of the main reasons why people say that Scala code can be very hard to reason about. I can't believe Odersky is doubling down on the implicit approach with Dotty. He just seems to be stuck in a language design corner and not willing to look at other ways to approach this problem. It's programming language design myopia.
- fnl 9y ago
  Sadly, I agree on your beef about implicits. They are a nice idea, but are far to easy to abuse to "hide" poor design.
- doikor 9y ago
  Implicit parameters are one of my favorite features of the language. I think most of the ambiguity comes from the days when IDEs couldn’t tell you what implicit was being used. I see the implicit functions as a great addition to the language making certain kind of code much easier to reason about. Personally most of the “wtf is going on here” comes from implicit conversions and usage of symbols (both of which have thankfully gone out of style for the most part)
  - hota_mazi 9y ago
    > Implicit parameters are one of my favorite features of the language. The real question is: does the team you work with share your love of implicits? Implicits are fun to use but they lead to code that's very hard to follow, so it's not uncommon to come across people who love them but these same people don't always realize the kind of code they are writing until way later.
    - doikor 9y ago
      There is some learning curve for people not familiar with Scala (not enough Scala developers in the market here so we have to "train" new developers often) But in general I haven't heard that many complaints outside of the few places where we use them for type level programming (Shapeless. Where most of the complaints are related to compile times). But the goal is usually to hide this behind some library or easy to understand type class instance and using implicits and shapeless to automatically derive the instances. In general all the type class based stuff relies on implicits to be really useful and haven't really heard any complaints related to that pattern from anyone once they actually understand what type classes are and what they are used for. Almost all the other use we have for implicits is automatically passing some context around in the app. This is things like RequestContext traveling down through the app and transmitting it to the next service in the chain. Basically only used so you don't have to be manually passing it around all the time. (another common example of this is passing ExecutionContext around. Or the ctx: Context in scalac that Martin mentions which appears 2600 times. If having it as implicit parameter 2600 times is pain think about having to manually fill it in) Implicits conversions is something we try to say away from if possible (there are some valid use cases for it but be careful with it)

s4vi0r 9y ago

This is a ridiculous strawman. Brainfuck has a tiny grammar, yeah, but its deliberately designed so as not to be readable. It also has an odd method of execution (I.e. your program is a big tape of memory and you manipulate the cells to do stuff) that makes doing anything worthwhile impossible to reason about, especially with the opaque syntax added on top. Scala neither has opaque syntax (see: many/most new languages borrowing its name:type format, smartly choosing [] over <> for type parameters, etc) nor does it have some weird execution model. Its a perfectly reasonable metric to use when talking about a normal/popular language, especially when people who don't even use the language complain about it being bloated and compare it to C++ which has a grammar twice the size of Scala. I really wish people would stop spreading FUD over these kinds of things :/

superlopuh 9y ago
Why do you prefer [] to <> for type parameters?
- simon_o 9y ago
  It is superior for readability and parsing, and combined together with ident: Type, you have a very consistent syntax (unlike other languages with generics, where you define e.g. generic methods one way, but call them in another).
nine_k 9y ago
> languages borrowing its name:type format To be honest, this format was first introduced by ALGOL around 1960. It does make more sense, though, compared to C's.