DEV Community: Sakib Hadžiavdić

You already know Monad(ic) stuff

Sakib Hadžiavdić — Tue, 17 May 2022 23:18:53 +0000

If you wonder what:

flatMap
Monads
Promise, Future, Rx, IO
do, for, async/await

have in common, then you are in a good place.

First we'll see how and why Monad came into Haskell (a purely functional language).

Then we will see a nicer syntax for writing functions that operate on monads.

And lastly I will show you some similarities between Monad and async/await.

Haskell

A few relevant things about Haskell:

it is a lazy language
it wants to separate pure functions from impure functions (actions)

Laziness

By "lazy" we mean non-strict evaluation.

In Java for example, when you call a function myFun(a, b), the order of evaluation is strict and consistent:

arguments are evaluated from left to right, one after another
function is evaluated

But in Haskell that's not the case. Arguments are not evaluated until needed.

So if the parameter a is not used in the body of myFun it will not be evaluated at all.

This is fine+desirable+performant when your functions are pure (not doing anything),
but it is a big issue when they do side effects: write to a file/db etc.

For example, if you want these actions to be executed:

f1: write to a file
f2: read from that file you need to make sure that f1 always gets evaluated before f2!!

In Haskell you are never sure because eval order is unspecified..

The next Haskell will be strict.

Simon Peyton Jones

Pure functions

Pure functions are like mathematical functions, they do calculations, and only return new values (no mutable variables).

They are only considering "insides" of a program, its own memory.

Impure functions

Impure functions go beyond our program, they "go outside", play and get dirty.

They read/write to a file/console/database etc.

So, Haskell wants you not to get dirty, and play as much as you can inside (stay safe).

How does it know which functions are "impure"?

Usually by marking them with IO wrapper type (which is "a monad").

Main function

"Normal" programming languages have a main function, which usually looks something like this:

static void main(String[] args) {
}

but in Haskell you have this:

main :: IO ()
main = ...

Haskell marks the main as an IO action, so by definition it is impure.

History and pre-history

Before monads were introduced, main function looked like this: main :: [Response] -> [Request].

Example taken from SO:

main :: [Response] -> [Request]
main responses =
  [
    AppendChan "stdout" "Please enter a Number\n",
    ReadChan "stdin",
    AppendChan "stdout" . show $ enteredNumber * 2
  ]
  where (Str input) = responses !! 1
        firstLine = head . lines $ input
        enteredNumber = read firstLine

In a nutshell, you would have to write all of the impure stuff that your whole program will do as a return value.

That is represented as a list of requests: [Request].

Return values from those IO actions are delivered in the [Response] list, that you would use inside the program logic.

The number of responses is the same as the number of requests you gave.

So you have to keep in mind the indices and bounds of responses, which is a bummer.
What if you add one request in the middle? You'd have to change all indices after it...

Which request belongs to which response? That's really hard to see.

We can already see that this way of writing a program is very cumbersome, unreadable, and limited.

Notice also that the approach above works only because Haskell is lazy!

Monads

Back to IO t. The IO t is an action that will do some side effects before returning a value of type t.

This can be anything: writing to disk, sending HTTP requests etc.

We have these impure functions in Haskell:

getChar :: IO Char
putChar :: Char -> IO ()

We already have some special functions that operate on these values inside the IO.

For example, we have fmap :: Functor f => (a -> b) -> f a -> f b which transformes the value inside any Functor f.

But what about chaining, sequencing actions one after another?

How can we ensure that getChar executes strictly before putChar?

Monads to the rescue! Its core function is called bind (flatMap in other languages):

(>>=) :: IO a -> (a -> IO b) -> IO b

It:

takes an IO a action
takes a function that takes a (from the IO a argument)
returns a new IO b

So there we have it, Monad in all its glory! :)

Let's see our solution:

echo = getChar >>= putChar

-- or more verbosely
echo = getChar >>= (\c -> putChar c)

-- or even more verbosely
echo = (>>=) getChar (\c -> putChar c)

