Semigroups and Monoids in Scala

Written version: blog.rockthejv...
Scala & Cats course: rockthejvm.com...
TH-cam videos on topics related to Cats:
Functors: • What the Functor? | Fu...
Type classes: • Why are Type Classes u...
Scala 3 Given/Using: • Given and Using Clause...
Monads intro: • A Monads Approach for ...
This is a video primarily for (comfortable) Scala programmers. That said, the concepts of Semigroups and Monoids are transferrable to other languages as well.
In this video we'll look at Semigroups and Monoids, two abstractions for functional programming derived from abstract algebra. We'll see how they would look like in Scala, and then we'll see what kind of practical problem they solve (besides adding more abstract math to programming). In the meantime, we'll also see some good practice for organizing Scala code, in the same style as the Cats library is organized.
The video is shot in Scala 3, but the concepts are equally valid for Scala 2 (and the article shows the Scala 2 implementation as well).
Follow Rock the JVM on:
LinkedIn: / rockthejvm
Twitter: / rockthejvm
Blog: rockthejvm.com...
-------------------------------------------------------------------------
Home: rockthejvm.com
-------------------------------------------------------------------------

[@abelgerli]

Scala3 will be just explosive in my opinion.
It is so expressive when defining strict typed domain models.
And the new given/using syntax is so much more natural und unmistakable useable.

[@eliasavelino6729]

I dont even code scala but your videos are interesting to watch

[@rockthejvm]

Biggest compliment today!

[@jimaaman]

Great video! Extremely informative and illuminating as always!

[@rockthejvm]

Glad it helped!

[@mompyish]

I think rockthejvm is the best source to learn scala on internet (trust me , I went through pluralsight and other paid ones)...Books ,of course is different category which requires time....When scala ll eventually eat up the programming space ,Daniel ll be a Rockstar literally. For me he already is :)

[@rockthejvm]

Thanks!!

[@michalbotor]

i can't believe that i see an an implementation of abstract algebra concepts in a programming language. it's as if it were designed by some math-loving researcher at some uni...
one clarification to your video:
the whole point of a semigroup (S, •) is the *associativity* of its operation •
(sidenote: a mapping • is called an operation if given a, b in S, a • b is also in S, i.e. when • eats two elements of S and spits out an element of S), i.e. that:
a • (b • c) = (a • b) • c for all a, b, c, in S.
this essentially allows you to drop the parenthesis in a • (b • c) and write a • b • c without it becoming ambiguous, which is a must if you want a concept of reduce of a, b, ..., z of S to be well-defined. otherwise given a, b, c of S and two reduces: r1 := a • (b • c) and r2 := (a • b) • c, you could not guarantee that r1 = r2, and the result of reduce would very much depend on the order in which the elements were being reduced.

[@rockthejvm]

Point taken - I didn't stress the "laws" of the concepts in question too much. Same with my monads videos.

[@Nebulorum]

Nice video as always. I was hoping for handling multiple monoids on the same type. For example products and summations on numeric values. How to structure your code to use them correctly. But never the less as an introduction it was very clear and helpful.

[@rockthejvm]

Glad it helped!

[@pbawa2003]

simple and well explained content with code examples for Monoids and Semigroups.

[@eugenehlushin1746]

awesome

[@mahesh_kndpl]

Amazing video.

[@thegeniusfool]

However elegant this might seem to Scala guys, the mix of hiding stuff inside object namespaces and the given and using and the various ways to do it is rather…. How can I put this gently: ugly in its “intricate flexibility. Scala 3 attempted to make type classes more streamlined but not sure it helped that much.

[@yaroslavsydorenko]

Hey, Daniel! Thanks for the great video! what diff between these definitions or their equivalent?
implicit class Syntax[T](val a: T) {
def |+|(b: T)(implicit instance: Semigroup[T]): T = instance.combine(a, b)
}
implicit class Syntax[T: Semigroup](val a: T) {
def |+|(b: T): T = combine(a, b)
}

[@rockthejvm]

