7 ms·

Plain Functional Programming by Martin Odersky [video]

103 points by cfarre 9y ago

virtualwhys 9y ago
Implicit function types in the next version of Scala look very interesting. The main example in the presentation compares Kleisli functors to impure imperative code, and then gradually transforms the imperative code to Kleisli equivalent using implicit function types without changing the body of the imperative code -- that was pretty cool. I don't know if Scala 3 will be a game changer wrt to language adoption, but it's certainly going to deliver a lot of compelling new features/enhancements [1] Based on the 6 week rolling release schedule a stable release should land presumably no later than this summer? That seems wildly optimistic but they released 0.4 last month... [1] http://dotty.epfl.ch/#so-features http://dotty.epfl.ch/#so-features
- fnl 9y ago
  Indeed, if people would only use implicits the way Odersky recommends, I'd love Scala. The problem is, too many people do exactly what he warns about in this video. And so my love-hate relationship continues... :-)
  - virtualwhys 9y ago
    If you're referring to implicit conversions, IIRC, those will have to be defined in the same source file in which they are used in Scala 3. Otherwise, refresh my memory, what was he warning about with implicits? There's currently no way around definition site boilerplate (e.g. `implicit name: Type`); `implicit` keyword and providing a variable name are required. Implicit function types eliminate definition site boilerplate while providing function composition -- looks like a solid enhancement for FP in Scala.
    - fnl 9y ago
      That sounds like a great idea. So no more importing of implicits in Scala 3 to use them on methods of another package (or namespace)? That would make them quite a lot more "wieldable". What Odersky warns about is defining implicits on built-in types. Which IMO too often gets abused to hide poor design.
    - tekacs 9y ago
      > If you're referring to implicit conversions, IIRC, those will have to be defined in the same source file in which they are used in Scala 3. That PR [1] is (IMO thankfully) not merged yet (marked as on hold) and reminds me of the indentation-based syntax proposal - ambitious, far from consensus on it being 'a good thing' by actual users, full of workarounds or escape hatches being sought by everyone, almost unilateral and very little to suggest it's even solving the problem it claims to (and it's fuzzy on what that is, exactly)[2]. Matching Rust's rules on this seems like the source motivator for Odersky and that only leads me to recall a conversation I had with a friend on these two languages and about a dozen or so practical, dramatically boilerplate- or complexity-reducing solutions that library authors or I had coded up; these would be either outlawed or made into large, complex workarounds under this scheme (Rust rules). Even in a codebase directly under my purview, we would have to duplicate implicits across modules (and keep them in sync), merge deliberately-separated modules and give up on some functionality altogether to support this proposal. These are mostly 'free' additional type safety constraints that we would just have to give up on. I'm not against making changes to make implicits easier to 'see'[3] - I'd only say that an approach with the above problems that gets worked around anyway is not the solution. [1]: https://github.com/lampepfl/dotty/pull/2060 https://github.com/lampepfl/dotty/pull/2060 [2]: Indeed even in this HN thread there are people criticising implicit parameters in a bunch of places (definitely not going away, IIRC Odersky likes them) - when people say 'they don't like implicits', between the various user demands they might well be removed in every variation. [3]: Indeed in IntelliJ IDEA and Ensime, every implicit conversion is underlined at the point of use. In that thread, someone suggests making implicits importable only with a modifier.
  - Randgalt 9y ago
    So true. Implicit parameter explosion is one the worst aspects of maintaining Scala code. In larger projects trying to comprehend how to import and understand which implicit parameters are used/needed can be maddening.
alexandercrohde 9y ago
I find this video really confusing. It presents the "simplest" functional solution [19:00] then shows us a bunch of complicated solutions and argues against them. But most of these complicated solutions (Kleisi) I imagine most viewers didn't even know about to begin with.
draw_down 9y ago
Scala just seems like a nightmare, sorry.
hota_mazi 9y ago
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.
Veedrac 9y ago
If the hard part of your problem is that you have to write "config: Config" a few times, either your problem is so easy that you should just get on with it or your solution is so badly designed you managed to ignore all the real issues and you should take a few dozen steps back and look at the actual domain. None of this talk seemed to have anything to do with actual software or the issues thereof.
pleasecalllater 9y ago
How about testing the objects which use the 'implicit' things instead of directly passed arguments. Can I just mock the implicits, and test behavior of the function with fully mocked world?
honey_bager 9y ago
I may be missing the point here, but can't you make the config object immutable? val instead of var?

103 points by cfarre 9y ago

Implicit function types in the next version of Scala look very interesting. The main example in the presentation compares Kleisli functors to impure imperative code, and then gradually transforms the imperative code to Kleisli equivalent using implicit function types without changing the body of the imperative code -- that was pretty cool. I don't know if Scala 3 will be a game changer wrt to language adoption, but it's certainly going to deliver a lot of compelling new features/enhancements [1] Based on the 6 week rolling release schedule a stable release should land presumably no later than this summer? That seems wildly optimistic but they released 0.4 last month... [1] http://dotty.epfl.ch/#so-features http://dotty.epfl.ch/#so-features

fnl 9y ago
Indeed, if people would only use implicits the way Odersky recommends, I'd love Scala. The problem is, too many people do exactly what he warns about in this video. And so my love-hate relationship continues... :-)
- virtualwhys 9y ago
  If you're referring to implicit conversions, IIRC, those will have to be defined in the same source file in which they are used in Scala 3. Otherwise, refresh my memory, what was he warning about with implicits? There's currently no way around definition site boilerplate (e.g. `implicit name: Type`); `implicit` keyword and providing a variable name are required. Implicit function types eliminate definition site boilerplate while providing function composition -- looks like a solid enhancement for FP in Scala.
  - fnl 9y ago
    That sounds like a great idea. So no more importing of implicits in Scala 3 to use them on methods of another package (or namespace)? That would make them quite a lot more "wieldable". What Odersky warns about is defining implicits on built-in types. Which IMO too often gets abused to hide poor design.
  - tekacs 9y ago
    > If you're referring to implicit conversions, IIRC, those will have to be defined in the same source file in which they are used in Scala 3. That PR [1] is (IMO thankfully) not merged yet (marked as on hold) and reminds me of the indentation-based syntax proposal - ambitious, far from consensus on it being 'a good thing' by actual users, full of workarounds or escape hatches being sought by everyone, almost unilateral and very little to suggest it's even solving the problem it claims to (and it's fuzzy on what that is, exactly)[2]. Matching Rust's rules on this seems like the source motivator for Odersky and that only leads me to recall a conversation I had with a friend on these two languages and about a dozen or so practical, dramatically boilerplate- or complexity-reducing solutions that library authors or I had coded up; these would be either outlawed or made into large, complex workarounds under this scheme (Rust rules). Even in a codebase directly under my purview, we would have to duplicate implicits across modules (and keep them in sync), merge deliberately-separated modules and give up on some functionality altogether to support this proposal. These are mostly 'free' additional type safety constraints that we would just have to give up on. I'm not against making changes to make implicits easier to 'see'[3] - I'd only say that an approach with the above problems that gets worked around anyway is not the solution. [1]: https://github.com/lampepfl/dotty/pull/2060 https://github.com/lampepfl/dotty/pull/2060 [2]: Indeed even in this HN thread there are people criticising implicit parameters in a bunch of places (definitely not going away, IIRC Odersky likes them) - when people say 'they don't like implicits', between the various user demands they might well be removed in every variation. [3]: Indeed in IntelliJ IDEA and Ensime, every implicit conversion is underlined at the point of use. In that thread, someone suggests making implicits importable only with a modifier.
- Randgalt 9y ago
  So true. Implicit parameter explosion is one the worst aspects of maintaining Scala code. In larger projects trying to comprehend how to import and understand which implicit parameters are used/needed can be maddening.

alexandercrohde 9y ago

I find this video really confusing. It presents the "simplest" functional solution [19:00] then shows us a bunch of complicated solutions and argues against them. But most of these complicated solutions (Kleisi) I imagine most viewers didn't even know about to begin with.

draw_down 9y ago

Scala just seems like a nightmare, sorry.

hota_mazi 9y ago

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.

Veedrac 9y ago

If the hard part of your problem is that you have to write "config: Config" a few times, either your problem is so easy that you should just get on with it or your solution is so badly designed you managed to ignore all the real issues and you should take a few dozen steps back and look at the actual domain. None of this talk seemed to have anything to do with actual software or the issues thereof.

pleasecalllater 9y ago

How about testing the objects which use the 'implicit' things instead of directly passed arguments. Can I just mock the implicits, and test behavior of the function with fully mocked world?

honey_bager 9y ago

I may be missing the point here, but can't you make the config object immutable? val instead of var?