In Scala you'd write val echo = getChar.flatMap(putChar).

This is the main reason why Monads were introduced in Haskell.

In short, Haskell is the world’s finest imperative programming language.

Simon Peyton Jones

Syntax sugar for Monads

Haskell and some other languages have built in syntax support for Monads.

Haskell has "do notation" and Scala has "for comprehensions"
It makes them more readable by flipping sides:

echo = do
    c <- getChar
    putChar c

Scala:

val echo = for {
    c <- getChar
    _ <- putChar(c)
} yield ()

The <- symbol gets translated into >>= by Haskell's compiler.
In case of Scala, it gets turned into a flatMap.

It turnes out they are useful not only in the IO context, but for other types too.

Whenever you have unwanted Wrapper[Wrapper[T]] wrappers, you need to "flatMap that shit" => Monads.

If you have List[List[String]] you probably needed a flatMap instead of map.

If you have Option[Option[String]] => same thing.

You can imagine doing the same with List[T], where c would be just one element of the list.

Async / Await

After some time it came to my mind that we are doing a similar thing in JS/C#/Kotlin with await.

It is almost the same thing, we are "pulling a value from a Promise/Task":

async function fetchUserMovies() {
  const user = await fetch('/user');
  const movies = await fetch(`/user/${user.id}/movies`);
  console.log(movies);
  return movies;
}

Before this we used to write "normal functions", callbacks:

function fetchUserMovies() {
    fetch('/user').then(user => {
        fetch(`/user/${user.id}/movies`).then(movies => {
            console.log(movies);
            return movies;
        });
    });
}

Seems like then corresponds to flatMap, and await corresponds to <- in do syntax.

Some noticable differences:

do/for is general, while await is specific just for Promise
do/for in statically typed languages is checked for proper types, while in JS you're on your own

My opinions

To me, it feels very awkward to program in a lazy programming language.

It is hard to reason about and you have to use monads for doing even the simplest IO operations.

Seems like it introduces more problems than it gives us benefits.

So, in my opinion, use Monads/Rx/whatever only when you have to!

The simpler the program - the better.

For example, in Java you can use threads and concurrent datastructures.
Web servers like Tomcat, Jetty etc. are working just fine with a thread-per-request model.

But in JS you don't have that liberty, you need to use Promises.

That's because JS doesn't have "normal threads", is uses an event-loop so you have to program asynchronous code.

I hope this gave you a better insight into scary Monads and the FP way of handling IO.

Additional resources

Tackling the Awkward Squad by Simon Peyton Jones
Essential Effects by Adam Rosien
State of Loom by Ron Pressler (comparing RX vs threads)
Future vs IO by Diogo Castro
The Observable disguised as an IO Monad by Luis Atencio

FlowRun - executable flowcharts for the web

Sakib Hadžiavdić — Mon, 11 Apr 2022 00:23:23 +0000

Wow, it's been 5 years since my last post here.. :o
I have something really exciting to share with you people!

FlowRun is my latest greatest project.
It is a PWA web app for designing and running flowcharts in your browser.
Its main alternative is Flowgorithm, which supports only Windows unfortunately.
FlowRun even works offline to some extent. It is a PWA so it can be "installed" on phone/desktop. Since it is web based it is easier to share programs and integrate them in other apps like Jira, Confluence and similar.

Snappy editor

A big advantage of FlowRun is its better UX of the editor: no popup windows, no doubleclicking nodes etc.
Everything is right there, usually one click away.
It has some features that Flowgorithm does not, like reporting syntax errors as you type.

Expressions

The expressions and execution is mostly the same as in Java.
It will be easy for beginners to switch to most real programming languages.

Code generator

Code generator works for 10 languages, although there are probably still some bugs left to fix.

When you click a statement(node in diagram) it gets highlighted in the code generator! Very handy when you are learning a new programming language.

Execution

Runtime is also neat, you can start and stop the program whenever you want.

When you get an error it will highlight the relevant node in the editor!

When a program pauses for taking input from user, you can see the current state/values of variables.

