Algebraic Data Types (ADT) in Scala | Rock the JVM

This video requires only basic experience with #Scala, although you can transfer the ideas in this video to other languages as well.

In this video we'll explore Algebraic Data Types (or ADTs). We'll look at what kind of problem they solve (data modeling), what kind of ADTs we can have and how they look like, and give some practical advantages of structuring your data as ADTs such that your Scala code is composable, maintainable and easily testable.

Follow Rock the JVM on:

-------------------------------------------------------------------------
-------------------------------------------------------------------------

[CoreyMinter]

The illegal state not represented is a huge aspect that people need to appreciate. I see a lot of "stringly typed" programming. It seems to be very common in Python and with beginner programmers. For example as map keys or Python dict keys). With ADTs a huge class of runtime errors are not possible.

[ValinorFP]

Wonderful video, as always. Thank you, Daniel and long live Scala!

[igf]

nicely crafted demonstration.
Very helpful to promote use of ADTs in Scala

[Yupppi]

Rock the JVM? That's the Marshall head from the 2010's, somewhat popular. Worth rocking.

[ibrahimkoz]

Always-valid domain model and avoiding primitive obsession are directly relevant to this concept.

[ZoYaBoBo]

Thank you for explaining ADT, you are awesome )

[miloventimiglia]

Once more a brilliant video! Keep up the good work!

[Lumintorious]

I love the explanation, I understood Product and Sum for the first time so thank you for that.

My brain is wired towards extensibility so I even though I understand the purpose of ADTs for types that are universally finite (True and False / Up, Down, Left and Right), it's hard for me to understand why you would not use an extensible pattern for the weather type.

Weather can be LOTS of things that can cause a whole array of feelings: Tornado, Sandstorm, Blizzard, Foggy etc. and maybe you just want to provide the functionality for these structures/objects, but let client code provide their types.

Let's say we have an application like the one you provided for weather requests/responses, but we want to make it open to extension, closed to change (open for external addons/plugins), how would you implement this system to let client code provide their own VolcanicThunderStorm (silly example I know) weather type with it's own feeling?

I feel like Scala is about the best of both worlds of FP + OOP and I want to understand the pros and cons of both. Thanks in advance.

[juanjdlt]

great Videos! thanks a lot. 
an observation. the function naiveFeeling() shouldn't be receiving the NaiveWeather type alias as the argument type, instead of String?
greetings

[matteozampieri]

Just bought access to your Advanced Scala course on Udemy! I am also eyeing the Spark Streaming 3.0 for my job :p

[wojciechgradzki]

Would be good if we have ADTs part 2 with smart constructors etc

[utubebroadcastme]

is this scala 3 ? why not try the new syntax ?