
Plain Functional Programming by Martin Odersky [video] - cfarre
https://www.youtube.com/watch?v=YXDm3WHZT5g
======
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](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.

~~~
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](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.

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

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

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

