Introduction
Have you ever been to a scala conf and told yourself "I have no idea what this guy talks about?" did you look nervously around and see all people smiling saying "yeah that's obvious " only to get you even more nervous? . If so this post is for you, otherwise just skip it, you already know fp in scala ;)
This post is optimistic, although I'm going to say functional programming in scala is not easy, our target is to understand it, so bare with me. Let's face the truth functional programmin in scala is difficult if is difficult if you are just another working class programmer coming mainly from java background. If you came from haskell background then hell it's easy. If you come from heavy math background then hell yes it's easy. But if you are a standard working class java backend engineer with previous OOP design background then hell yeah it's difficult.
Scala and Design Patterns
An interesting point of view on scala, is looking at it's set of features as design patterns. This is exactly what Ivan Nikolov says in Scala Design Patterns . He actually shows how the hybrid nature of the scala programming language also makes some of the traditional object-oriented design patterns obsolete, or possible, using other cleaner techniques in his great book. While I fully agree with him, I recognize that it's going to take lot of time going over all the standard design patterns and not only the standard ones but also many of th enon written patterns, best practices, and seeing how the match in the scala programming language.
Scala Design Patterns
Terminology
Let's start with the terminology, monad, semigroup, functor, typeclass, higher order functions, higher order types, partially applied functions, partial functions, are you still with us? If you already know the above concepts then this post is not for you but if you don't then heck yeah, but I have no chance of going through them in a single post, so stay tuned for the next post.
Example, is it simple
Question, is the below code easy?
  object Request {
    def pure[A](a: A): Free[Requestable, A] =
      Free.liftFC(Pure(a) : Request[A])

    def fetch[A](service: Service[A]): Free[Requestable, A] =
      Free.liftFC(Fetch(service) : Request[A])
  }
Not for me, what are all those "Free", "lift", "pure", what are the generics doing there? I can find thousands of examples like this, just search google for the cool FP terminology, this is our target to decompose this structure, to clear out the fog.
Haskell
I think if you want to learn scala you first need to learn haskell or something else and only then get to scala. It looks like its very difficult to first get to these concepts by scala. And yes when I need to learn a concept in scala guess what I first learn it in haskell and only then get to scala. if haskell would only have all java libraries and run on jvm...
FP is very important
But FP is very important, concurrency, better code, big data, parallel computing, better testing. I mean FP is the thing for a programmer who want's to write clean code with a clean pure core and all the IO surrounding it, it's the dream of clean code, so we are going to make that effort.
The good thing about FB
The good thing about FP is what makes all the problem and noise. With FP you use pure functions, this I assume we all know what it means. The problem is that real world applications are not pure, they have side effects. And this is where much of the complexity comes into play, this is the challenge, in addition you don't mutate things, so you start using recursion :)
The benefits of imperative programmers
Before i'm getting assassinated by functional programmers I want to tell you this, there are good things about imperative programming. If you have some basic sanity of clean code practices and you write well organized and clean code with imperative programming, (small functions, mutation where needed but not always), you use for loops instead of map/flatMap twin brothers. Then you know what? you use the java util concurrency building blocks and non blocking io also with multithreading, you can write excellent applications which have high performance utilization, I know this from first hand, I wrote many such apps some with very high scale demand, and i have to say that for other programmers without majour knowledge in FP those imperative programs were much easier to understand than their FP mirror brothers and sisters programs. So imperative is also good. But we are here to get to FP not to imperative. And this is the route we are going to take.
Declarative vs Imperative
So the first step is to understand what declarative code means.
I like jenkov article "The illusion of declarative code". He presents the below imperative code:
function capitalWithInterest(capital, interest, periods) {
    var result = capital;
    for(var i = 0; i < periods; i++) {
        result = result * (1 + interest);
    }
    return result;
}
Now he asks what is the declarative version of that code? and he answers:
var result = capitalWithInterest(100, 0.1, 5);
Here - it's declarative we didn't say imperatively how we want to calculate capital with interest we have just told the computer that we want it to calculate for us the capital with interest.
Declarative code with scala
So in scala the most common example of declarative code is by using "map" and friends instead of for loops, for loops are the explicit imperative way to tell the computer how to do the loop and map and friends are declarative you just tell the computer go over the items on this list and subtract 2 from each
val listOfNumbers = List(1,2,3)
listOfNumbers.map(_ - 2).foreach(println) 
So in this case instead of imperatively going through the list and printing each we tell odersky, hey please for each item in the list (map) please subtract two and for each item print it (after you subtracted 2 from it)
Functional Programming and Immutability
Because in functional programming we would rather have pure functions, then, there is a consequence to that the consequence, is that we use immutability more nad more, as much as we can in favour of mutable data structures. In the great book Scala Design Patterns by Ivan Nikolov, the author says, quote: "Immutability is an important principle in Scala and it should be preferred. The builder design pattern with case classes uses immutable fields and this is considered a good practice.". And yes case classes which inherit from sealed traits are not only a great way to model your data, they help extensively with using immutable data structures instead of mutable.
Summary
We have just touched the tip of the iceberg here, but don't worry before global warming takes it's place and metls the iceberg we are going to hit upon all the concepts you wanted to know about scala but had nightmares about free monad, managing state, functors and friends.
14