Layout

You can turn off some panels in the settings popup.

E.g. if you only want to show the main function you can hide the functions chooser. This way you can focus viewer's attention on relevant details.

Fun facts

FlowRun editor/interpreter is open source: https://github.com/sacode387/FlowRun

It is written in ScalaJS, which compiles to JavaScript.
Why? Because Scala is really good for writing compilers.

Next, it uses Graphviz via d3-graphviz library,
which uses WebAssembly under the hood.
You can copy the DOT source for each function that is displayed,
and generate an SVG/PDF/JPG or any other format that Graphviz supports.

Conclusion

Hope that this tool will help more people to get into programming.

If you have any feedback, suggestions, please let me know in the comments! :)

Render static site from Scala code

Sakib Hadžiavdić — Thu, 17 Aug 2017 14:18:46 +0000

Have you ever thought:

If I just had a variable in my ugly HTML...
So I wouldn't have to repeat all those Bootstrap classes and could change them at one place...

Sbt-hepek to the rescue

So, after some thinking, I decided to write my first sbt plugin just for that (Sbt is a Scala build tool, like Maven or Gradle in Java ecosystem).

Note: This is not a standard template-based, special-language static site generator like Jekyll and others. It is a completely different approach, namely, we use Scala objects to represent pages.
We can use some of Scala's features to our advantage:

Scala has singleton object as a built-in feature. Every object that extends Renderable trait will be rendered to a file. You can specify a default extension etc.
Also, Scala/Java packages can be used to represent file system structure! For example, if an object is in a package mysite.posts it could be rendered to a "mysite/posts" folder! Cool, right? :)

The meat of your page could look like this:


object HelloWorld extends JavaTemplate {

  override def pageTitle = "Hello world!"

  val introSectionContent =
    div(
      p("Java "Hello World!" example:"),
      javaSnippet("""         
            class HelloWorldApp {
                public static void main(String[] args) {       
                    System.out.println("Hello!");      
                }
            }
      """)
    )

  val introSection = Section("Hello world!", introSectionContent)
  override def sections = Seq(introSection)
}

Ideas

Since we use a full-featured programming language, we can do many things that are not possible (or not as nice) with custom-made template languages like Markdown. These are some ideas that are already implemented.

Templates

This one is obvious, to represent a template you can use traits. Then you make an object that extends it and implement(override) only the methods that are abstract. Scala's trait methods can have default implementation so we can exploit that also.

Relative paths

Another thing I thought about was error-prone relative paths in HTML, like ../js/something.js. We can make a method def relTo(other: RelativePath): String that will "calculate" it for us. Then a relative link looks like Index.relTo(MyOtherPage), or from Index object itself this.relTo(MyOtherPage). Very intuitive IMHO.

Sections

This one is "stolen" from Li Haoyi's Scalatex. Idea is very simple, structure your content inside sections so you can render them like chapters in a book. Also, you can make a nice Table Of Contents! :)

Example site

For a full-blown example, please take a look at my repo alive @ blog.sake.ba

It has a core project where the templates are (if I decide to make another site, I could reuse it), and sake-ba-blog where the content is.

Conclusion

IMHO, this is a very powerful approach for static sites and all kinds of static stuff, like XML or JSON. Since there is no parsing we can incrementally render files by examining class dependencies. E.g. if we change a template we want all Renderables to be rendered again, but if we change just the content of a page only that page should be rendered. See hepek-core for implementation details.

This approach can be implemented in other languages that have singleton objects as first-class sitizens, like Kotlin and others.
Opinions, suggestions are welcome! :)

Hi, I'm Sakib Hadžiavdić

Sakib Hadžiavdić — Mon, 10 Apr 2017 13:33:54 +0000

{
  "hello": "world!",
  "startedCodingYear": 2011,
  "spaces": true,
  "location": "Sarajevo, Bosnia",
  "favoriteLanguages": [ "Scala", "Java", "!JS"],
  "learning": [ "FP", "OOP", "web" ]
}