Virtually none - you'll only be able to call the method in the presence of an implicit Semigroup.
The structure is different in that the implicit class with [T: Semigroup] will add _all_ the extension methods inside at once, whereas the other class will apply the extension methods in turn depending on the requirements of _each_.

[@yaroslavsydorenko]

@@rockthejvm so, I correct understand, if we use [T: Semigroup] all method of Semigroup was added to Syntax and with implicit param, we choose the only needed method(s)?

[@swapnilzade5384]

Hi, first I am big thank full to you l, because of you I started to learn scala in more detail, I always wanted to ask you questions but never get chance to interact but let me get straight to my question
1. My company uses scala and I wanted to become data scientists should I keep working on Scala or do I need to learn python also?
2. Should I need to learn scala at pro level to learn spark and other data engineering tools effectively

[@rockthejvm]

Hi, you don't need to be a Scala expert to do data engineering in Spark. Python will also help, and it's not that hard to learn.

[@sergeydev8273]

I'm in time:)

[@no_more_free_nicks]

Indeed you are.

[@seanhdr4k629]

Nice!

[@rockthejvm]

More incoming!

[@Jankoekepannekoek]

Good explanation and clear examples, however I am missing some context as to when someone would use this. Why wouldn't I just use the specialised 'add' and 'concatenate' methods for int and string? It seems to me that it's not worth to go through all this effort, unless you're writing abstract code that needs to aggregate values for multiple types.

[@rockthejvm]

That's the goal: when you want to present/prepare a general API dealing with "addable" things, which wants to support many different types at the same time. All while the actual mechanics of adding is different for each type (adding numbers, concatenating, aggregating shopping carts etc) .

[@vitalykalinichev7126]

To add to the op - how many more such "generic" operations are there besides adding that could be used across multiple types? Seems like just implementing it for each type is not that much more effort but much more readable

[@rockthejvm]

@@vitalykalinichev7126 never ask "how big can this become" or "how many types will I ever need" - these are usually famous-last-words kind of questions

[@luismiguelmejiasuarez2020]

I would like to make a point on top of Daniel's answer. Typeclasses are a pattern for achieving ad-hoc polymorphism and, as most things in life, they are not good or bad (and even less, they are not better or worse) in general. Typeclasses come with a downside of a lot of boilerplate (especially in Scala 2, thankfully Scala 3 improved that) and additional cognitive load since it is a new pattern to learn and as of today (this will probably change in the future) not many languages support it.
However, they provide a lot of advantages that make them very useful in certain situations.
First, they are extremely reusable. For example, you propose we add multiple reduceFoo methods one can argue that at the end there will be the same amount of code in both ways either you repeat the reduce function or your repeat the definition of a combination function. However, the typeclass approach allows us to repeat only the essential (in this case just the combination) allows us to reuse the other things (in this case the reduce). This point became more clear if we recognize that the reduce function has a problem, it will fail for empty collections, so it would be better to use foldLeft and use a Monoid instead which provide the empty element that will be returned in the case of an empty collection, now if we want to provide both reduce and fold for all types without using a typeclass we would need to repeat ourselves even more. Lets make this even more clear, Daniel's example takes a List but we can reduce or fold multiple things, not just lists. So if we make a typeclass that represents the ability to fold something (which exists in cats) then we can create an even more generic method that will take a F[A] and return an A as long as F is foldable and A is combinable (has a Monoid).
Second, we as providers of the API do not have to worry about all the possible types. For example, what happens if a downstream user wants to reduce a list of durations, where duration is a datatype provided by another third-party library. In that case, our user just need to provide the Monoid of that type and he / she can use our API without needing to patch our code.
I once wrote about different forms of Polymorphism in Scala and their trade-offs here: gist.github.com/BalmungSan/c19557030181c0dc36533f3de7d7abf4

[@mourikogoro9709]

@@luismiguelmejiasuarez2020 You explanation is nicely complement the video.

[@igboman2860]

Scala is the mother of all complexity