I dont’ use cats-effects and monads.
For me they are too complicated …
Maybe i’m wrong.
3 Likes
Honestly, this comes down to actually learning it properly.
I do essentially nothing without monads – they’re the heart of nearly everything, and they’re really not hard if you learn them properly and practice them a little. I would guess that 3/4 of the methods I write are based on one monad or another.
Unfortunately, they’re often badly taught, so people wind up getting tied in knots. Introductions often spend too much time trying to explain mostly-irrelevant theory, at the cost of the basic “how to use them”. In my experience, a few examples are worth a hundred pages of boring details.
As for cats-effect, that’s a tad more complicated, but actually using it is largely pretty straightforward, especially if you already understand functional programming. (I generally recommend Adam Rosien’s Essential Effects as a good explanation of the major ins and outs.)
The core concept is that an IO represents an algorithm, and you build bigger IOs out of smaller ones, very much like ordinary functions. The only thing that’s unusual is that an IO is a data structure that encapsulates an algorithm, instead of raw code – and that buys you a remarkable amount of power.
(There’s lots more, of course. But that’s the heart of it.)
None of it’s trivial, mind. But I routinely bring junior engineers up to speed on this stuff in about three weeks. That’s real effort, to be sure, but I don’t think it’s really all that complicated.
4 Likes
I don’t use any of the Reactive or FP frameworks: Akka, Cats, Zio, etc.
My experience using Scala is that beginners typically bring themselves up to speed prettymuch instantly. Scala’s actually a pretty easy language unless you pile on additional complexity yourself. But you don’t have to, and can get remarkably far without. 3 weeks to get up to speed sounds like an eternity
Honestly taking weeks to bring someone up to speed, and all the above caveats, make it a tough sell. It’s great for the people who click with it, but its definitely a high-risk investment for IMO not huge returns. Performance/scalability is honestly not a big deal when the words biggest systems run on blocking Python/Ruby/PHP/Java, and for the same reason the level of safety of vanilla Scala should be enough for most use cases. And its far too easy for “often badly taught” to hit you/your-team directly and cause it to end in disaster
5 Likes
The inventor of Scala, Martin Odersky, previously this year made a blog post about “lean” Scala, promoting usage of Scala in a way that makes your code easy to understand, with the simplest possible abstractions that still do the job, while making systems safe to evolve:
5 Likes
I have always considered programming to be a mathematical exercise in which homomorphisms cost money (time and effort). Previously I was interested in programming in lambda calculus and a version of predicate logic, and then moved to higher order logic. But now I am interested in programming in type theory, because software I am developing is nicely implemented using compositions of types instead of a class hierarchy. I am learning Scala 3 and it is working nicely for my needs except for a JavaFX configuration issue that I aim to resolve soon. Having survived the Category Theory Wars of the 1980s, I am intrigued by scala cats and am wondering how some practical programming might be expressed using cats.
2 Likes
The only wrong part is that you do use monads, whether you recognize them or not. They are just here. The same with logic, for instance. Or covid viruses.
4 Likes
Just to expand on that: List is a monad. Option is a monad. Future is a monad, etc. Every for (especially any nested for) is doing monadic operations.
That’s basically the heart of my point above: monads are everywhere in Scala, and it’s kind of hard not to use them. The problem isn’t monads, the problem is that people turn them into this Big Scary Mystery instead of just teaching by example.
Sure, monads are everywhere and I teach it that way in my courses. The problem comes when you abstract over monads in a typeclass and start developing general monad composition operations based on that type class. Then complexity for beginners goes through the roof. To pick an analogy: Recursion is also everywhere and we teach it that way. But when you abstract recursion in recursion schemes, complexity goes through the roof as well. Haoyi is completely correct when he says that core Scala is a language that is very approachable. It’s these add ons (which are not even in the standard library) that make it complex hard. (You can argue it’s actually not complex one you subscribe to category theory, but it’s definitely hard for beginners that do not).
7 Likes
Sure, but the real complexity is mostly at the library level. Application programmers just don’t need most of that, even if they’re working with ZIO or cats-effect – they just need to know enough to work with those libraries, not how the type math works under the hood.
Seriously, I think most of the “hard” is self-fulfilling prophecy. (Not that that’s new – we’ve been having this debate for the entire 16 years since I joined the community.)
I get folks who know nothing about Scala (and are often straight out of college) fully up and running on the FP frameworks with about four hours of “classroom” time spread over a few weeks, which in practice isn’t much longer than it takes to get productive in any new language and environment. Onboarding is always necessary to get someone to the point of being helpful.
So yes, monads and typeclasses and all that can be hard. But in my experience, that usually means that you’re teaching the wrong things, rather than focusing on what folks need to know in order to do their job.
4 Likes
Hi Haoyi, just let you know, I love your packages. They are easy to use and easy to read to learn Scala. I don’t have any extra knowledge about FP frameworks but just basic Scala (I don’t know why I need those FP frameworks). Thank you!
2 Likes
Personally I feel it is important to know how well the code is going to perform. Apart from readability and clean code, it should be obvious how to write optimized code in Scala.
I’ve been drawn to FP mainly as a solution to better handle complexity (in one’s program).
Also, overall, I’m interested in making “correct programs” as much as possible. But I recognize all of this has a cost and finding the right balance is tricky.
On one hand, the answer is “test everything” which has its limits IMO, on the other you lean on the type system as much as possible to catch mistakes (which is more difficult and requires more effort).
If someone were looking for this more straight forward approach to programming, why would they choose simple Scala vs let’s say a more popular language like Kotlin?
I can see a clear story FP-wise, but not so much with the other side of the coin.
2 Likes
Yes, batman, I agree it is important to know how the code will perform. For example, if you try to implement data composition (instead of inheritance) in Java or Kotlin, it fakes it using delegation, which can have a performance penalty when it is heavily used. I am hoping that Scala constructs an instance of an object of an intersection type by allocating a single data object. If not, I may as well go back to Java!
Scala has other advantages. So i stick with scala.
In my experience as teacher, OSS maintainer and researcher, also simple Scala benefits greatly from a stronger type system that helps me find more bugs at compile time compared to e.g. Kotlin. Also the cleaner syntax, more regular semantics and powerful standard library help me write simpler code that is more understandable to me.
I see the same thing among my students as they learn more and more Scala, esp. among those that had previous knowledge of some other popular language such as Python, C#, Java and Javascript (the most common languages in order of frequency as previous main language in pre-university studies among the group of my students that are not pure beginners) and can compare with their learning experience of that other language.
2 Likes
I love Scala, among other reasons, precisely for its versatile/hybrid nature. Coming from Java, I started using Scala OO style, then gradually moved towards the FP side (learning monads and friends didn’t come naturally to me, but I could see value in the investment from the start), and I was mostly happy with the language during every step of the journey.
Now I’m mostly using cats[-effect], but I may still divert to OO/direct/“lean” style, especially for smallish ad hoc projects, or, rarely, for submodules where it feels appropriate, and I’m not that surprised that others feel comfortable with this approach for bigger fish. I’ve been using some of @lihaoyi’s projects, as well, and haven’t encountered significant problems mixing and matching them with the cats eco system. And I’m curious to see how direct effects will fare, even though I may still stick with monads (and I’d strongly hope that there will remain full-fledged support for monadic effects style), but who knows…
So I see quite some stories beside the pure FP one:
- I don’t know much Kotlin, but from what I’ve seen of it, I’d pretty much prefer “lean” Scala as “a better Java”, never mind popularity comparisons.
- There’s a gradual path from OO/“lean” to Haskell-style FP that makes for a smooth and adaptable learning curve.
- There’s ongoing research feeding into the language that may nicely complement FP style, or be “dual use”.
I really hope Scala is going to stick to its open and open-minded nature, even if this renders the language more complex and baroque in public perception.
4 Likes
I stick with the most easy “monoids” and simple libraries like slick & scalafx .
Givens and Monads and Cats are above my level.
See also,
I’ll just use the library map and flatMap.
Scala goes with everything, red and white, fish and poultry, and of course burritos.
2 Likes
As an example, I could see how using Scala’s Option type rather than Kotlin’s nullable type feature would be beneficial in terms of catching bugs. But I suspect a programmer targeting “easy mode” would prefer the TypeScript-like approach of nullable types (it’s just one simple concept to learn).
What I meant was I can see how Scala can enable one to go “full FP” if that’s a wish. While having the possibility to still keep imperative code in certain places if that makes sens (performance or algorithms for example). However, I still fail to see the benefits of simple Scala rather than simple other language.
What I think I understand is some people like to use monads but not in the core of their programs. However, learning about monad is still necessary to understand them properly so wanting to use them everywhere comes naturally at some point (since it’s just logic).
Personally, I’m still learning and I’m more and more drawn to monadic computations. I see more benefits to them than downsides at my current knowledge.
2 Likes
If you have understood the basic methods of aVector then Option is a natural step as you can contrast it with a collection of zero or one elements and then there is not much new to grok.
I still fail to see the benefits of simple Scala rather than simple other language
In my experience, Scala without any explicit monad talk, just using basic language constructs (if, while, for, def, val, …) and the regular standard library collections’ basic methods, is easier to learn and simpler to understand, use and get right at both write-time and runtime for learners, compared to any other language I have taught to pure beginners (from young kids to adult students), also simpler than e.g. Python and Javascript.
1 Like