HN Theater @HNTheaterMonth

Dotty is moving in this direction with Implicit Function Types.

https://dotty.epfl.ch/docs/reference/implicit-function-types...

https://www.youtube.com/watch?v=YXDm3WHZT5g&feature=youtu.be

⬐ hota_mazi

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

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

Indeed, Guice even recommends not to use (static) final fields.

https://github.com/google/guice/wiki/Injections

⬐ hota_mazi

I was talking about regular (instance) fields, not static ones.

⬐ fnl

Right. "class fields" as opposed to "instance fields" had me confused.

⬐ hota_mazi

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.

⬐ doikor

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

> 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

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)

⬐ fnl

Sadly, I agree on your beef about implicits. They are a nice idea, but are far to easy to abuse to "hide" poor design.

⬐ dominotw

I started scala with Akka Http and magnet pattern[1] is the most convoluted, disgusting abuse of any language feature i've encountered. I really dislike implicits, implicit conversions ect, doesn't matter how awesome features it enables you to use.

Can implicit fans explain to me how I am supposed to navigate to the correct overloaded method in Magnet pattern? Even IDE's like intellij Idea have no idea what to navigate to. If its so hard of an IDE to figure out, how are humans supposed to deal with this.

http://spray.io/blog/2012-12-13-the-magnet-pattern/

⬐ MrBuddyCasino

And I thought I was the only only to go "wtf" when I first read about the magnet pattern. They claimed it to be "elegant", but it really is only "clever" in the worst possible way and makes it hard to reason about the code.

I've got a theory that the type of people doing overly complex Java enterprise (see EJB 2.1) 15 years ago haven't vanished, they're just doing Scala now.

⬐ doikor

Magnet pattern is purely about making the code you write nicer to look at. (for spray it had more reasons to exist but for akka-http it is purely a usability problem)

Basically it allows you to write

  def f[T](fMagnet: FMagnet[T]): X => Y

  f(t) { x =>
    // ...
  }

instead of

  def f[T](t: T)(implicit tc: TC[T]): X => Y

  f(t).apply { x =>
    // ...
  }

so just about removing one ".apply"

(see https://github.com/akka/akka-http/issues/100 where i copy pasted the code bits from)

But yeah first time I read up on the magnet pattern it was a wtf moment.

⬐ s4vi0r

If you have to write that kind of code for work you're probably out of luck, but if you're comfortable with FP and have some control over your stack I'd suggest the typelevel stack. I didn't know what the magnet pattern was until you just said so, and it seems like an awful idea relying on implicit abuse on the level of the cake pattern - something which has been discouraged for the last 4 years now.

Implicits are great, and allow you to do some really amazing things, but you have to be careful not to abuse them or risk making your code take forever to compile and be impossible to debug.

⬐ s4vi0r

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

Why do you prefer [] to <> for type parameters?

⬐ simon_o

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

> 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.

⬐ pleasecalllater

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

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

⬐ Veedrac

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.

⬐ alexandercrohde

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

Scala just seems like a nightmare, sorry.

⬐ virtualwhys

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

⬐ fnl

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

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

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

> 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

[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

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.