View comments

Chapter X: Getting Started with AWS Step Functions

We've successfully navigated the world of serverless compute with AWS Lambda. You've learned how to create event-driven functions and unlock the power of code without managing servers. Now, let's elevate our serverless capabilities by delving into AWS Step Functions, a service that allows you to coordinate multiple AWS services into serverless workflows so you can build and run sophisticated applications.

Think of Step Functions as the conductor of your serverless orchestra. While Lambda functions are the individual instruments performing specific tasks, Step Functions defines the order in which these instruments play, ensuring a harmonious and well-structured performance.

Introduction

Tools that enhance productivity and streamline workflows are in high demand. Among these, AI-powered coding assistants have taken center stage, promising to act as virtual pair programmers. While GitHub Copilot and JetBrains AI Assistant have become household names in this space, a lesser-known but intriguing contender, Aider, is making waves.

Introduction

The line between batch and streaming processing is blurring. Apache Iceberg, an open table format, is at the forefront of this shift, promising to unify these paradigms in a single, scalable framework. But how does it achieve this? Can it replace traditional streaming systems like Kafka? And how do tools like Flink and Spark Streaming leverage Iceberg for streaming workloads? Let’s dive in.

502 Bad Gateway Errors with Reflex Python Behind NGINX

Overview

You're experiencing a 502 Bad Gateway error every few hours with your Reflex Python application behind NGINX, which gets resolved by restarting the app but recurs later. This suggests the problem lies with the Reflex app or its connection to NGINX.

Likely Cause

It seems likely that the Reflex Python application is becoming unresponsive after a few hours, possibly due to memory leaks, resource exhaustion, or unhandled exceptions.

Overview

RDS with PostgreSQL is cost-effective for general-purpose databases, while Redshift seems more economical for large-scale data analytics due to lower storage costs.Matching use cases are using RDS for transactional applications and Redshift for analytical queries on big datasets, with costs varying by workload.An unexpected detail is that Redshift's compute costs per hour can be higher, but its storage is significantly cheaper, affecting total cost based on data size.Pricing Comparison

Web Scraping

- https://www.scrapingdog.com/

Is common for ClickHouse to use S3 for data storage. And while it's not as common (yet) for ClickHouse to directly integrate with Iceberg as a table format, the integration is evolving and becoming increasingly relevant in modern data architectures.

Let's break down each part:

1. ClickHouse and S3 (Common and Yes):

Yes, it's very common for ClickHouse to interact with and utilize S3. In cloud deployments, especially on AWS (where S3 is native), it's a highly prevalent pattern.

Unraveling Flux: Why Your React Frontend Needs a Data Flow Blueprint

Hey Back-End Engineers, let's talk about frontends. Specifically, React frontends, which you've likely heard a lot about. You might be thinking, "Frontend? Isn't that just HTML, CSS, and a bit of JavaScript glue? We handle the real data logic on the server."  Well, in today's web applications, that "bit of JavaScript glue" is doing a lot more, and that's where things like Flux come in.

Imagine your backend system.

In today's data-driven world, operational metrics are the lifeblood of any organization running complex systems. They provide crucial insights into performance, availability, and user behavior. However, as systems become more intricate and user bases grow, we often encounter the daunting challenge of high cardinality metrics. Imagine tracking metrics not just by server, but by individual container, user session, product SKU, or geographical location.

Document Processing Pipelines vs. Kubernetes Containers: A Comparative Analysis with Orchestration Insights

When designing a document processing system, architects and engineers must choose between managed document processing pipelines (e.g., AWS Glue, Google Dataflow) and Kubernetes (k8s)-based containerized solutions.
Popular Posts
Popular Posts
Contributors
Contributors
Archive
Labels
Loading
Dynamic Views theme. Powered by Blogger. Report Abuse.