AoC puzzles expose me to many sorts of list and graph-type data structure puzzles, with some accompanying search (usually DFS) / update algorithms. As someone who comes from a non-CompSci background with very weak math acumen (one of the reasons I did not pursue a masters in Physics), all of this hurts but it's nevertheless so much fun to think of an algorithm, express it in Haskell syntax (or try to) and then run the code to see it output what has so far ended up being the right answers to the AoC puzzles.

Some notes arose out of this.

"Thinking in types" does not go brrrr

It's all fun and games to think in types. In fact, it makes sense when I am building something. But boy does it suck to introduce sum types and such when doing these puzzles. I started the first couple of days with a type-based approach but by Day 6, I turned away from it. It's useful when I can afford to spend a whole lot of time building types and functions for data transformation but not when I just want to solve a damn puzzle that just involves a whole bunch of Chars.

My algorithms lack mathematical aesthetics

One of the wonderful after-effects of me discovering the world of FP is that I could model something as data-transformations. A lot of things can be modelled like that and the triumvirate of immutability, applicative/monadic laws, and strong typing make it a delightful experience. AoC puzzles literally are about data transformations. Great.

But when I compare my solutions to those of someone like Abhinav, good lord, my programs feel so imperative. Almost every puzzle lends itself to some really aesthetic mathematical jugglery, sometimes simple, sometimes complex. I guess having a good mathematical bent helps in discovering or inventing these aesthetic-looking solutions (yes, aesthetics is subjective, I know). Haskell is well-suited to expressing these mathematical things almost verbatim. Too bad I have not the level of acumen or knowledge.

REPLing is fun till that large computation hits you

REPL-based development is a gift. I am sad that it's not the norm in many environments (like frontend, except when it's Clojurescript). While not as exceptional as Clojure, Haskell's REPL is great and it accelerates development.

Except, during some of these AoC puzzles, the computation does take a while and it's a long pensive wait because sometimes I can't tell if the code went into an infinite recursion or it's just taking a long time. (Long times here mean ~120s, which doesn't feel all that long on paper but when other puzzles solve in under a second or two, 120 is huuuuuuge).

I compiled the program to test some other mechanism I was building into my code unrelated to some long-running puzzles, and then I ran the binary, running the puzzle inadvertently. Suddenly, the ~120s function ran in a fraction of that time! Crap. I could've saved a lot of anxiety by just building the binary (which takes <5s) and running the solutions!

Resisting the urge to be (point-)free

Several times in a coding session, there's this opportunity to reduce an expression, often to the extent of point-free. It is tempting. But I imagine myself reading this code a few weeks down the line and I can vividly picture a completely confused brain that struggles to comprehend what it wrote. That keeps the terseness-shenanigans at bay. However, it would be cool to have a branch where the code is as terse as can be.

*

Anyway, it is almost always a delight to be able to solve some puzzles by writing some code. Amidst some stressful work caretaking for a recovering parent from their surgery, I look forward to these moments when I get to think about these AoC puzzles.

My first attempts to do this was to upload my locally-built binary and see if that works in a GH action running on a macos-latest machine — it did not. I spent a tiny bit of time before my day-job took precedence and because I couldn't get it to work, I decided to park there and come back later.

Coming back later, I decided to make the rdigest repo build its binaries on ubuntu-latest and release the artefact in the repo. This was exceedingly simple (probably needed a couple of iterations to get the right configuration options for GHCup, Cabal, GHC, tagging etc.). This worked nice, and all that was left to do was to consume the release in my rdigest-data repo's cron action.

With a few iterations, I got all of it tied up. The cron ran once every day and updated the digest for a particular day. With GH Pages setup on that repo, I was able to just hit the URL and see a list of all digests and read each digest at leisure.

But this unearthed a new problem: since I ran the digest update just once, and the process would only update for "today" (whatever today was at the time of running the binary), some posts could "slip" the digest depending on the timing. I haven't spent much time thinking about the optimal approach to fixing this but in the meantime, it made sense to just update all digest-days once I have refreshed (and saved posts from) all feeds in my list. Ugly, nuclear solution but it ensures all my digest files are up-to-date.

Life is getting a lot in the way in recent times so there's been a pause in activity but I am itching to refine the rdigest codebase to elegantly separate out the functional and imperative bits. And also revisit what interesting things the project can spawn into and make it more useful than just producing digests.

runApp :: App a -> IO ()
runApp app = do
  let template = $(embedFile "./template.html")
  rdigestPath <- lookupEnv "RDIGEST_FOLDER"
  case rdigestPath of
    Nothing -> showAppError $ GeneralError "It looks like you have not set the RDIGEST_FOLDER env. `export RDIGEST_FOLDER=<full-path-where-rdigest-should-save-data>"
    Just rdPath -> do
      pool <- newPool (defaultPoolConfig (open (getDBFile rdPath)) close 60.0 10)
      let config = Config {connPool = pool, template = BS.unpack template, rdigestPath = rdPath}
      res <- (try :: IO a -> IO (Either AppError a)) $ app config
      destroyAllResources pool
      either showAppError (const $ return ()) res

• In this code, app returns an IO a which is handled as a potentially-throwing action. However, the extraction of rdPath happens outside the try. Better code would follow the happy-path pattern, with errors handled inherently in a global try block. The runApp function is intended to be that global try block for all App a actions, but the environment variable extraction happens outside this boundary.

• At some point in this Haskell journey, the project began feeling like routine code similar to Typescript. This prompted reflection on the benefits derived from using Haskell beyond learning the language and code architecture. Notable advantages include:

  • Easier writing and reading of async/effectful actions due to bind abstractions (sugared as do blocks) with upper-level error handling
  • Clean implementation of applicative parsing, which would be challenging in non-functional programming languages
  • Convenient data types and constructors that simplify logic construction

• Hlint often recommended ways to make code more concise through point-free style or using operators. For example, this code:

parseURL :: String -> Maybe URL
parseURL url = case parseURI url of
  Just uri -> (if uriScheme uri `elem` ["http:", "https:"] then Just url else Nothing)
  Nothing -> Nothing

Can be written as:

parseURL :: String -> Maybe URL
parseURL url = parseURI url >>= \uri -> if uriScheme uri `elem` ["http:", "https:"] then Just url else Nothing

• Sometimes explicit destructuring and imperative-style expressions were preferred for better understanding of the logic.

• This was largely a matter of familiarity. With more exposure to situations requiring unwrapping double monadic structures, the use and understanding of >>= became more natural:

getDomain :: Maybe String -> String
getDomain url =
  let maybeURI = url >>= parseURI >>= uriAuthority
   in maybe "" uriRegName maybeURI

• This experience recalled the exchange on terseness and readability.

• I think sometimes I am able to think very cleanly thanks to the type-system and the functional-style of programming but there's certainly the feeling that I am not completely tapping into that potential. Being able to express the logic in the code as a beautiful equation is still elusive.

parseDate datetime = fmap utctDay $ firstJust $ map tryParse [fmt1, fmt2, fmt3, fmt4, fmt5, fmt6]
   where
     fmt1 = "%Y-%m-%dT%H:%M:%S%z"
     fmt2 = "%a, %d %b %Y %H:%M:%S %z"
     fmt3 = "%a, %d %b %Y %H:%M:%S %Z"
     fmt4 = "%Y-%m-%dT%H:%M:%S%Z"
     fmt5 = "%Y-%m-%dT%H:%M:%S%Q%z"
     fmt6 = "%Y-%m-%dT%H:%M:%S%Q%Z"
     ...rest of the code

• Renamed the project from rss-digest to rdigest.

• Progress on Haskell-specific learning has slowed. Excitement is waning due to lack of challenges outside the comfort zone. Considering adding server capabilities to the tool, allowing it to serve the digest. This would involve UI updates to accept date ranges and implementing server functionality.

> rss-digest add <url> # this adds an XML URL to the database, correctly showing an error if the URL is already added or it's an invalid URL.
> rss-digest refresh # this fetches all feed links from all the RSS feeds in the database, and then updates the feed_items table.
> rss-digest purge # nukes the whole thing

• I wanted to check the size of the binary and it was a whopping 64MB. Ignorant me was surprised as heck. I asked ChatGPT about it and it said it was because the binary was packing everything to be self-sufficient. One of the options it gave was to use dynamic linking instead of static linking — I had concerns about this because how would that work if one were to distribute the binary? The reduction was anyway not all that great. There were other options it suggested like "no profiling", turning off debug mode, using some "O2" mode of optimization etc... nothing really worked.
• One thing I missed in the ChatGPT list of recommendations was to use the strip command on the binary. Instead, I went to Stack Overflow and Google... and one of the suggestions there was strip too. So I did that and the binary came down to 41MB which is still humongous (for comparison, GitHub's CLI tool gh v2.49 is ~48MB). strip removes all the symbols from the binary. I did a test run of the binary after doing the strip and it was working OK. (update: if I compile the binary with dynamic linking, and then do a strip, the binary size is about 200kb)
• I'm quite happy about the way the project has shaped up so far. Might do a recap of what I learned, patterns that seem to emerge etc at some point.

Update:

• I did some more work as I was bored and couldn't stop being obsessed with the project for a bit.
• I wrote a Makefile because I was frequently running cabal build ... and cabal install. This made the process quicker.
• I found a problem where, when I added more constructors to my Command data type, the compiler didn't warn about missing pattern matches in the main function where I was handling the command. It turns out I had to enable some flags (specifically -Wincomplete-patterns). I ended up using -Wall and fixing a bunch of lint warnings like unused declarations and imports and adding type annotations where I hadn't written them out explicitly. This had zero impact on the built binary size, though.
• I added a couple of commands to remove a feed and list all existing feeds. The remove feed command made me realize that I need to set up a foreign key relationship between the feeds_table and feeds — so that when I remove a feed, I also remove all the posts that came from that feed URL. I've noted this for later implementation.

...
res <- try $ withResource connPool handleSomething :: IO (...)
...
where
  handleSomething :: IO ... -- this is where I play with and finalze the type till compiler stops complaining
  handleSomething = undefined

• And then workout the handleSomething function by unwrapping/wrapping stuff.
• With one of the core prerequisites done, I am now going to do some work on finding out what I want the outputs to look like and how the CLI should behave. I am partly leaning towards being able to run a single command that produces a simple HTML file which I can just serve or see directly to get my "daily digest". But how would I mark the reads as reads if it's a static html file?
• Update: at the end of the day, I spent a little more time on the codebase. I was particularly looking for ways to extract some patterns out and minimize code. Somewhere, I feel like there are a bunch of utilities from the standard library that I could be using to wrap, unwrap, map over the monadic datatypes involved in the app at this point, but I couldn't really get a sense of what those would be. (The hlint does sometimes suggest interesting alternative options that make the code concise, without losing the readability mostly). I did realize though that I have a bunch of trys in the app and then I always have to handle the SomeException and convert it into my AppError... so I wrote a custom try' that I could use all over the place and never worry about having to convert SomeException to AppError again.

try' :: (String -> AppError) -> IO a -> IO (Either AppError a)
try' mkError action = do
  res <- (try :: IO a -> IO (Either SomeException a)) action
  pure $ case res of
    Left e -> Left . mkError $ show e
    Right a -> Right a

type App a = Config -> ExceptT AppError IO a

• So now, any function that needs the config can simply be a function that takes a Config and returns an ExceptT AppError IO a.
• I also updated the feed-item extracting part of the code so that it can, in one pass, work for both Youtube feeds and other RSS XML 2.0 spec feeds — the difference in YT feeds is that they use <link href="..." /> instead of <link>{actual_url}</link>, and they use <published> and <updated> instead of <pubDate>.. basically different specs. The way I handled this was to use the wonderful <|> (alternative) operator. My use-case has been very simple so far thankfully — I just try to extract/parse (using tagsoup) and then return a Maybe String. Combined with the <|> operator, I get what I want - if the item has <pubDate>, that's extracted and returned. But if it has <updated> instead, that will be extracted and sent. If both exist, the first will be returned.

extractData :: [Tag String] -> FeedItem
extractData tags =
  let title = getInnerText $ takeBetween "<title>" "</title>" tags
      linkFromYtFeed = extractLinkHref tags -- youtube specific
      link = case getInnerText $ takeBetween "<link>" "</link>" tags of
        "" -> Nothing
        x -> Just x
      pubDate = case getInnerText $ takeBetween "<pubDate>" "</pubDate>" tags of
        "" -> Nothing
        x -> Just x
      updatedDate = case getInnerText $ takeBetween "<updated>" "</updated>" tags of
        "" -> Nothing
        x -> Just x
      updated = pubDate <|> updatedDate
   in FeedItem {title = title, link = link <|> linkFromYtFeed, updated = fromMaybe "" updated}

• The success in extractData did not last by the time it came to working with functions that had to interface with the DB. Had a lot of trouble writing that one function processFeed :: URL -> App () which takes a URL (String), and an app config (Config) and then actually fetches the contents, then writes to the database. This was because I had a tough time unwrapping/wrapping to IO () without losing the errors.. but then, I realized I had not really thought about error/crash strategy: like, when I extract feed items and attempt to write each link to the database, should I crash at the first error or should I just log it to the console and carry on with the next item?
• I decided that it was best to log and continue to the next. Then came the question of which function should do the logging? For now, the insertFeedItem (which takes a feed item and writes to the DB) is the one that logs... but that came about after so much wrangling with these functions. At the end of the day, I went with really simplified insertFeedItem whose return type went from ExceptT ... () to IO ()... which I am not really happy about because a thrown error is not caught.
• Eventually, insertFeedItem got wrapped inside processFeed (which processes a single feed URL), which then got wrapped inside processFeeds which processes a list of URLs, simply mapping over the processFeed function.
• Overall — the good thing is that I managed to get a working function that took a URL and fed the feed items into the table. But the code is already somewhat confusing and there were times where things compiled and worked but I just couldn't get a complete understanding of what was going on in the wrapping/unwrapping — a feeling I commonly encounter when dealing with these functional programming languages.
• I spent time on finalizing the table schemas. The link is the primary key so duplicate inserts are prevented at the DB level besides being prevented at the code level.
• I am also briefly mulling if I could put all the code in a single file. I have modules around functions (like DB-related, RSS parsing related etc) but they are already coupled by sharing of types and whatnot. So I am thinking maybe for now I will put them all in a single Main.hs file and then extract out modules based on what natural grouping requirements emerge in that file.

runApp :: AppM a -> IO (Either e a)
runApp app = do
	config <- ask -- gets the global app config
	runExceptT $ (runReaderT app config)
	-- runReaderT runs the app and extracts the inner monad (ExceptT e a)
	-- runExceptT then runs the inner monad and returns an IO (Either e a)

• Problems started brewing because all my lower-level functions were of the ExceptT type. At some point, the way I was doing it, running the app returned something like IO (Either SomeException (Either SomeException ())) — i.e., I was not passing the ExceptT context correctly.
• This had disastrous effects: errors were not being bubbled up (in my mind, that was the whole point of wrapping the app in the ExceptT monad). Instead, they were wrapped in another Either monad surrounded by the IO. Horrible. I had output that looked like this:

Right (Left <some_error_message>)

• I had a long chat with ChatGPT about these things, asking it about the idea of bubbling up the errors from ExceptT without having to do runExceptT wherever I wanted the error to be bubbled up but the ideas it returned were not working or not useful — or in some cases, it was just reinventing the ExceptT or ReaderT monad transformers.
• But it did tell me how to actually unwrap the ExceptTs at lower-levels (using runExceptT of course), and then lift them in the AppM monad so that the exceptions bubble up and are caught at the top-most function — which is exactly what I want but not at the cost of having to run runExceptTs at the inner functions and then lifting them using custom lift functions.
• I had working code that did involve runExceptT and an interesting custom liftEitherAppM function:

liftEitherAppM :: Either SomeException a -> AppM a
liftEitherAppM = either throwE return . lift

• As you can imagine, I spent all this time trying to understand some higher-level mechanics of the app (i.e. abstraction) rather than just working on the actual functionality and it was too late by the time I realized what I was doing.
• One other interesting thing that I noticed was that I did not google for solutions or ideas for a long time; it was almost at the end that I realized I could also just google/SO for solutions. That didn't help though. Ended up posting my questions on the FP slack.

Update: In the morning, I had the idea of looking at opensource Haskell projects to see what patterns they use. I tried Hakyll and PostgREST: both the projects seem to be just passing config to the relevant functions, so I think I will simplify the app for now to just pass Config (the one that has connection pool so that my inner functions that deal with DB can get a connection to work with) to the functions instead of using the ReaderT monad transformer until I get some more ideas and understanding of the monad.

case args of
  ("--url" : url : _) -> ...
  _ -> ...

• I tried to initialize the project with Stack first, but it threw some weird errors. So I decided to go with a Cabal-only approach, which worked. I haven’t investigated why Stack failed. I might not do that for now, as the Cabal setup seems good enough—I was able to add packages, build the binary, test it, and also run the REPL from Cabal.
• Overall, a great day 1—just the right amount of pushing against my comfort zone.

Very briefly, the idea is to:

• "extract" the example queries from where they live (either in a markdown file in between sql codeblocks or in a configuration file) in a plugin or a mod repository and,
• run those queries using steampipe and,
• collect and log the results.

Needless to point out, this involved running some CLI commands and reading files etc. That is to say, a bunch of Node.* modules in Purescript.

At first, I wrote the thing to run sequentially. This is slow but for development and quick prototyping, this was OK. This meant I could get away with Effect monads all the way through. Most notably, Node.ChildProcess's execSync was very handy to run commands and grab the results without having to fall into callback traps.

The first draft ran painfully slowly because it was running validation checks on some dozen queries in series/sequence and that took a handful of minutes. The validation and logging worked – great – but so many minutes to check just one plugin? That won't fly. I had to parallelize it now.

parTraverse is a go-to for parallelizing traverse (and the equivalent for sequence is parSequence) but the big problem I had at this point was that all my "effect-ful" functions were in the Effect monad... and that monad has no Parallel instance. (To the uninitiated, your monad needs a Parallel instance to be able to use functions like parTraverse on it).

This meant I had to convert all those Effect monads into Aff monads.

And that's where converting execSync to Aff took me on a goose-chase.

Obviously, the first thing I tried to ChatGPT and Google was "how to convert an Effect to Aff" and the only standard library function to do this is the seemingly-complicated makeAff function. I've yet to wrap my mind around that.

The other thing to try involved FFI with EffectFnAff. This seems straightforward at first and probably is to people who have successfully intuited it, but it mandates your foreign function to be in a particular shape.

In both the makeAff and EffectFnAff cases, I was able to get the code to compile (which is a great sign that your code works in Purescript) but the query validation continued to run in sequence instead of parallel.

Turns out JS's execSync, even when converted into a promise on the JS side and then imported into an Aff on Purescript via EffectFnAff will continue to block. (That or the way I wrote it was blocking).

Finally, I stumbled on aff-promise through this post and discovered a very simple way to convert Node's exec into a Purescript Aff:

On the JS side, you have this:

import { exec } from "child_process";

export const exec_ = (cmd) => {
  return () => {
    return new Promise((res, rej) => {
      exec(cmd, { encoding: "utf-8" }, (err, stdout, stderr) => {
        if (err || stderr) {
          rej(err || stderr);
        } else {
          res(stdout);
        }
      });
    });
  };
};

which is essentially exporting a function that returns a "thunk" which returns a Promise.

And on the Purescript side, where you import this "exec_" as an FFI, you have this:

import Control.Promise (Promise, toAffE)
import Data.Either (Either)
import Effect (Effect)
import Effect.Aff (Aff, try)

foreign import exec_ :: String -> Effect (Promise String)

execAff :: String -> Aff (Either Error String)
execAff = try <<< toAffE <<< exec_

which is essentially:

• import the foreign/JS function exec_ as an Effect (Promise a) (where a = String in my case)
• convert the exec_ result into an Aff using toAffE (so, toAffE <<< exec_ :: Aff String)
• slap a try onto this to catch any errors that could be thrown in the exec_ function.

I must've spent as much time on finding a way to convert execSync into an Aff as I did writing the entire program, but c'est la vie.

I hope to move to the query extraction part – where you point the script to a folder and the program extracts all queries it finds in the markdown or config files – in the next iteration.

About two years ago, I wanted to see if Elm can be used to build a meaningful Android app.

I manage my expenses on a simple Google spreadsheet. When I'm on the move, I'd jot down the expenses as notes and then type them out on the spreadsheet once I had access to my laptop. I wanted a way to add expenses directly to my spreadsheet through my phone. The Google Sheets mobile app does not offer a great UX for this.

I ended up building a (highly-personalized) expense tracking Android app using Elm. I've been using this app ever since and has hardly needed a few updates in all this time.

Recently, I updated the "bootstrap" repo that I use to build Elm-based Android apps. (These can be used to build iOS apps as well). You can grab the source-code / clone the repo from here.

But if you're interested in setting up an Elm-based Android app project yourself, here's my notes:

1. Core dependencies
2. Bundling logic – how is the project built?

1. Core dependencies

For this project, I use CapacitorJS. This means the whole application runs inside a web-view.

Things have improved quite a bit in the web-view (and mobile browser engine) space in the recent years so building apps that run on web-views is not really a bad thing now.

For styling, I use TailwindCSS. It's simple, clean and has one of the best styling ecosystems that one can ask for.

Custom JS glue-code has to be written to make your Elm app interact with native things (via CapacitorJS) and you'd ideally write these in ES6 or later. So, the app would need a way to be "transpiled" and/or bundled. To do this, I use Parcel. Not exactly the best solution out there but it's far more than enough for a bootstrap. Eventually, I'd like to swap this out with Vite to see how things work.

2. Bundling logic – How is the project built?

If we were building an Elm app, this is broadly the workflow:

• write Elm code
• compile Elm to JS
• include the compiled JS in an index.html file and init the Elm app via Elm.Main.init()
• serve the html file and JS assets.

Building a mobile app is almost the same, except for a couple of steps:

• include Capacitor-JS related code (in Javascript) – typically, Elm and Capacitor would communicate via ports,
• and because Capacitor-related code will end up being ES6 or later, use a bundler like Parcel

The bootstrap's project structure is simple:

public
├── css
│   ├── index.css
│   └── style.css
├── index.html
└── js
    ├── elm.js
    └── index.js

Here's more info:

public
├── css
│   ├── index.css <-- all your custom CSS goes here
│   └── style.css <-- this file gets auto-generated by the `yarn build` command
├── index.html <-- main entry-point for the project. Parcel will use this file to build/bundle the project.
└── js
    ├── elm.js <-- this file is auto-generated by Elm during the `yarn build` process
    └── index.js <-- all your custom Capacitor / other JS can go in this file (and other JS files)

The build step does these things:

• it compiles Elm code to JS
• it builds a minified CSS file
• then it lets Parcel bundle the whole project into a separate directory (web)
• and finally, it lets Capacitor "sync" the project which is basically Capacitor copying over the web into the Android/iOS project folder.

3. Caveats and explorations

One of the things I realized while building the personal expense tracking app was that Elm routing doesn't work. So I had to resort to using Browser.element and using a custom Page type as part of the Model.

Elm ports can feel a little tedious to hook up with the Capacitor bridge. However, with some good abstractions, using ports can be more streamlined.

Capacitor is not the only JS-native bridge. There are also other tools like NativeScript and it could be worth exploring how that plays with an Elm project.

The other day, I stumbled on this tweet:

While the tweet does say libraries allowed, it got me curious.

What if it said no libraries allowed?

There are possibly many clever ways of solving it. As I thought about it, I realized that this could be a great exercise to implement an actual concurrent promise executer that can be used for any kind of a list!

So here I am.

First off, let's scope out what we want to do:

• run a large list of promises/async functions parallelly
• but run them in batches of X, where X = some integer
• make sure to collect all errors
• in fact, make sure to collect all values! that way, one can use this even if they want to extract all values out

To be sure, I am not aiming for brevity or cleverness here. I'm looking to build the lego building blocks (primitives) that will help us "compose" or construct the final function easily.

Breaking down the basic structure/idea of concurrency with limitations

What does it mean to run a 1000 promises, but 25 at a time?

How can be break this down into smaller steps?

• First, split the 1000 items into lists of 25 each. That is, make groups of X where X = 25.
• Then, loop through each group and run all the promises inside each group parallelly.
• While doing that, make sure you await the result of each group's promise run before running the next. That is, each group should run sequentially.
• Finally, flatten everything because we had grouped a giant list into a list of smaller lists. And return the flattened results.

We need small functions/helpers to do each of these:

• we need a groupsOf function to split a large list into a list of smaller items,
• we need a helper that can take a list of promises, run them parallelly and return the results,
• and we need a helper that can take a list of promises and run them sequentially.

Groups of X

const groupsOf =
  (number = 0) =>
  (arr = []) => {
    return arr.reduce(
      (acc, curr, idx) => {
        const step_ = acc.step.concat(curr);
        if (idx === arr.length - 1 || step_.length === number) {
          return { final: acc.final.concat([step_]), step: [] };
        }
        return { final: acc.final, step: step_ };
      },
      { final: [], step: [] }
    ).final;
  };

The groupsOf function takes a number (the max number of items in a list), an array and then chunks the array into groups of whatever number we give it.

The logic is simple: it accumulates a step list till the number of items in the step list reaches the max number allowed. Once it reaches that, it pushes the step list into the final list and resets the step list. There are some checks to ensure that the if it's the last item in the array and the step list is not "full" yet, it still makes it to the final list.

Let's test this:

const array = range(1, 11);
console.log(groupsOf(3)(array));
// [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ], [ 10 ] ]

Run promises parallelly and collect errors

const runPromisesPar = async (promiseFns = []) => {
  return await Promise.allSettled(promiseFns.map((p) => p()));
};

Here, the promiseFns is a list of functions that return a promise.

So something like async () => { return await something; }.

This distinction is critical (as we'll use it again).

A promise is a value that could resolve or reject.

A promise function (in this post) refers to a function that will return a promise when we call the function.

So in our runPromisesPar, we take a list of functions that return a promise, do a map to call each function (so we have a list of promises) and use Promise.allSettled to convert it into an async list of values.

In types, we go from Array<Promise<value>> -> Promise<Array<value>>

We use allSettled instead of all because we want to "collect" errors. all would crash and return the first error it encounters. allSettled will run every promise even if there are errors/rejections and finally return all values/errors.

Testing this:

(I made up a few helper functions to create a promise function and then a list of promise functions):

const createPromise = (val, err, timeout = 100, idx) => {
  return () =>
    new Promise((res, rej) => {
      console.log(
        `running promise #${idx} with val: ${val}, err: ${
          err ? err.toString() : null
        }, timeout: ${timeout}`
      );
      setTimeout(() => {
        if (val) {
          res(val);
        } else if (err) {
          rej(new Error(err));
        } else rej("No value or error given");
      }, timeout);
    });
};

const promises = range(1, 11).map((val) => {
  return createPromise(
    val % 5 === 0 ? null : val,
    val % 5 === 0 ? "oops" : null,
    val * 50,
    val
  );
});

> console.log(await runPromisesPar(promises))

running promise #1 with val: 1, err: null, timeout: 50
running promise #2 with val: 2, err: null, timeout: 100
running promise #3 with val: 3, err: null, timeout: 150
running promise #4 with val: 4, err: null, timeout: 200
running promise #5 with val: null, err: oops, timeout: 250
running promise #6 with val: 6, err: null, timeout: 300
running promise #7 with val: 7, err: null, timeout: 350
running promise #8 with val: 8, err: null, timeout: 400
running promise #9 with val: 9, err: null, timeout: 450
running promise #10 with val: null, err: oops, timeout: 500
[
  { status: 'fulfilled', value: 1 },
  { status: 'fulfilled', value: 2 },
  { status: 'fulfilled', value: 3 },
  { status: 'fulfilled', value: 4 },
  {
    status: 'rejected',
    reason: Error: oops
        at Timeout._onTimeout (/Users/chandrashekharv/Documents/projects/promise-concurrency/test.js:21:15)
        at listOnTimeout (node:internal/timers:559:17)
        at processTimers (node:internal/timers:502:7)
  },
  { status: 'fulfilled', value: 6 },
  { status: 'fulfilled', value: 7 },
  { status: 'fulfilled', value: 8 },
  { status: 'fulfilled', value: 9 },
  {
    status: 'rejected',
    reason: Error: oops
        at Timeout._onTimeout (/Users/chandrashekharv/Documents/projects/promise-concurrency/test.js:21:15)
        at listOnTimeout (node:internal/timers:559:17)
        at processTimers (node:internal/timers:502:7)
  }
]

Run promises sequentially

const runPromisesSeq = async (promiseFns = []) => {
  let res = [];
  for (let promise of promiseFns) {
    res.push(await promise());
  }
  return res;
};

Nothing fancy here. We use a for ... of ... loop, await every promise and then proceed to the next one, collecting results all along.

Testing this:

> console.log(await runPromisesSeq(promises))

running promise #1 with val: 1, err: null, timeout: 50
running promise #2 with val: 2, err: null, timeout: 100
running promise #3 with val: 3, err: null, timeout: 150
running promise #4 with val: 4, err: null, timeout: 200
running promise #5 with val: null, err: oops, timeout: 250
/Users/druchan/Documents/projects/promise-concurrency/test.js:21
          rej(new Error(err));
              ^

Error: oops
    at Timeout._onTimeout (/Users/druchan/Documents/projects/promise-concurrency/test.js:21:15)
    at listOnTimeout (node:internal/timers:559:17)
    at processTimers (node:internal/timers:502:7)

If there's an error in any promise, it will crash.

Why not "handle" this too?

Technically, we could but we don't have to, in our case. Our runPromisesPar returns a "safe" promise – one that will never crash. And we're only going to use the runPromisesSeq to run the groups returned from runPromisesPar.

Note: In a real-world setting, I'd probably make runPromisesSeq not crash but short-circuit and return the error as a value instead.

Combining all these together

const runPromiseConcurrent =
  (limit = 0) =>
  async (promiseFns = []) => {
    // create the groups
    const promiseGroups = groupsOf(limit)(promiseFns);

    // promiseGroups is Array<Array<() => Promise<any>>>
    // we can only pass Array<() => Promise<any>> to `runPromisesSeq`
    // so we transform promiseGroups

    const transformed = promiseGroups.map(
      (group) => () => runPromisesPar(group)
    );
    // now transformed is Array<() => Promise<Array<any>>>
    // which is equivalent to Array<() => Promise<any>>

    // finally, run it and flatten the results
    return (await runPromisesSeq(promiseGroups)).reduce(
      (acc, curr) => acc.concat(curr),
      []
    );
  };

A simplified version:

const runPromiseConcurrent =
  (limit = 0) =>
  async (promiseFns = []) => {
    const promiseGroups = groupsOf(limit)(promiseFns).map(
      (group) => async () => await runPromisesPar(group)
    );
    return (await runPromisesSeq(promiseGroups)).reduce(
      (acc, curr) => acc.concat(curr),
      []
    );
  };

Here's a gist of this all.

In the previous Elm-specific post, I covered on how to render a basic calendar. In this one, let's write an application that implements Conway's Game of Life.

Rules of the game

Apparently there are many versions of the "game" but the basic rules are:

• a "live" cell will live in the next generation if it has exactly 2 or 3 "live" neighbors
• a "live" cell will die if it has less than 2 or more than 3 "live" neighbors
• a "dead" cell will come alive if it has exactly 3 "live" neighbors
• a "dead" cell will remain dead if it has less than 3 neighbors.

The trick for us is to figure out what it means to be a "neighbor" in the programmatic sense.

What's a good data structure?

Conway's game of life is laid out as a grid containing lots of cells.

For simplicity, we'll take a square grid. Example, a 15x15 grid will have 225 cells. We can start off with that.

We need to know if a cell is alive or dead. So we could model a cell like this:

type alias Cell = { status : Status }
type Status = Alive | Dead

But of course, we'd also need to know where that cell is located in the grid because we'd need to that to compute the neighbors...

type alias Cell = { status : Status, position : Position }
type Status = Alive | Dead
type alias Position = (RowId, ColumnId)
type alias RowId = Int
type alias ColumnId = Int

That is, we just represent a cell as: a row index, a column index (these two locate the cell's position in the grid) and then the status which tells us whether the cell is alive or dead.

The grid is just a list of cells. So:

type alias Grid = Array Cell

Why Array instead of List?

• Eventually, we'd need to work out the neighboring cells of a cell.
• This involves filtering the cells.
• Arrays are faster when it comes to such accesses.
• Hence, using Array instead of List.

1. How to render a board?

We have our types defined.

Let's now try and render a sample grid.

To get a sample grid, I'm going to use a random generator.

Generating a random Grid

The logic is this:

• start with a "random cell generator" – takes a rowId, a columnId and returns a cell generator where the status could be dead or alive (with a 40/60 odds).
• use this generator to create a Grid generator that can generate a list of cells when called

First, the random cell generator:

randomCellGenerator : RowId -> ColumnId -> Random.Generator Cell
randomCellGenerator rowId columnId =
    let position = (rowId, columnId)
    in
    Random.weighted (40, { position = position, status = Alive })
        [ (60, { position = position, status = Dead }) ]

Then, we use this in our Grid generator:

randomGridGenerator : Int -> Random.Generator Grid
randomGridGenerator size =
		-- create a List that starts with 1, and goes up to the size of the grid
    List.range 1 ((size * size))
    -- now map the list created above
    |> List.map
            (\cellId ->
                let
                    remainder =
                        remainderBy size cellId

                    rowId =
                        if remainder /= 0 then
                            (cellId // size) + 1

                        else
                            cellId // size

                    -- this creates the rowId
                    columnId =
                        if remainder == 0 then
                            size

                        else
                            remainder

                    -- this creates the columnId
                in
                randomCellGenerator rowId columnId
            )
    -- the above step returns a `List (Generator Cell)` but we need `Generator (List Cell)` so we `sequence` it. For this we use the `Random.Extra` package
    |> Random.Extra.sequence
    -- and finally convert it into an Array.
    |> Random.map (Array.fromList)

The random generator Generator Grid is not useful on its own.

We need to run the generator (so it generates the Grid) and for that, we need a Msg.

type Msg
    = UpdateGrid Grid

type alias Model =
    { grid : Grid, size : Int }

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        UpdateGrid grid ->
            ({ model | grid = grid }, Cmd.none)

init : () -> ( Model, Cmd Msg )
init _ =
    let
        size =
            15
    in
    ( { grid = Array.empty, size = size }, Random.generate UpdateGrid (randomGridGenerator size) )

In the init function, I'm generating a 15x15 grid.

Rendering the Grid

Again, simple composition here.

• First, we write a function that renders a cell.
• Then, we use this to compose the function that writes an entire grid.
• We'll use CSS grid for layout.

The function that renders a cell:

viewCell : Cell -> Html Msg
viewCell { status, position } =
    case status of
        Alive ->
            div
                [ Attr.style "background-color" "black"
                , Attr.style "width" "16px"
                , Attr.style "height" "16px"
                , Attr.style "border" "1px solid black"
                ]
                [ text "" ]

        Dead ->
            div
                [ Attr.style "background-color" "white"
                , Attr.style "width" "16px"
                , Attr.style "height" "16px"
                , Attr.style "border" "1px solid black"
                ]
                [ text "" ]

Now, the grid renderer:

viewGrid : Model -> Html Msg
viewGrid { grid, size } =
    div
        [ Attr.style "display" "grid"
        , Attr.style "gap" "0"
        , Attr.style "grid-template-columns" ("repeat(" ++ String.fromInt size ++ ",16px)")
        ]
        (Array.map viewCell grid |> Array.toList)

-- simply map over the grid (which is an array) using the `viewCell` function, but convert that into a `List` because it's easier to deal with `List (Html Msg)` in view/render functions in Elm.

And finally:

view : Model -> Html Msg
view model =
    viewGrid model

If we ran this application now, we get something like this:

2. Computing the "next" generation of the app

Conway's game of life proceeds by moving to the "next" generation. Each "step" is going to the next generation.

Next generation basically means which cells survive and which die.

To compute this, we need two things:

• who are the neighbors?
• what are their statuses?
• what are the rules for a cell to survive, die or revive depending on its neighbors?

First, the neighbors:

Imagine a cell at the center...

The neighboring cells are:

• top-left == rowId-1, columnId-1
• top == rowId-1, columnId
• top-right == rowId-1, columnId+1
• left = columnId-1
• right = columnId+1
• bottom-left == rowId+1, columnId-1
• bottom == rowId+1, columnId
• bottom-right == rowId+1, columnId+1

Sometimes, some of these neighbors may not exist. Example: top-left-most cell (ie, start of the grid) does not have a top-* or left neighbor.

But that's okay.

We know the formula for neighbors now. We can use this to get a list of "valid" neighboring cells.

isTopLeft : Position -> Cell -> Bool
isTopLeft ( rowId, columnId ) { position } =
    rowId == Tuple.first position - 1 && columnId == Tuple.second position - 1


isTop : Position -> Cell -> Bool
isTop ( rowId, columnId ) { position } =
    rowId == Tuple.first position - 1 && columnId == Tuple.second position


isTopRight : Position -> Cell -> Bool
isTopRight ( rowId, columnId ) { position } =
    rowId == Tuple.first position - 1 && columnId == Tuple.second position + 1


isLeft : Position -> Cell -> Bool
isLeft ( rowId, columnId ) { position } =
    Tuple.first position == rowId && columnId == Tuple.second position - 1


isRight : Position -> Cell -> Bool
isRight ( rowId, columnId ) { position } =
    Tuple.first position == rowId && columnId == Tuple.second position + 1


isBottomLeft : Position -> Cell -> Bool
isBottomLeft ( rowId, columnId ) { position } =
    rowId == Tuple.first position + 1 && columnId == Tuple.second position - 1


isBottom : Position -> Cell -> Bool
isBottom ( rowId, columnId ) { position } =
    rowId == Tuple.first position + 1 && columnId == Tuple.second position


isBottomRight : Position -> Cell -> Bool
isBottomRight ( rowId, columnId ) { position } =
    rowId == Tuple.first position + 1 && columnId == Tuple.second position + 1


getNeighboringCells : Cell -> Grid -> Array Cell
getNeighboringCells cell grid =
    Array.filter
        (\cell_ ->
            isTopLeft cell_.position cell
                || isTopRight cell_.position cell
                || isTop cell_.position cell
                || isLeft cell_.position cell
                || isRight cell_.position cell
                || isBottomLeft cell_.position cell
                || isBottomRight cell_.position cell
                || isBottom cell_.position cell
        )
        grid

We can test this in a Debug statement:

> getNeighboringCells { status = Alive, position = ( 1, 1 ) } grid

Array.fromList [{ position = (1,2), status = Dead },{ position = (2,1), status = Dead },{ position = (2,2), status = Dead }]

Now that we have the neighbors (and their status), we can compute if the cell will be alive, dead or revived from death.

These are the rules:

• a "live" cell will live in the next generation if it has exactly 2 or 3 "live" neighbors
• a "live" cell will die if it has less than 2 or more than 3 "live" neighbors
• a "dead" cell will come alive if it has exactly 3 "live" neighbors
• a "dead" cell will remain dead if it has less than 3 neighbors.

newStatusOfCell : Cell -> Grid -> Cell
newStatusOfCell cell grid =
    let
        neighboringCells =
            getNeighboringCells cell grid

        totalCellsAlive =
            Array.filter (\{ status } -> status == Alive) neighboringCells |> Array.length
    in
    case cell.status of
        Alive ->
            if totalCellsAlive == 2 || totalCellsAlive == 3 then
                { cell | status = Alive }

            else
                { cell | status = Dead }

        Dead ->
            if totalCellsAlive == 3 then
                { cell | status = Alive }

            else
                cell

It's worth adding a "Next" Msg to our app so it's easy to test the above function right away.

type Msg
    = UpdateGrid Grid
    | Next -- the new Msg

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        UpdateGrid grid ->
            ( { model | grid = grid }, Cmd.none )

        Next ->
            ( { model | grid = Array.map (\cell -> newStatusOfCell cell model.grid) model.grid }, Cmd.none )

view : Model -> Html Msg
view model =
    div []
        [viewGrid model, div [] [ button [ onClick Next ] [text "Next Gen"] ] ]

This renders a "Next Gen" button under the grid and clicking that advances the grid to the next generation. You can fiddle around with the app at this stage here

3. Making the grid come alive

The final step is to make the grid come alive. That is, it should step to the next generation automatically!

To do this, we'll add a Tick Msg that calls itself. Since we have the Next msg that computes the next generation of the board, we can re-use that!

type Msg
    = UpdateGrid Grid
    | Next
    | Tick -- we added a new Msg type


update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        UpdateGrid grid ->
            -- existing code as is

        Next ->
            -- existing code as is

        Tick ->
            let
                ( newModel, _ ) =
                    update Next model -- grab the new model/grid
            in
            ( newModel
            , Task.perform (\_ -> Tick) (Process.sleep 1000.0)
            )

I'm using Process.sleep to mimic the behavior of Javascript's setTimeout. And then I use the Task.perform to perform some task – in this case, (\_ -> Tick).

To trigger this, we'll add a Start button:

view : Model -> Html Msg
view model =
    div []
        [ viewGrid model
        , div []
            [ button [ onClick Next ] [ text "Next Gen" ]
            , button [ onClick Tick ] [ text "Start" ]
            ]
        ]

If you now click on the Start button, the grid starts changing every second, essentially moving to the next generation.

And the cells live/die or come alive depending on the rules.

Here's the final output you can play with.

You could try and add more features:

• a "Pause" function.
• a way to stop the game when either every cell dies or when it reaches an equilibrium.
• configurable size of the grid.

Making a basic calendar UI turned out to be a great example of this.

Here's the final output I aimed for:

I started by thinking about the lowest unit: the month.

Given a month (and a year), can I get this?

My first idea was to do this:

• get all dates in a given month-year.
• get some padding for the first week and padding for the last week so that I can fill them with empty blocks (this depends on when the week starts)
• pass this data to a rendering function!

The type of data we choose should be good enough to make it possible to render it easily.

So, in our case, we're rendering dates. Lists of dates.

And because we're rendering "rows" of dates, each row is a week of dates.

So the data structure I'm going for is this:

-- assuming `Date` is some valid date representation
type Week = List Date
type MonthData = List Week

MonthData could have 5-6 items, each item being a Week. And each Week being a list of 7 Dates.

I took a look at Elm's time library to see if that fit the bill. Turns out it didnt. It's too low-level and involves a lot of Task mechanics that was an overkill.

Looking around, I found Justin's date library which seemed like a great candidate.

(Edit: In fact, it turned out to be a life-saver. It has everything we need.)

Justin's date library had these two functions which were interesting:

ceiling : Interval -> Date -> Date
-- Round up a date to the beginning of the closest interval. The resulting date will be greater than or equal to the one provided.

floor : Interval -> Date -> Date
-- Round down a date to the beginning of the closest interval. The resulting date will be less than or equal to the one provided.

So, if I wanted to find the nearest "previous" Sunday before 1st July 2023, I can do this:

import Date
import Time

result = Date.floor Date.Sunday (Date.fromCalendarDate 2023 Time.Jul 1)

Testing this in REPL:

> result |> Date.format "EEE, d MM y"
"Sun, 25 Jun 2023" : String

And if I wanted to nearest "next" Saturday after 31st of July 2023, I can do this:

import Date
import Time

result = Date.ceiling Date.Saturday (Date.fromCalendarDate 2023 Time.Jul 31)

In REPL:

> result |> format "EEE, d MMM y"
"Sat, 5 Aug 2023" : String

That's fantastic. Now, my logic is simplified to this:

• take start of week (eg Sunday), month and year as inputs
• compute the "proper" start date (which is the nearest start of week for a given first-day of the month)
• compute the "proper" end date (which is the nearest start of week minus one for a given last-day of the month)
• get all dates falling between these two dates (including both) – this becomes a list of all dates to render
• split them into groups of 7 and we have a list of weeks... which is the same as our MonthData!

Getting the start date for a given month, year and start of week:

First step: take month, year and start of week and output the right/proper start date.

Example what we want:

-- `getProperStartDate : StartOfWeek -> Month -> Year -> Date`
getProperStartDate Sunday July 2023 == "25th June 2023"
getProperStartDate Sunday June 2023 == "28th May 2023"

-- ignore the fact that the result is string. that's just for demonstration

To get here, we just have to use the floor function from the Date library:

import Date
import Time

getProperStartDate : StartOfWeek -> Month -> Year -> Date.Date
getProperStartDate startOfWeek month year =
    Date.floor (weekdayToInterval startOfWeek) (Date.fromCalendarDate year month 1)

-- we also need a function that converts a Time.Weekday to a Date.Interval
-- to use in the `getProperStartDate` function
weekdayToInterval : Time.Weekday -> Date.Interval
weekdayToInterval weekday =
    case weekday of
        Time.Sun ->
            Date.Sunday

        Time.Mon ->
            Date.Monday

        Time.Tue ->
            Date.Tuesday

        Time.Wed ->
            Date.Wednesday

        Time.Thu ->
            Date.Thursday

        Time.Fri ->
            Date.Friday

        Time.Sat ->
            Date.Saturday

Test in REPL:

> getProperStartDate Time.Sun Time.Jul 2023 |> Date.format "EEE, d MMM y"
"Sun, 25 Jun 2023" : String

Next up, let's also write a function to get the proper end date for a given month, year and start of week.

This time, it's not as straight-forward.

Take 31st July 2023 and Sunday (for start of week) as an example:

• 31st July 2023 is a Monday
• The next closest Sunday is 6th August 2023.
• But we don't need a "Sunday". We need the next closest "Saturday".
• At first, I thought "hey we could compute the actual end of week day from the given start-of-week day" but that's a lot of code. Instead, we can just get the next-closest Sunday and then reduce 1 day!

And here's that logic:

getProperEndDate : StartOfWeek -> Month -> Year -> Date.Date
getProperEndDate startOfWeek month year =
    let
        endDate =
            Date.add Date.Months 1 (Date.fromCalendarDate year month 1) |> Date.add Date.Days -1

        endDateIsStartOfWeek =
            Date.weekday endDate == startOfWeek
    in
    if endDateIsStartOfWeek then
        Date.add Date.Days 7 endDate

    else
        Date.ceiling (weekdayToInterval startOfWeek) endDate |> Date.add Date.Days -1

• First we calculate the end date of the month.
• Then we find the actual end date we need – this happens to be the closest "start of week" day minus 1 (so that it's the end of the week).
• One small additional condition there that checks if the actual end date of the month also happens to be the start of the week. In that case, we add 7 days to get to the closest end of week day.

Testing this in REPL:

> getProperEndDate Time.Sun Time.Jul 2023 |> format "EEE, d MMM y"
"Sat, 5 Aug 2023" : String

Now that we know the proper start and end dates, we can use them to get all dates in that range.

getDatesBetween : Date.Date -> Date.Date -> List Date.Date
getDatesBetween start end =
    Date.range Date.Day 1 start (Date.add Date.Days 1 end)

This Date.range function excludes the last date in the range. But we need the proper end date as well, so we just add one.

And now that we have all the dates to render, we can group them to get a list of weeks!

To do this, I'm using the List.Extra library's groupsOf function:

getMonth : List Date.Date -> List Week
getMonth =
    List.Extra.groupsOf 7

And of course, we need to take just month, year and start of week as inputs and get back an entire month of dates:

getDatesForMonth : Month -> Year -> List Week
getDatesForMonth month year =
    let
        start =
            getProperStartDate Time.Sun month year

        end =
            getProperEndDate Time.Sun month year

        dates =
            getDatesBetween start end
    in
    getMonth dates

Yes, we're just hard-coding the start of the week (Time.Sun) for now. We can switch this later to be something that the function accepts as an input.

Testing these in REPL:

> getDatesForMonth Time.Jul 2023
[[RD 738696,RD 738697,RD 738698,RD 738699,RD 738700,RD 738701,RD 738702],[RD 738703,RD 738704,RD 738705,RD 738706,RD 738707,RD 738708,RD 738709],[RD 738710,RD 738711,RD 738712,RD 738713,RD 738714,RD 738715,RD 738716],[RD 738717,RD 738718,RD 738719,RD 738720,RD 738721,RD 738722,RD 738723],[RD 738724,RD 738725,RD 738726,RD 738727,RD 738728,RD 738729,RD 738730],[RD 738731,RD 738732,RD 738733,RD 738734,RD 738735,RD 738736,RD 738737]]

The RD Int is a native representation of the Date library.

We can format this to be human-friendly and check that the results are OK:

> getDatesForMonth Time.Jul 2023 |> List.map (List.map (Date.format "EEE, d MMM y"))
[["Sun, 25 Jun 2023","Mon, 26 Jun 2023","Tue, 27 Jun 2023","Wed, 28 Jun 2023","Thu, 29 Jun 2023","Fri, 30 Jun 2023","Sat, 1 Jul 2023"],["Sun, 2 Jul 2023","Mon, 3 Jul 2023","Tue, 4 Jul 2023","Wed, 5 Jul 2023","Thu, 6 Jul 2023","Fri, 7 Jul 2023","Sat, 8 Jul 2023"],["Sun, 9 Jul 2023","Mon, 10 Jul 2023","Tue, 11 Jul 2023","Wed, 12 Jul 2023","Thu, 13 Jul 2023","Fri, 14 Jul 2023","Sat, 15 Jul 2023"],["Sun, 16 Jul 2023","Mon, 17 Jul 2023","Tue, 18 Jul 2023","Wed, 19 Jul 2023","Thu, 20 Jul 2023","Fri, 21 Jul 2023","Sat, 22 Jul 2023"],["Sun, 23 Jul 2023","Mon, 24 Jul 2023","Tue, 25 Jul 2023","Wed, 26 Jul 2023","Thu, 27 Jul 2023","Fri, 28 Jul 2023","Sat, 29 Jul 2023"],["Sun, 30 Jul 2023","Mon, 31 Jul 2023","Tue, 1 Aug 2023","Wed, 2 Aug 2023","Thu, 3 Aug 2023","Fri, 4 Aug 2023","Sat, 5 Aug 2023"]]

Now that I have this data structure, all I need to do is render it as a month!

We can work this inside-out. That is, we can build functions to render a date, a week and then combine these to render the month.

Here's a function to render the date:

(I'm using Tailwind classes to simplify styling)

viewDate : Date.Date -> Html Msg
viewDate date =
    H.div [ Attr.class "flex items-center justify-center" ] [ H.text <| Date.format "d" date ]

And the week:

viewWeek : Week -> Html Msg
viewWeek dates =
    H.div [ Attr.class "grid grid-cols-7 items-center gap-4" ] (List.map viewDate dates)

I'm using CSS grid to make it easy to arrange the dates. Each date is flex and center-aligned (see the viewDate function above). And the week-render takes care of rendering all dates in a 7-column grid.

And the view month is just this:

viewMonth : List Week -> Html Msg
viewMonth weeks =
    H.div [] (List.map viewWeek weeks)

And of course, we need to render the week header as well which lists the weekdays.

To do this, I'm going to be a bit hacky:

• We already have a list of weeks in List Week.
• We can take the "first" element of this list and
• format each date in the list to just extract the weekday
• and use the resulting list to render the week header!

Expressed in code, we start with the week header view function which takes a list of weeks and renders a list of weekday headers.

viewWeekHeader : Week -> Html Msg
viewWeekHeader week =
    H.div [ Attr.class "grid grid-cols-7 items-center gap-2" ] <|
        List.map (\date -> H.div [ Attr.class "flex items-center justify-center" ] [ H.text <| Date.format "EEEEE" date ]) week

Combining all of this into a view function:

view : Model -> Html Msg
view _ =
    let
        dates =
            getDatesForMonth Time.Jul 2023
    in
    H.div [ Attr.class "w-72" ]
        [ viewWeekHeader (Maybe.withDefault [] (List.head dates))
        , viewMonth dates
        ]

Here's what it renders as:

It's ugly, shows dates from the previous/next months and there's so much room for improvement.

But we've got the basics right and that's good enough to boot.

The first order of business now is to not show dates which are not part of the month.

In the example above, that's 25th - 30th (June) and 1st - 5th (August).

What we have is a long list of dates. We need to somehow know if a date in the list is part of the current month (eg July) or not.

Let's think in terms of the type:

type alias CalendarDate =
    { date : Date.Date, dateInCurrentMonth : Bool }

And we'll change our week to be:

type alias Week =
    List CalendarDate

The moment we make this change, the Elm compiler will start guiding us through the functions that need updating.

We'll change the getMonth one first:

getMonth : List CalendarDate -> List Week
getMonth =
    List.Extra.groupsOf 7

And:

getDatesForMonth : Month -> Year -> List Week
getDatesForMonth month year =
    let
        start =
            getProperStartDate Time.Sun month year

        end =
            getProperEndDate Time.Sun month year

        dates =
            getDatesBetween start end
                |> List.map (\date -> { date = date, dateInCurrentMonth = Date.month date == month })
    in
    getMonth dates

And the last things we need to fix are the viewDate and viewWeekHeader functions. The logic is simple: if the date is not that of current month, we'll set the opacity to 0.

viewDate : CalendarDate -> Html Msg
viewDate { date, dateInCurrentMonth } =
    H.div
        [ Attr.class "flex items-center justify-center"
        , Attr.class
            (if dateInCurrentMonth then
                ""

             else
                "opacity-0"
            )
        ]
        [ H.text <| Date.format "d" date ]

viewWeekHeader : Week -> Html Msg
viewWeekHeader week =
    H.div [ Attr.class "grid grid-cols-7 items-center gap-2" ] <|
        List.map (\{ date } -> H.div [ Attr.class "flex items-center justify-center" ] [ H.text <| Date.format "EEEEE" date ]) week

This gets us to here:

One of the things that's been bothering me about this render is that there's a lot of duplication because of the way we're rendering the rows.

Each row is it's own "grid", instead of the whole month being a grid. (And the week header is also it's own "grid").

We can fix this.

We want a structure like this:

<div class="grid grid-cols-7 items-center gap-2">
	<div>S</div>
	<div>M</div>
	<div>T</div>
	... all weekday headers
	...
	<div>1</div>
	<div>2</div>
	... all dates
</div>

We can do this in two steps:

1. first, we'll write one generic container viewBox which wraps all its children in the grid
2. then, we'll ensure all our viewMonth/viewWeek functions return a list of divs that we can just render inside the viewBox

viewBox : List (Html Msg) -> Html Msg
viewBox =
    H.div [ Attr.class "grid grid-cols-7 gap-2 items-center" ]

And to make life easier, I'll also add a viewItem (which is basically the date render):

viewItem : List (Html Msg) -> Html Msg
viewItem =
    H.div [ Attr.class "flex items-center justify-center" ]

And now, we'll change the other view functions so they return a List (Html Msg) instead of Html Msg:

viewWeek : Week -> List (Html Msg)
viewWeek dates =
    List.map viewDate dates


viewMonth : List Week -> List (Html Msg)
viewMonth weeks =
    List.concatMap viewWeek weeks


viewWeekHeader : Week -> List (Html Msg)
viewWeekHeader week =
    List.map (\{ date } -> H.div [ Attr.class "flex items-center justify-center" ] [ H.text <| Date.format "EEEEE" date ]) week

In the viewMonth function, we use the List.concatMap function because:

• viewMonth is a list.map over weeks using the viewWeek function
• the viewWeek function returns a list
• so the final result is list of lists
• which we concat to flatten into a list.

Finally, we'll modify the main view function:

view : Model -> Html Msg
view _ =
    let
        year =
            2023

        month =
            Time.Jul

        dates =
            getDatesForMonth month year
    in
    H.div [ Attr.class "w-72" ]
        [ H.div [ Attr.class "p-2" ] [ H.text (Date.format "MMMM YYYY" (Date.fromCalendarDate year month 1)) ]
        , viewBox <| List.concat [ viewWeekHeader (Maybe.withDefault [] (List.head dates)), viewMonth dates ]
        ]

The main change is that we're now using the viewBox function (so we modify the input to it).

And the other thing is we added this bit:

H.div [ Attr.class "p-2" ] [ H.text (Date.format "MMMM YYYY" (Date.fromCalendarDate year month 1))

which adds a month-year header.

Our final result:

All that remains is to repeat this for each month in a given year.

To do this, we can just write out all the months of a year, and loop over them:

view : Model -> Html Msg
view _ =
    let
        year =
            2023

        months =
            [ Time.Jan
            , Time.Feb
            , Time.Mar
            , Time.Apr
            , Time.May
            , Time.Jun
            , Time.Jul
            , Time.Aug
            , Time.Sep
            , Time.Oct
            , Time.Nov
            , Time.Dec
            ]
    in
    H.div [ Attr.class "p-8 grid grid-cols-4 gap-4 items-stretch" ]
        (List.map (\month -> viewMonthBox month year) months)

This produces:

Oh no! Here's a problem: the first month reads January 2022.

Turns out, the formatting string I was using is wrong:

Instead of MMMM YYYY, I need to be using MMMM y. (More info about these format strings here.)

[ H.div [ Attr.class "p-2 text-center" ] [ H.text (Date.format "MMMM y" (Date.fromCalendarDate year month 1)) ]

And that fixes the problem:

The full source code can be found here.

Two data structures specifically had this notion associated with them:

-- type Day = Int
-- type Price = Int

type StockDay = Tuple Price Day
-- and
data BuySell = BuySell StockDay StockDay

Two StockDays could be valid only if they happen on subsequent days.

That is:

a = Tuple _ 1
b = Tuple _ 6

c = Tuple _ 8
d = Tuple _ 4

In this, a followed by b can be a valid trade because the "day" order makes sense. (That is a is on 1st day and b is on 6th day - buy on 1st and sell on 6th).

But c followed by d (and b followed by d) are not valid because the day orders are reversed.

This notion comes into the picture when we "pair" these to make a BuySell combination.

We expressed this as a Maybe:

makeBuySell :: StockDay -> StockDay -> Maybe BuySell
makeBuySell t1@(Tuple p1 a) t2@(Tuple p2 b) =
  if a < b && p1 < p2 then Just (BuySell t1 t2) else Nothing

That a < b part takes care of the "valid trade" logic.

It's OK and there's no need to "improve" this...

But now, there's also this other function that we use in our computation:

isValidTradeDayOrder :: BuySell -> BuySell -> Boolean
isValidTradeDayOrder (BuySell (Tuple _ a) (Tuple _ b)) (BuySell (Tuple _ c) (Tuple _ d)) =
  (a < b && c < d && c > b) || (c < d && a < b && d < a)

Here, we're trying to confirm if two buy-sell pairs are actually valid by making sure the dates/days align. (Remember that within a BuySell pair, the StockDays are valid thanks to our makeBuySell function. Essentially, a BuySell represents valid, profitable buy-and-sell operation).

Again, though, in the case of a isValidTradeDayOrder, we're dealing with this idea of "valid trade".

I decided (or rather, wanted to experiment) if this general idea of a "valid trade" can be encoded into the code as a general function.

Purescript, like Haskell, allows you to define your own typeclasses and then define instances for your data types.

So, here's a generic ValidTrade class:

class ValidTrade a where
  validTrade :: a -> a -> Boolean

Any datatype using the ValidTrade class must simply describe a validTrade function.

And so, here are the definitions for both the StockDay and BuySell data types:

instance ValidTrade BuySell where
  validTrade (BuySell (Tuple _ a) (Tuple _ b)) (BuySell (Tuple _ c) (Tuple _ d)) =
    (a < b && c < d && c > b) || (c < d && a < b && d < a)

instance ValidTrade StockDay where
  validTrade (Tuple _ d1) (Tuple _ d2) = d1 < d2

I also added an infix to help make the code a little succinct:

infix 1 validTrade as ??

Now, I could get rid of the isValidTradeDayOrder function in totality and replace some instances with ??:

makeBuySell :: StockDay -> StockDay -> Maybe BuySell
makeBuySell t1@(Tuple p1 _) t2@(Tuple p2 _) =
  if (t1 ?? t2) && p1 < p2 then Just (BuySell t1 t2) else Nothing

bestBuySellPair :: BuySell -> SortedArray (BuySell) -> Int -> Maybe BestCandidate -> Maybe BestCandidate
bestBuySellPair buySell (SortedArray []) maxProfitSoFar bestTradeSoFar =
  if buySellProfit buySell > maxProfitSoFar then (Just $ Tuple buySell Nothing)
  else bestTradeSoFar
bestBuySellPair buySell (SortedArray tradePairs) maxProfitSoFar bestTradeSoFar =
  case head tradePairs of
    Just h ->
      -- notice the ?? here. we've replaced the `isValidTradeDayOrder` function with ??
      if ((buySell ?? h) && (buySellProfit buySell + buySellProfit h) > maxProfitSoFar) then bestBuySellPair buySell (fromMaybe (SortedArray []) (map SortedArray $ tail tradePairs)) (buySellProfit buySell + buySellProfit h) (Just $ Tuple buySell (Just h))
      else bestBuySellPair buySell (fromMaybe (SortedArray []) (map SortedArray $ tail tradePairs)) maxProfitSoFar bestTradeSoFar
    Nothing ->
      if buySellProfit buySell > maxProfitSoFar then (Just $ Tuple buySell Nothing)
      else bestTradeSoFar

And the script continues to run just fine:

> totalProfits [3,1,0,0,5,4,1]
5

> totalProfits [3,1,0,0,1]
1

> totalProfits [3,1,0,0,1,2,3]
3

Updated source-code here.

Today, I decided to pick this one.

You are given a list of integers representing a stock's price for consecutive days.

[3,1,0,0,5,4,1,3]

You can buy on one day and then sell on any future day. You cannot buy and sell on the same day, nor can you buy more than once before selling it. Also, you can only buy and sell atmost twice. (That is, two buy-sell trades).

Given those conditions, find out what's the maximum profit you can make if you picked the best 1 or at most 2 trades from the list.

So for the example list of numbers from above, here's one potential candidate of trades that can net you the maximum profit:

stock prices: [3,1,0,0,5,4,1,3]
max profit = 7
because:
best trade #1 = 0 (buy on day 3 or 4), 5 (sell on 5th day) => profit = 5
best trade #2 = 1 (buy on 7th day), 3 (sell on 9th day) => profit = 2
total profit = 7

I thought that the first thing to do was to sort the array ascending so that it was eaiser to know which trades netted the maximum profits.

Example:

unsorted: [3,1,0,0,5,4,1,3]
sorted: [0,0,1,1,3,3,4,5]

But of course, we have to also "carry" the information of which number (price) belongs to which day (original index) because to be able to calculate the best trade, we need to have a valid buy-sell sequence. If I sort the list, I know 0 and 5 net a great profit but those could not even be a valid sale as 5 could be on day 1 and 0 could be on day 2 (i.e, you cant sell before you buy).

Something like this would be a better data to carry around:

unsorted: [3,1,0,0,5,4,1,3]
sorted but with date info:
  [(0,3), (0,4), (1,2), (1,7), (3,1), (3,8), (4,6), (5,5)]

In Purescript, that's a Tuple:

type Price = Int

type Day = Int

type StockDay = Tuple Price Day

arrayToStockDay :: Array Int -> SortedArray StockDay
arrayToStockDay xs = sortStockDay $ go xs 1 []
  where
  go :: Array Int -> Int -> Array StockDay -> Array StockDay
  go [] _ acc = acc
  go ys day acc =
    case head ys of
      Just stockPrice -> go (fromMaybe [] $ tail ys) (day + 1) (snoc acc (Tuple stockPrice day))
      Nothing -> acc

(I will cover the SortedArray bit shortly; for now, treat it just as a wrapper around an Array)

This data structure lets me do an important thing: find all possible valid trades (single buy-and-sell) and their profit.

Suppose I take the first item: (0,3)

I can now iterate over the rest of the items and make up a list of valid buy-sell trades like this:

buy = (0,3)
valid sells =
  (0,4)
  (1,7)
  (3,8)
  (4,6)
  (5,5)

(1,2) and (3,1) are not valid because their "days" are before the chosen (0,4).

And now, I can do one more thing: get profits for each of the valid sells.

buy = (0,3)
valid sells with profit info =
  (0,4) => 0
  (1,7) => 1
  (3,8) => 3
  (4,6) => 4
  (5,5) => 5

Let me do this for the next item in the list (0,4)

buy = (0,4)
valid sells with profit info =
  (1,7) => 1
  (3,8) => 3
  (4,6) => 4
  (5,5) => 5

And more:

buy = (1,2)
valid sells with profit info =
  (1,7) => 0
  (3,8) => 2
  (4,6) => 3
  (5,5) => 4

buy = (1,7)
valid sells with profit info =
  (3,8) => 2

and so on.

Notice that because I'm sorting the array by the stock price, I only have to pick the subsequent items in an array when comparing one item with the rest.

What I need now is to somehow represent all that data (from the previous step) so that I can then use it to find out the best two sequential trades that can give me maximum profits.

I could simply rely on another "pair" like so:

buy = (0,3)
valid sells with profit info =
  (0,4) => 0
  (1,7) => 1
  (3,8) => 3
  (4,6) => 4
  (5,5) => 5

can be represented as:

[
  ( (0,3) , (0,4) ),
  ( (0,3) , (1,7) ),
  ( (0,3) , (3,8) )
  ( (0,3) , (4,6) ),
  ... and so on
]

And then you just combine all of them to have one giant list of all valid profit-making sales. By the time I get to code, I'll have one more check to filter out those valid trades that result in some profit so the list is really small. (Our example only has 14 valid profit-making buy-sell combinations).

Translating this logic to code, I worked from the smallest step: if I compare two stock-price-day items, I should be able to tell if the pair is a valid buy-sell trade:

import Data.Tuple (Tuple(..))
import Data.Maybe (Maybe(..))

-- represeting a buy sell trade
data BuySell = BuySell StockDay StockDay

makeBuySell :: StockDay -> StockDay -> Maybe BuySell
makeBuySell t1@(Tuple p1 a) t2@(Tuple p2 b) =
  if a < b && p1 < p2 then Just (BuySell t1 t2) else Nothing

I use the Maybe data type to indicate if a comparison of two stock-price-day items results in a valid pair (valid by both day sequence and guaranteed profit).

I can use this makeBuySell function to do the comparison I wrote about earlier:

import Data.Array (snoc, head, tail)
import Data.Maybe (Maybe(..), fromMaybe)

makeBuySellList :: StockDay -> SortedArray StockDay -> Array BuySell
makeBuySellList sdp (SortedArray xs) = go sdp xs []
  where
  go _ [] acc = acc
  go _sdp ls acc = case head ls of
    Just h -> case makeBuySell _sdp h of
      Nothing -> go _sdp (fromMaybe [] $ tail ls) acc
      Just tp -> go _sdp (fromMaybe [] $ tail ls) (snoc acc tp)
    Nothing -> acc

Okay, pause here. I'm using a new data type called SortedArray. It's really just a newtype.

But why?

An Array can be sorted or unsorted. There is no way for me to know, by looking at a type signature, if an array being used by a function is sorted or not. Also, sorting can mean different things when we are talking about a Tuple or complex data structures.

So, I decided to use a newtype called SortedArray to indicate any array that is sorted (in some way).

newtype SortedArray a = SortedArray (Array a)

Again, I am not interested in the sort order or the sort logic here. All I want is a distinction between any random array (that could or could not be sorted) and a sorted array which is sorted using some logic that I don't care about.

Also, to make development easy, I decided to write a Show instance for it:

instance showSortedArray :: Show a => Show (SortedArray a) where
  show (SortedArray a) = "SortedArray " <> show a

I tried to derive a Show instance for this (via derive newtype instance) but given that the polymorphic a is really an unknown, I couldn't write a derivation. That's a knowledge-gap for me.

Finally, with these functions, I can go through the whole list and make combinations:

import Data.Array (reverse, sortBy, head, tail, concat)
import Data.Maybe (Maybe(..), fromMaybe)

makeBuySellCombinationsList :: SortedArray StockDay -> SortedArray BuySell
makeBuySellCombinationsList xs = SortedArray $ reverse $ sortBy sortBuySell $ go xs ([])
  where
  go :: SortedArray StockDay -> Array BuySell -> Array BuySell
  go (SortedArray []) tps = tps
  go (SortedArray sdps) (tps) =
    case head sdps of
      Nothing -> (tps)
      Just h -> go (SortedArray $ fromMaybe [] $ tail sdps) (concat [ tps, makeBuySellList h (SortedArray $ fromMaybe [] $ tail sdps) ])

sortBuySell :: BuySell -> BuySell -> Ordering
sortBuySell bs1 bs2 =
  if buySellProfit bs1 > buySellProfit bs2 then GT else LT

Worth noting that while I make this list, I am also sorting the list by profits descending. That means, I have buy-sell combinations with maximum profit at the front of the list.

With this (reverse) sorted list, I can now simply do this:

• take the highest profit-making trade
• compare it to the next-highest profit-making trade
• check if the day/date sequence works out. That is, the first trade sequence should have dates that are either before or after the second trade sequence in the comparison.

Here's one example of valid combo:

((0,4), (5,5))
followed by
(1,7),(3,8)
is valid
because I buy on 4th day, sell on 5th,
then buy again on 7th day and sell on 8th.

The interesting thing to note is that I have to check for both directions. I could have a combination like this:

((1,7), (9,8))
compared with
((0,2),(3,6))

That is also a valid combination because you could buy on 2nd day, sell on 6th, then buy again on 7th day and sell on 8th.

So, basically, check both directions.

isValidTradeDayOrder :: BuySell -> BuySell -> Boolean
isValidTradeDayOrder (BuySell (Tuple _ a) (Tuple _ b)) (BuySell (Tuple _ c) (Tuple _ d)) =
  (a < b && c < d && c > b) || (c < d && a < b && d < a)

Before I write the function that goes through a list of sorted buy-sell pairs and fetches a possible "best candidate", I need to define what a "best candidate" really is:

type BestCandidate = Tuple BuySell (Maybe BuySell)

The idea really is this -> A best candidate is potentially:

• either a pair of two buy-sell trades
• or just one buy-sell trade

Why the second option?

Because according to the leetcode puzzle, you are allowed at most two trades in total. That means, you could also have a case where you make maximum profits with just one trade (and there is no other trade you can make which is profitable after the first).

Hence, the structure:

type BestCandidate = Tuple BuySell (Maybe BuySell)

The second (Maybe BuySell) is that "optional" buy-sell trade.

And now, the function that works through the whole list and picks the best candidate:

workThroughStockDays :: SortedArray BuySell -> Maybe BestCandidate
workThroughStockDays tradePairs = go tradePairs 0 (Nothing)
  where
  go :: SortedArray BuySell -> Int -> Maybe BestCandidate -> Maybe BestCandidate
  go (SortedArray []) _ candidate = candidate
  go (SortedArray tps) maxProfitSoFar candidate =
    case head tps of
      Just tp ->
        let
          candidate1 = bestBuySellPair tp (SortedArray tps) maxProfitSoFar candidate
          bestCandidate = case candidate, candidate1 of
            Just c1, Just c2 -> Just $ getBestCandidate c1 c2
            Just c1, Nothing -> Just c1
            Nothing, Just c2 -> Just c2
            _, _ -> Nothing
          newMaxProfitSoFar = map candidateProfit bestCandidate # fromMaybe 0
        in
          go (fromMaybe (SortedArray []) $ map SortedArray $ tail tps) newMaxProfitSoFar bestCandidate
      Nothing -> candidate

The logic of the workThroughStockDays function is this:

• take the first item from the BuySell list (ie, the first buy-sell pair/combination)
• check if it has the best candidature (ie, max profits) when compared with another candidature (starting value of this candidature is Nothing)
• get the profit value for the best candidate from the comparison
• feed it recursively to the next step and do this till you run out of BuySell items in the list

The best candidate comparison function is this:

bestBuySellPair :: BuySell -> SortedArray (BuySell) -> Int -> Maybe BestCandidate -> Maybe BestCandidate
bestBuySellPair buySell (SortedArray []) maxProfitSoFar bestTradeSoFar =
  if buySellProfit buySell > maxProfitSoFar then (Just $ Tuple buySell Nothing)
  else bestTradeSoFar
bestBuySellPair buySell (SortedArray tradePairs) maxProfitSoFar bestTradeSoFar =
  case head tradePairs of
    Just h ->
      if (isValidTradeDayOrder buySell h && (buySellProfit buySell + buySellProfit h) > maxProfitSoFar) then bestBuySellPair buySell (fromMaybe (SortedArray []) (map SortedArray $ tail tradePairs)) (buySellProfit buySell + buySellProfit h) (Just $ Tuple buySell (Just h))
      else bestBuySellPair buySell (fromMaybe (SortedArray []) (map SortedArray $ tail tradePairs)) maxProfitSoFar bestTradeSoFar
    Nothing ->
      if buySellProfit buySell > maxProfitSoFar then (Just $ Tuple buySell Nothing)
      else bestTradeSoFar


buySellProfit :: BuySell -> Int
buySellProfit (BuySell a b) = fst b - fst a

There's a bit of a duplication there but I figured I could optimize this later.

Also, the getBestCandidate function:

getBestCandidate :: BestCandidate -> BestCandidate -> BestCandidate
getBestCandidate c1 c2 =
  if candidateProfit c2 > candidateProfit c1 then c2 else c1

candidateProfit :: BestCandidate -> Int
candidateProfit (Tuple t1 Nothing) = buySellProfit t1
candidateProfit (Tuple t1 (Just t2)) = buySellProfit t1 + buySellProfit t2

At this point, it looks like the pieces are in place so I can start composing them all to go from an array of integers to a best candidate!

arrayToBuySellList :: Array Int -> SortedArray BuySell
arrayToBuySellList = arrayToStockDay >>> makeBuySellCombinationsList

findBestCandidate :: Array Int -> Maybe BestCandidate
findBestCandidate = arrayToBuySellList >>> workThroughStockDays

One final step. Just having a Maybe BestCandidate is not good. I need to know what profits were made (that's the original solution).

So:

profitFromBestCandidate :: BestCandidate -> Int
profitFromBestCandidate (Tuple tp1 Nothing) = buySellProfit tp1
profitFromBestCandidate (Tuple tp1 (Just tp2)) = buySellProfit tp1 + buySellProfit tp2

Now I can simply do:

totalProfits :: Array Int -> Int
totalProfits = findBestCandidate >>> map profitFromBestCandidate >>> fromMaybe 0

And as a test:

> totalProfits [3,1,0,0,5,4,1,3]
7

> totalProfits [3,1,0,0,5,4,1]
5

> totalProfits [3,1,0,0]
0

> totalProfits [3,1,0,0,1]
1

> totalProfits [3,1,0,0,1,2,3]
3

The full source-code can be found here.

Update: I wrote some notes on refactoring small bits of the code to use a custom Typeclass to define what's a "valid trade".

In the last part, I left here:

All that remains now is getting ValidLines out of the given array of words.

I just got around to writing the function that converts an array of strings into an array of valid lines that I can then pass/process through the validLineToParaLine function I wrote in part two.

validLineToParaLine :: Int -> ValidLine -> String
validLineToParaLine maxLen (ValidLine xs) =
  specialIntercalate xs (makeSpaces maxLen (ValidLine xs))
  # Str.joinWith ""

Here's how I approached the validline generation. I was going to rely on an accumulating recursive function (very common in functional/recursive programs):

1. The function I'm going to write will keep track of a current valid line, a final array of valid lines, and the list of words to process.
2. As a base case, if the list of words to process is empty, it's simply going to concatenate the final array of valid lines and the current valid line and return the whole thing. That will be my final valid line list!
3. If the list of words to process is not empty:

• I'm going to pick the first element from the words list
• and then I'm going to add it temporarily to the current valid line that the function is carrying around
• and check if the total length of this temporary valid line is less than the max-length
• if yes, I will recurse again on the function, passing as the list of words to process the tail of the list (because I've already picked out the first element)
• if not, I will just add whatever's current valid line to the final valid lines list, and recurse on the function, passing in existing list of words (because I did not use the first element) and also emptying out the current valid line because a new valid line is going to form.

In code:

listToValidLines :: Int -> Array String -> Array ValidLine
listToValidLines maxlen xs = helper (ValidLine []) [] xs
  where
    helper :: ValidLine -> Array ValidLine -> Array String -> Array ValidLine
    helper (ValidLine acc) final [] = snoc final (ValidLine acc)
    helper (ValidLine acc) final ys =
      case head ys of
        Maybe.Nothing -> helper (ValidLine acc) final (Maybe.fromMaybe [] $ tail ys)
        Maybe.Just wrd ->
          let
            tempValidLine = snoc acc wrd
            lengthTempValidLine = totalCharLength $ ValidLine tempValidLine
          in
            if lengthTempValidLine > maxlen
              then helper (ValidLine []) (snoc final (ValidLine acc)) ys
              else helper (ValidLine tempValidLine) final (Maybe.fromMaybe [] $ tail ys)

There's a bit of a Maybe wrangling because I'm using head and tail, but it's OK. The code is safer.

Now that I have a function that converts an array of words to an array of valid lines, I can simply map over this list to generate a list of justified lines!

justify :: Int -> Array String -> Array String
justify maxWidth = listToValidLines maxWidth >>> map (validLineToParaLine maxWidth)

maxWidth is the same as max length of a line.

I could've written it this way too:

justify :: Int -> Array String -> Array String
justify maxWidth xs = listToValidLines maxWidth xs # map (validLineToParaLine maxWidth)

Time to test:

> justify 16 ["This", "is", "an", "example", "of", "text", "justification", "folks,", "okay?"]
["This----is----an","example--of-text","justification","folks,-----okay?"]

We can join this text with "\n" to get a paragraph:

justify 16 ["This", "is", "an", "example", "of", "text", "justification", "folks,", "okay?"] # joinWith "\n"

This----is----an
example--of-text
justification
folks,-----okay?

The last rule in the puzzle was:

the last line can be left-aligned so just one space between the words is fine.

I think there are a couple of ways to accomplish this.

I could have used an indexed map in justify function to not justify the last item in the array of valid lines.

Or I could simply use regex to replace all multilpe spaces (ie, one or more spaces) with just one space in the last line.

Those are trivial, so leaving it here for now.

You can play around with the full-code here.

In the first part, I had this problem to fix:

The trick is to find out how to go from a "number of spaces to distribute" to a "special spaces array".

I worked through a few examples to get an intuitive feel of how the logic could look like:

Suppose there are 7 spaces to distribute in 3 slots:

spaces to distribute        -> 7
slots                       -> 3

I could first distribute equally by dividing the two (integer division):

equal division        -> 7 / 3 = 2 (remainder 1)
                      -> ["--", "--", "--"]

And then distribute the remainder left-to-right:

equal division        -> 7 / 3 = 2 (remainder 1)
                      -> ["--", "--", "--"]
with remainder        -> ["---", "--", "--"]
distributed

I tried to run some more examples for this. Like this:

spaces to distribute  -> 15
slots to distribute   -> 4
equal distribution    -> 15/4 => 3
                      -> ["---","---","---","---"]
remainder             -> 3
remainder distributed -> ["----","----","----","---"]

This still did not give me a clear grasp of the distribution logic.

Eventually, I came up with this idea: I could have a function that gradually "builds" the array of spaces from an empty array.

It would do this by "remembering" and "updating" the number of extra/remainder spaces it has to distribute across the slots.

So, something like this:

example: 15 spaces, 4 slots

step 1: empty array ([]), number of slots to fill (4), number of remainders to distribute (remainder 15/4 = 3)
step 2:
  - push the first space slot into the array [?]
  - where ? = normally, just the equal distribution of space.
  - in this case, that's 15/4 quotient = 3. so => [3]
  - but the number of remainders to distribute is more than 0,
  - so we just add 1 more to the fill => [4]
  - now that we've filled the first, we have to reduce number of slots to fill to 3.
  - also, we've distributed 1 of the 3 remainders to distribute so that also becomes 2.
step 3:
  - repeat the above step for the next slot,
    but remember that we only have 2 remainders to distribute and 3 slots to fill.
...and so on...

Doing this "recursively" gives us a final array of space slots.

The function looks something like this:

import Prelude

import Data.Array (snoc, catMaybes)
import Data.Int (quot, rem)
import Data.String.Utils (repeat)

makeSpaces :: Int -> ValidLine -> Array String
makeSpaces maxLen vl =
  let
    d = deficit maxLen vl
    spaceSlots = numberOfSpaces vl
    totalSpaces = d + spaceSlots
  in
    makeSpacesHelper [] (quot totalSpaces spaceSlots) (rem totalSpaces spaceSlots) spaceSlots
    # map (\a -> repeat a "-")
    -- note: I'm using hyphens for demonstration
    -- use space in the real program
    # catMaybes

makeSpacesHelper :: Array Int -> Int -> Int -> Int -> Array Int
makeSpacesHelper xs _ _ 0 = xs
makeSpacesHelper xs n incCount timesCount =
  makeSpacesHelper (snoc xs a) n (incCount-1) (timesCount-1)
    where
    a = n + (if incCount > 0 then 1 else 0)

In this:

incCount => the remainders to be distributed
timesCount => number of slots to be filled

I've used a bunch of helper functions in the above code like deficit, numberOfSpaces and some library functions like catMaybes.

Here's definitions for the helpers:

import Data.Array (length, foldl)
import Data.String as Str

deficit :: Int -> ValidLine -> Int
deficit maxLen vl = maxLen - (totalCharLength vl)

numberOfSpaces :: ValidLine -> Int
numberOfSpaces (ValidLine xs) = length xs - 1

totalCharLength :: ValidLine -> Int
totalCharLength (ValidLine xs) =
  foldl (\b a -> b + Str.length a) 0 xs + numberOfSpaces (ValidLine xs)

Testing all of this:

> makeSpaces 16 (ValidLine ["this","is","an"])
# that is max length is 16. valid line has char length = 10.
# deficit = 6. Total spaces to distribute is 6+2 = 8. Across 2 slots.
["----","----"]

> makeSpaces 19 (ValidLine ["a","b","c","d","e"])
# that is, max length is 19, valid line has 9 characters length, so deficit is 10.
# Total spaces to distribute is 10+4 = 14. Across 4 slots.
["----","----","---","---"]

All we need now is a way to mix an array of strings (from the ValidLine) and this spaces array such that the words and spaces are interleaved.

I checked Purescript's Array package and found a transpose function that fit the need perfectly:

transpose :: forall a. Array (Array a) -> Array (Array a)

{-
The 'transpose' function transposes the rows and columns of its argument. For example,

transpose
  [ [1, 2, 3]
  , [4, 5, 6]
  ] ==
  [ [1, 4]
  , [2, 5]
  , [3, 6]
  ]

If some of the rows are shorter than the following rows, their elements are skipped:

transpose
  [ [10, 11]
  , [20]
  , [30, 31, 32]
  ] ==
  [ [10, 20, 30]
  , [11, 31]
  , [32]
  ]
-}

So I could just put the array of valid lines and array of space slots into another array and then transpose them.

import Data.Array (transpose, concat)

specialIntercalate :: forall a. Array a -> Array a -> Array a
specialIntercalate xs ys = transpose [xs, ys] # concat

Mixing these so far:

validLineToParaLine :: Int -> ValidLine -> String
validLineToParaLine maxLen (ValidLine xs) =
  specialIntercalate xs (makeSpaces maxLen (ValidLine xs))
  # Str.joinWith ""

And the test:

> validLineToParaLine 19 (ValidLine ["a","b","c","d","e"])
"a----b----c---d---e"

> validLineToParaLine 16 (ValidLine ["This","is","an"])
"This----is----an"

All that remains now is getting ValidLines out of the given array of words.

I'll write about that in the next part.

Quick rundown of the problem:

• you're given an array of words (eg ["This", "is", "an", "example", "of", "text", "justification."])
• and a max-length per line (eg 16)
• and you have to space the words in such a way that the resulting text/paragraph is "justified".

The rule for spacing is simple:

• one space between words
• if that does not fit the line (length of line = 16), introduce more spaces between words
• more spaces get distributed left to right so spaces on the left would get filled / incremented first and then the right.
• the last line can be left-aligned so just one space between the words is fine.

I spent a few minutes trying to find out how to extract the collection of words that would fit a line.

That is, if this is the text:

["This", "is", "an", "example", "of", "text", "justification."]

and the max length per line is 16,

the first line can only have ["This", "is", "an"].

This is because if I include the word "example", then the length of this line exceeds 16. Remember that I have to include spaces between the words as well in the calculation of line length.

I decided to park this and assume there's a function that gives me a "valid" line already and work on calculating the number of spaces to distribute to justify a "valid" line.

(A valid line is basically an array of words that can fit within the max-length per line including at least 1 space between each word).

In this example, some valid lines would be:

valid lines:
["This", "is", "an"]
["example", "of", "text"]

I decided to use a newtype to differentiate between any random array of words and a valid line:

newtype ValidLine = ValidLine (Array String)

What I have to get to, as a first step, is this function:

validLineToParaLine :: Int -> ValidLine -> String
validLineToParaLine maxLen validLine = ? -- to be implemented

After a while of thinking about this, here's one logic I came up with:

• the actual length of the line is length of each word in the valid line, and spaces between them.
• the total number of spaces (single-space) in a valid line array is simply one less than the total number of words in the valid line array.
• if I subtract the actual length of the valid line from the deficit, I get the number of extra spaces I have to distribute.

This gives me the number of spaces to distribute.

Here's an example of the logic at work:

valid line        -> ["This", "is", "an"]
spaces            -> total words in valid line (3) minus 1 = 3-1 = 2
total characters  -> sum of length of each word in valid line (4+2+2=7) + spaces(2) = 8+2 = 10
deficit           -> max length (16) minus total chars (10) = 16-10 = 6

Okay, so now I have "extra number of spaces to distribute" in the line.

But it got tricky here as I had to find out how to distribute x number of spaces across y number of space-slots.

That is:

deficit = 6
6 spaces have to be distributed in this line: "This is an".

Visually, it looks easy. There are just 2 space-slots. Divide 6 by 2 = 3. So each slot gets 3 extra spaces. (Will replace space with hyphen to be more clear in the representation)

This----is----an

But what is the general logic here?

After much thought, I came up with what looks like a slightly-complicated solution.

Here's the logic:

1. First off, instead of using the "deficit" (that is, how many more spaces need to be distributed besides the usual number of spaces), I combined the deficit with existing spaces so that now, I just have to worry about how many spaces to distribute in total between the words.
2. Using the "total spaces to distribute" number, I construct another array that represents the number of spaces to actually put between each word in the valid line.

Here's an example of point #2:

valid line          -> ["This", "is", "an"]
total spaces to     -> usual spaces (2) + deficit (6) = 8
distribute
space distribution  -> ["----","----"]
array

If the total spaces to distribute was 9, then the array would look like this:

["-----","----"]

That is, the first item will have 5 spaces and the second will have 4.

If I have this array, I could simply merge these two arrays in some way to get the final result:

valid line        -> ["This", "is", "an"]
spaces array      -> ["----","----"]

justified         -> ["This","----","is","----","an"]

The trick is to find out how to go from a "number of spaces to distribute" to a "special spaces array".

I'll post about that in the second part.

I did a couple of them but here's one that I liked. Converting an integer (under 3999) to Roman numerals.

The basic rules are these:

1. Roman numerals are represented by seven different symbols: I, V, X, L, C, D and M.
2. There's a table on the puzzle page that shows what these symbols mean. For the most part, it's simple. Things change at 5, 10, 50, 100, 500 and 1000.
3. And then there are special rules for 4, 9, 40, 90, 400 and 900 which are represented with a slightly different algorithm. (Eg, 4 is not IIII, it's IV and 40 follows a similar logic, so it's XL – that is, 10 less than 50).

The basic idea:

Say, the number to convert into Roman is 23.

I could split that as 20 + 3 (so we know what numbers show up in 1s, 10s ... and so on places).

Then, I can "translate" the numbers like so:

23 -> [2x10, 3x1]
      [XX, III]
      [XXIII]

But if I have a 4 or a 9 somewhere, I need to use a slightly different representation:

49 -> [4x10, 9x1]
      [XXXX, IX] -> wrong
      [XL, IV] -> correct
      [XLIV]

So for each place (1s, 10s, 100s, 1000s), there are special rules for the numbers 4, 5 and 9.

Come to think about it, there are also special rules for numbers greater than 5 in each place.

In 1s place, any number greater than 5 but less than 9 is represented as (Roman for 5) + (Roman for difference).

Eg, 7.

7 -> greater than 5 by 2.
  -> Roman for 5 + Roman for 2
  -> V II
  -> VII

The same kind of a rule applies for 70 too but now, the application changes a little:

70  -> greater than 50 by 20
    -> Roman for 50 + Roman for 20
    -> L XX
    -> LXX

So I realized that the best thing to do (given the limitation that the larger number to convert could only be 3999) was to just write replacement rules for each place in the decimal system.

Here's the replacement rule for the unit (1s) place:

import Prelude
import Data.Maybe as Maybe
import Data.String.Utils (repeat)

process1sPlace :: Int -> String
process1sPlace x
  | x == 4 = "IV"
  | x == 5 = "V"
  | x == 9 = "IX"
  | x < 5 = repeat x "I" # Maybe.fromMaybe ""
  | x > 5 = "V" <> (repeat (x - 5) "I" # Maybe.fromMaybe "")
  | otherwise = ""

As you can see, the logic is kind of straightforward:

• for 4, 5 and 9, we have special cases. I just directly convert them into their corresponding roman numeral,
• for anything less than 5, I just repeat I as many times,
• and for anything more than 5, I prepend a V and then repeat I as many times as the difference.

The repeat function from Data.String.Utils returns a Maybe, which explains why I use a fromMaybe to unbox the data.

These are the functions for the rest of the places:

process10sPlace :: Int -> String
process10sPlace x
  | x == 1 = "X"
  | x == 4 = "XL"
  | x == 5 = "L"
  | x == 9 = "XC"
  | x < 5 = repeat (x) "X" # Maybe.fromMaybe ""
  | x < 10 = "L" <> (repeat (x-5) "X" # Maybe.fromMaybe "")
  | otherwise = ""

process100sPlace :: Int -> String
process100sPlace x
  | x == 1 = "C"
  | x == 5 = "D"
  | x == 4 = "CD"
  | x == 9 = "CM"
  | x < 5 = repeat x "C" # Maybe.fromMaybe ""
  | x > 5 = "D" <> (repeat (x-5) "C" # Maybe.fromMaybe "")
  | otherwise = ""

process1000sPlace :: Int -> String
process1000sPlace x = repeat x "M" # Maybe.fromMaybe ""

Note that for the 1000s place, I just repeat M. We're not dealing with numbers greater than 3999 so this solution works.

Well, now I have the logic to process each number based on which place it is on the decimal system but that leaves me with one other problem: How do I actually split a number into its corresponding number + decimal place?

As an example: 437.

437  -> 4x100s, 3x10s, 7x1s

Turns out, this one I'll have to work in reverse.

1. If I divide 437 by 10, I get 43 as the quotient and 7 as the remainder. Hurray, I was able to "extract" 7 out.
2. If I repeat the division by 10 on the quotient 43, I now get 4 as the quotient and 3 as the remainder! Hurray again: I've extracted the 3 out.
3. Repeat this again and I'm left with 0 as quotient and 4 as remainder -> i.e, extracted the 4 out too!

But wait, I also have to remember which decimal place each number belonged to.

I could do this by keeping track of the number of times I'm dividing by 10. The first time, it's 1s place, the second time, it's the 10ths place and so on.

The logic seems okay but I have to think of a nice data structure that can hold this information. (Side quote: Good programmers worry about data structures and their relationships. - Linus Torvalds)

I thought a Tuple would be best. So:

437 -> [ (4,100), (3,10), (7,1) ]

seemed like a nice representation that I can work with. (Remember the place functions above: I can use the Tuple to know which place function to pass the number through!)

So here's the code I wrote to represent the data and also split the number into the data type:

import Data.Tuple as Tuple
import Data.Int (rem, quot, pow)
import Data.Array (snoc, reverse)

type Group = Tuple.Tuple Int Int -- the data structure

splitter :: Int -> Array Group
splitter x = reverse $ go (quot x 10) (rem x 10) 0 []
  where
    go :: Int -> Int -> Int -> Array Group -> Array Group
    go quotient remainder power acc
      | quotient == 0 = snoc acc (Tuple.Tuple remainder (pow 10 power))
      | otherwise = go (quot quotient 10) (rem quotient 10) (power + 1) (snoc acc (Tuple.Tuple remainder (pow 10 power)))

The splitter takes a number and starts doing the logic I discussed above. Divide by 10, save the remainder and the decimal value (by using the power function) and repeat till the quotient is 0.

And finally it reverses the list (because I worked backwards).

As a test run:

> splitter 437
[(Tuple 4 100),(Tuple 3 10),(Tuple 7 1)]

Okay, now I just have to take each Tuple and then:

• use the second part of the tuple to find out which place function to use
• and use the first part of the tuple as input for the place function

groupToRoman :: Group -> String
groupToRoman (Tuple.Tuple num place)
  | place == 1 = process1sPlace num
  | place == 10 = process10sPlace num
  | place == 100 = process100sPlace num
  | place == 1000 = process1000sPlace num
  | otherwise = ""

At this point, just wanted to note how amazing the destructuring and guard syntaxes are in Purescript/Haskell to be able to write such succint functions that read like math expressions easily.

Now that I have this function to process a Tuple, I can use foldr to simply walk over a list of tuples and join them:

-- all other imports
import Data.Array (snoc, reverse, foldr) -- modified to add `foldr`

arabicToRoman :: Int -> String
arabicToRoman x =
  splitter x
    # foldr fn ""
    where
    fn grp acc = groupToRoman grp <> acc

And to test:

> arabicToRoman 437
CDXXXVII

> arabicToRoman 3789
MMMDCCLXXXIX

> arabicToRoman 7
VII

And that's it.

The fun bits was trying to break the logic into small chunks that can be expressed cleanly in Purescript and then the composition.

Behind the scenes

• I initially thought I could use a look-up table for the 4, 9, 40, 90... special cases. But that seemed to create more complexities.
• The lookup table also failed because the rules change at the 5 mark (5, 50, 500) for each place: it becomes a representation of Roman for 5/50/500 plus the roman for the difference.
• Also, a lookup table would've introduced a lot more Maybe unwrappings, which could clutter the code.

You can see/hack around with the full source here.

After a few-months-long hiatus, I seem to have suddenly landed on a purple patch of writing a lot of Elm. It began as a self-imposed feature request on an old project I had done where you could visually see a calendar of potential long-weekends. I realize I sound vain but I seem to have surprised myself in being able to stick to doing things this long and in such quantities. All tallied, I modified 2 old projects written in Elm (one of which is my go-to expense tracker that I use almost everyday), created a tool that helps me in my daily work, published my first Elm package, and managed to wire up something that can serve as a pattern library to interact type-safely with Elm's Ports (something that's currently not easily done).

My foray into this strange world of "functional programming" really began in 2018. I suspect the actual history is permanently lost in my neural pathways but I remember the dichotomy of having been singed by Javascript frameworks (Vue was, at the time, my favorite and also the one I had the most experience with) prompting me to seek alternatives (leading to the beautiful little website of Elm Lang) and the impregnable-esque feeling one finds oneself in when staring at Maybes and Results and Json Decoders.

It's only recently that I've realized how lucky it is that I discovered Elm not at the time of its initial release but a few years later, because by 2018, Elm had undergone a sort of a major overhaul in terms of the entire structure, philosophy and architecture. It would undergo one more transformation a little later (with v0.19) but honestly, since none of the work I do involves Elm at large-scale production, that drama did not affect me. Anyway: having seen a good chunk of code written in pre-2018-style Elm, I can safely say I'd have easily given this language a miss if I had to deal with that for runtime safety guarantees.

My abortive attempts at learning Elm at the time were a chagrin. I was frustrated that I couldnt quite "intuit" the idioms of the language and yet I wanted to learn this language because I was thoroughly convinced – because of my interactions with libraries like RamdaJS – that this functional-style of writing code was a lot better than anything I had done (or was doing at work).

Late 2019, however, something happened: I had to model a customized Highcharts implementation (think massive, highly-user-customizable wrappers around that charting library), and this would've been extremely complex. What saved the day was that I wrote all of the first-pass code in pseudo-Elm (ie, Elm-like syntax, but code that wont really run). But even the pseudo-code suddenly made it extremely easy to write "composable" chunks of manageable, grokkable code that led directly to the larger model. Transfering all of that into Vue / JS was a breeze (although just tedious because so many functions!). I was completely "sold" at this point to the notion that Elm would make me enjoy programming far more than I had ever did so far (and I was already enjoying writing programs).

Cut to 2023: It's a pity that I have not put in enough time/effort in looking for external projects where I could work with Elm completely, but I find this language to be a refuge nevertheless. My forays into Purescript (and a bit of Haskell) has made me realize that there's a lot more to the iceberg than meets the eye (and Elm really is sort of a tip-of-the-iceberg thing in the functional world – all of it by choice because it aims to be a frontend language right now and wants to make the transition from unsafe JS to safe functional-style programming as easy as possible). For instance, pun intended, Type classes and instances are very much missing from Elm (for good reasons) and they are quite powerful tools when programming applications. Despite these, Elm continues to be quite a powerful toolkit to build complex stuff.

Now, almost two years later, I have repeated half the feat but this time, I went in a little more prepared. I found a great resource that covered the 80% use-case first (while occasionally showing you a glimpse of the 20% use-case as well) and practiced somewhat diligently.

I dont know what constitutes success but I’m now at a comfortable point in using Vim-style actions. But I won’t switch to Vim or Neovim because I’m too tied to VS Code and the plugins there. So I have this plugin that makes Vim out of VS Code so it’s kind of the best of both worlds.

The best bit though is that I’ve gotten a little too used to the efficacy of the Vim grammar of shortcuts (while occasionally shifting to the classic Ctrl/Cmd sequences) that I want to use these bindings in every text-editor interface. And that’s why my Obsidian interface now has Vim-style bindings enabled. Some small misgivings aside, great experience.

If you were a little too obsessive, you might also seek some similar way of navigating between tabs, searching on a page, navigating through history, and so on for your browser. And that’s when you’ll find Vimium.

• running a function repeatedly, at set intervals, is tricky in React. existing examples and libraries are all-too simple for real-world use cases (for eg, they dont work great for async functions, they dont do well with exponential backoff and they dont stop when the function being called at regular interval fails)
• you might reach for setInterval at first, but it has problems like waiting for an async function to finish before calling it again at a given interval, or to stop after a few failed calls. complexity compounds when you add a backoff to this.
• what we'll end up doing in this exercise is to build on top of two critical things – setTimeout and useEffect's "unmounting" behavior – to build a decently-robust useInterval hook that works great for both regular and async functions, and comes with a couple of extra niceties like stopping after n-retries and exponential backoff that are very useful in real-world scenarios.

You'll find a lot of examples online if you went looking for a way to run a function repeatedly after a delay that goes something like this:

const useInterval = (fn, { delay = 5000 }) => {
  useEffect(() => {
    let id;

    if (delay === null) {
      return;
    }

    id = setInterval(fn, delay);

    return () => clearInterval(id);
  }, [delay]);
};

The idea is simple:

• you create a hook that takes the function to run and a delay time
• and it uses a useEffect to setup a setInterval that runs the function after the delay
• and when the component using this hook unmounts, you clear the interval

There are a bunch of problems with this approach:

• What if the function you want to run is async and returns (or resolves) only after a few seconds? (Ans: you'll see function stackups if your delay is less than the time it takes for your async function to resolve.)
• What if you wanted to add some kind of an exponential backoff? (Ans: Not possible in the current scheme. Plain old setInterval is too limiting)
• Oh what if the function throws an error?! (Ans: we could simply slap a try ... catch but then, it doesnt solve for advanced use-cases like retrying a few times before giving up)

So let's make our useInterval robust by solving these problems.

Supporting async functions

Here's the ask: you want to run async functions repeatedly (with a delay) but you want the next-run of the function to be some seconds after the first run is complete. To do this, we have to await our function. But setInterval does not care for waiting - it just keeps calling whatever you give it after a delay.

We could use a setTimeout instead. Sure, the problem is it runs just once but let's see:

const useInterval = (fn, { delay = 5000 }) => {
  useEffect(() => {
    let id;

    if (delay === null) {
      return;
    }

    id = setTimeout(async () => {
      await fn();
    }, delay);

    return () => clearTimeout(id);
  }, [delay]);
};

Because all logic is inside a useEffect, we could simply force the useEffect to re-run after a delay - and that will call setTimeout again!

And useEffect will re-run if something changes in the dependency array. To do this, we'll just introduce a random state variable (which is just Math.random()):

const useInterval = (fn, { delay = 5000 }) => {
  let [randomN, setRandomN] = useState(Math.random());

  useEffect(() => {
    let id;

    if (delay === null) {
      return;
    }

    id = setTimeout(async () => {
      await fn();
      setRandomN(Math.random());
      clearTimeout(id);
    }, delay);

    return () => clearTimeout(id);
  }, [delay, randomN]);
};

What happens is this:

• the hook loads
• it calls the useEffect function
• which calls the setTimeout (if there is a valid delay value)
• in the setTimeout, we call the function to call (and wait for it to resolve)
• once the function is run, we clear the interval and we set a new randomN which triggers the useEffect to re-run

Supporting error-retries

But of course what's a function if it does not throw in the most unexpected way?

Error handling is simple: we just wrap the function call with in a try ... catch but what that achieves is not optimal. Why? Because if the function (for some reason) keeps throwing an error all the time, what's the point in calling it over and over again?

So we have to get the whole thing to stop if the function throws an error. We'll just be a little fancy and ask our hook to "retry" the function a few times before giving up.

That is, just two rules:

• don't blow up
• try a few times

To do this, we'll just do 3 things:

• introduce a "retryCount" state; except, we'll just use a ref for this because we don't want to re-render anything when it changes
• update the retryCount when our function errors
• and if retryCount has hit the max, we clear the timeout and stop the whole logic from running again

const useInterval = (fn, { retries = 3, delay = 5000 }) => {
  let [randomN, setRandomN] = useState(Math.random());
  let retryCount = useRef(retries);

  useEffect(() => {
    let id;

    if (delay === null) {
      return;
    }

    if (retryCount.current === 0) {
      clearTimeout(id);
      return;
    }

    id = setTimeout(async () => {
      try {
        await fn();
      } catch (_) {
        retryCount.current = retryCount.current - 1;
      }
      setRandomN(Math.random());
    }, delay);

    return () => clearTimeout(id);
  }, [delay, randomN]);
};

There is a small problem with this logic though: our hook tracks retries but not "consecutive" ones. We want the hook to stop only if the function throws three consecutive times.

To do this, we'll reset the retryCount if the function succeeds.

const useInterval = (fn, { retries = 3, delay = 5000 }) => {
  let [randomN, setRandomN] = useState(Math.random());
  let retryCount = useRef(retries);

  useEffect(() => {
    let id;

    if (delay === null) {
      return;
    }

    if (retryCount.current === 0) {
      clearTimeout(id);
      return;
    }

    id = setTimeout(async () => {
      try {
        await fn();
        retryCount.current = retries;
      } catch (_) {
        retryCount.current = retryCount.current - 1;
      }
      setRandomN(Math.random());
    }, delay);

    return () => clearTimeout(id);
  }, [delay, randomN]);
};

Adding an incremental backoff

This is a great place to be at. But more realistically, these interval-functions need an exponential backoff so that the retries are lagged by an increasing amount of delay.

All we need to do is keep track of – and use – a new delay amount everytime the function runs. We can do this by introducing a new reference or variable called delayAmt and updating its value when the function finishes running.

const useInterval = (
  fn,
  { retries = 3, delay = 5000, backoffFactor = 1.2 }
) => {
  let [randomN, setRandomN] = useState(Math.random());
  let retryCount = useRef(retries);
  let delayAmt = useRef(delay);

  useEffect(() => {
    let id;

    if (delay === null) {
      return;
    }

    if (retryCount.current === 0) {
      clearTimeout(id);
      return;
    }

    id = setTimeout(async () => {
      try {
        await fn();
        retryCount.current = retries;
        delayAmt.current = delayAmt.current * backoffFactor;
      } catch (_) {
        retryCount.current = retryCount.current - 1;
      }
      setRandomN(Math.random());
    }, delayAmt.current);

    return () => clearTimeout(id);
  }, [delay, randomN]);
};

And that's a complete, usable useInterval hook.

Other improvements you could try:

• The hook should update if the function passed to it changes
• Use this as a wrapper around popular data-fetching libraries like SWR and TanStack Query

Frameworks like React/Vue, libraries like Lodash/Ramda, vendor plugins etc. are tools like hammers, like bulldozers - they are ready-made, are handy to use when you build stuff (stuff in our case is web apps, or websites, or even modules that may be backend-specific).

Building things gets easier with tools, yes. Faster too (at least, most of the time).

But because these tools exist, many of us fall into a simple mindset trap: there are tools and there are apps (ie, built stuff).

This mindset causes us to do things that are often repetitive and time-consuming without us realizing that they are so.

Tools, it turns out, can be used to build bigger tools, better tools. Apps are bigger tools built from smaller tools.

Bigger, better tools are great because they often save time, make your code look and read better (better debugging, lesser testing!) and help you build things in a much more easier way.

Eg. Take the fetch API. (let's assume we want to avoid Axios for this use case).

The fetch API is a tool to make HTTP requests, get responses and pass it down to whatever function you have to store and process the response.

The level zero of using fetch in your project is using it as-is. Let's say you have a page where a component lives. The page makes a call to the API, gets the data and hands it over the component. Some pseudo code in React:

const Page = () => {
  const [loading, setLoading] = useState(true);
  const [data, setData] = useState(null);
  useEffect(() => {
    fetch(URL + "/something", {
      method: "get",
      headers: {
        authorization: "Bearer " + TOKEN,
        ["content-type"]: "application/json",
      },
      //...other options
    })
      .then((r) => r.json())
      .then((res) => {
        setData(res);
        setLoading(false);
      });
  }, []);
  return <Child data={data} loading={loading} />;
};

You can see where this is going to be a problem: your app is going to have so many pages, making so many calls to the API, and writing this fektch.then(r => r.json()).then(...) is going to be a chore.

So you build an abstraction. We will skip a few steps ahead and have ourself an async fetch wrapper - a wrapper that does three things:

1. it automatically injects the default configuration like the method, headers and whatnot.
2. it handles an error-code response (400s, 500s) so you don't have to do r.ok every time to check for successful responses.
3. and it hands you data at the end if everything went well.

The code for the wrapper might look something like this:

const fetchWrapper = (url, options) => {
  return fetch(url, {
    ...DEFAULT_OPTIONS,
    ...options,
  })
    .then((r) => {
      return r.ok ? Promise.resolve(r.json()) : Promise.reject(r.statusText);
    })
    .catch((e) => Promise.reject(e));
};

The two explicit Promise.rejects enable us to use the fetchWrapper like this:

useEffect(() => {
  fetchWrapper({
    url: "/something",
  })
    .then((res) => {
      setData(res);
    })
    .catch((e) => {
      console.error(e);
      // or some toast-like notification
    })
    .then((r) => setLoading(false));
}, []);

Let me pause for a second here. This is not about reduction in code or something trivial like that - although this will eventually be one good reason to adopt a tool-building mindset.

We've built a mini tool (fetchWrapper) on top of another tool (the fetch API) which converts an unwieldy-looking, unwieldy-behaving function into a simpler one that makes it easier for us to use it.

But we need to go further here with the fetchWrapper. It's an okay tool, but it's not very useful yet.

Promises and async/await are great but here's the problem: if a promise fails (ie rejects, throws an error), you have to write the "catch" function to handle it. Otherwise, the app will crash and cause ugly UX issues.

Most developers I see have resigned to writing catch glue everywhere to handle this. Okay, but can we do better?

Turns out, yes.

Our fetchWrapper, if you think about it, either resolves into data or rejects into an error. That is, there are only two things that it "returns": a data or an error.

Once again: the problem is we keep writing ".then" and ".catch" everytime we use the wrapper. The ideal solution is - and this sort of thing always needs a bit of imagination (sometimes bold) - that you never have to write a ".then" and ".catch". Let's see:

We could go try-catch but that is not really much different now is it?:

try {
  const data = await fetchWrapper(...)
  // do something with data
} catch (e) {
  // do something with error e
}

It's slightly shorter but it is still repetition. Needless repetition.

What if the modified, better fetchWrapper could return both data and error in a single object?

const { data, error } = await fetchWrapper(...)

Wait, how come there is no try or catch?

Because fetchWrapper takes care of "catching" errors for us and returns it in a "safe" way.

Actually, if we implement fetchWrapper this way - where it never throws or rejects but returns an error as a simple object key - we eliminate a big class of problems: ie, your app crashing because something at the API failed for some weird reason.

This is not relevant for this talk but here's how the code might look. Again, this is just pseudo code:

const fetchWrapper = (url, options) => {
  return fetch(url, {
    ...DEFAULT_OPTIONS,
    ...options,
  })
    .then((r) => {
      return r.ok
        ? Promise.resolve({
            data: r.json(),
            error: null,
          })
        : Promise.resolve({
            data: null,
            error: r.statusText,
          });
    })
    .catch((e) =>
      Promise.resolve({
        data: null,
        error: e.toString(),
      })
    );
};

The fetchWrapper is still a Promise but it will never "reject". In other words, you will never have to write a '.catch' for it and if you use async/await sugar, you will never have to write '.then' either. Both data and error come in the result value and if there is data, error is null and if there is error, data is null.

In your use of the wrapper, you'll simply do this:

const { data, error } = await fetchWrapper(...)
if (data) {
  setData(data)
}
if (error) {
  setError(error)
}
setLoading(false)

The bigger and better tool-building mindset is not just about saving time or reducing lines of code. It is also about paving way for a better API for your own internal use. Like the poor fetch becomes a better fetch and you destroy the chance of errors crashing your app because of the API-calling layer.

Let's take another example. Most components that receive data (esp from an API call) will need to have three states:

1. the loading state
2. the data state
3. the error state where the expected data couldn't come through We will ignore the empty state. Let's assume it's part of the data state.

Most of us have written this kind of stuff in every component:

const Child = (props) => {
  if (props.loading) return <Loader />;
  if (props.error) return <div>{props.error}</div>;
  if (props.data) return <div> ... </div>;
  return <></>;
};

Imagine writing something similar for every single component in your app.

It doesn't look daunting at all because we're kind of used to doing it. But at the end of the app building exercise, look back at the number of components you wrote this boilerplate and you'll realize it's a horrendous amount of time spent doing that.

If we apply the tool building mindset to this, we will think of a component that takes care of rendering a loader or showing an error for all components without us having to do it manually every time.

Here's a basic implementation in React:

const DataWrapper = (props) => {
  if (props.loading) return <Loading />;
  if (props.error) return <div> {error} </div>;
  return <>{props.children}</>;
};

And we'd use it like so:

<DataWrapper loading={loading} error={error}>
  <Child data={data} />
</DataWrapper>

In Vue, for example, this use case will translate to slots.

With this, all your components have to be written as if they will only have data (or data could be null or something). You can stop wiring the loading and error states throughout the codebase.

Of course you might want to make DataWrapper more fine-grained with more options for things like a different-styled loader or different-styled error render but they are trivial things to do once you build the base.

The point, of course, is this: when we walk into our workday, we already have tools given to us, selected by us, tools that we use often, tools we've gotten fond of, tools we swear by.

They will help you build your app, sure. But they are not built for your app - they are built for all apps. Which means they are not crafted specifically to make building your app easy, fast and seamless.

It is up to us and up to the app we're working on to build bigger tools using the tools we're given to make the whole experience of building simpler, better and smoother.

• This is written (or thought) from the perspective of a JS developer who discovered functional programming as recently as 2019 and has used monads.
• This is not a tutorial on monads, by the way.

Propriety

I still do not profess to know monads ... but I consider that I do understand core idea of functional monads. FWIW, I've implemented monads from scratch in Purescript through this fascinating resource.

Has monads changed the way I write JS code?

Absolutely.

It's quite normal for JS developers to be okay with doing possibleObject.someProperty when possibleObject is not guaranteed to be an object in the first place. That is, it could be "null" or "undefined". Learning monads and using them (the Maybe monad in this case) has helped me be aware of and mitigate this risk (of property access in vanilla JS). Now, I use get from Lodash or the fancier S.prop from Sanctuary depending on the project.

Functions that could throw errors (known and unknown) will need to be handled with try catch blocks. The Either monad has helped me not only be more conscious about such functions when I use them but also model my data structures and pipeline functions better to handle this easily. Think of this: instead of try catch all over the place, I wrap functions in a way that they will return a tuple of [error, data] and I just need to check for either to be null to know if the function worked or failed. No try catch blocks all over the place.

Monad's bind and map have helped me understand how useful such functions are when dealing with pipelines and data transformation (which is about 80% of my work). Maybe they are only useful when you write code in a functional-style but the utility is enormous nevertheless.

Learning monads has also helped me quickly identify certain patterns (for example, think of running an array of promises parallelly and then processing the result. In JS, this is [Promise<value1>, Promise<value2>, Promise<value3>] but using this data as-is is a messy business. But if you convert this into a Promise<[value1, value2, value3]>, suddenly, you only have to unwrap a single promise (via await) to get all the values and have fun using simple, synchronous array functions. This idea is called sequence and within the FP-world, most libraries provide this function).

Learning monads

While this is a completely subjective feeling, I think the best way to learn about monads would be to actually build them from scratch.

The monad challenges were hard. I spent days solving some of them and had to rope in some help from the FP community.

But in the end, while I came out of it battered, some of the core ideas of monads (and why we have them in the first place) got ingrained in me. And they've made writing and approaching problems (to be solved through code) much easier.

Also:

• Safe vs Unsafe Javascript

TLDR: Try to catch errors early, convert errors into "data" that can safely be passed around without the fear of your app crashing. JavaScript does not provide built-in mechanisms like Either to do this but you can build a trivial one yourself. Make programs safe.

The other day a colleague and I got into a conundrum involving JavaScript Promises, unhandled exceptions and who ultimately should own the responsibility of handling thrown errors and rejected promises.

Here's some setup.

Your frontend architecture has three distinct layers that work like a pipeline:

• an API handler which is more or less a wrapper for a Promise-based API library like Axios/Fetch which makes the calls to the backend service
• a caching layer which exposes data and functions to query and mutate the data (mutations ultimately get passed over to the API layer)
• and the app's rendering layer which consists of pages and components

One of the first places your app can "throw" an error is the API layer. For example, all HTTP responses that are in the 4xx or 5xx status zones are technically errors for Axios.

Since you export these helpers out to the caching layer, you have the option of either handling the error at the API layer and passing a "safe" data-only artefact to the subsequent layers of your pipeline, or letting the subsequent layers handle the error the way they see it fit.

Now this is a problem. Why? Because there is no standard operating procedure (enforced either by the language's built-in paradigms or by coding discipline + style-guide), any opinion on who should "handle" the error finds merit. Should it be the API layer itself? Or should it be the component/page that actually triggers the pipeline?

In our case, we also had a constraint: our caching layer needed functions that will "throw" in case of errors (in order for it to run some side-effects on error). One of the libraries being used deep inside components would also need promises that can reject/throw. So, since we were passing around promises across the pipeline, the argument went, the final consumer can do a simple .catch (in our case with a noop for the catch) and none will be the wiser. Long story short, we have a codebase where unhandled promise rejections are being piped across the app.

I think there's some sort of a Sapir-Whorf equivalent to programming languages as well. At a different time, I'd not think this approach is inherently risky and wrong because JavaScript does not provide built-in mechanisms to do two things that completely alter the way we think about unhandled exceptions: 1) a way to safely wrap errors so they wont crash an app and 2) a way to handle such wrapped errors and pipe them across so that they can be handled just at the level they need to be - again, without crashing the app.

My first tryst with functional programming came when I started reading about this frontend language that compiled to JS, called Elm and one of the USPs that it tooted often was "No runtime errors!" (Given how notorious JS is for runtime type errors and undefineds, this is a fantastic marketing tag for Elm).

In Elm, I found the ideas of what's called the Either (or Result) datatype that lets you - very safely - wrap the output of a function (like an Axios promise) even if it throws an error so that your app can continue to work without crashing. You can then inspect what's inside the Either - if it's a Left, then it's an error and if it's a Right then you have successful data. (And this is a concept available in all typed languages that offer some category theory sprinkling)

Of course this is not enough. You need mechanisms in the language that let you do that inspection easily. That part is provided by pattern matching / case expressions in many functional languages. I think our approach to solving these classes of problems is influenced by the languages we "speak". Knowing and using ideas such as Either/Result alters the way we look at such problems.

At Algoshelf, when I wrote the API layer for a VueJS frontend, one of the first things I did was to turn the response from Axios into a tuple of (data, error) (of course, represented in JavaScript as a plain array of length 2). Every function down the pipeline, then, had merely to do a case expression (if). Luckily, the whole architecture was designed so we didn't have to write boilerplate code for everytime we were using those functions. And the component design was such that the wrapping component would handle it for us.

The general principle here is that "data" is a safer thing to carry around and pass in your application than "error" (especially the kinds that need a "catch" mechanism). Instead, adopting a mechanism where errors are turned into data at the first instance gives us the ability to have a consistent, uniform and a safe way to inspect the contents of the data and decide if it's a successful response or an error one.

JavaScript does not provide such mechanisms out of the box but that does not mean you can't build one yourself. Libraries like Sanctuary/Folktale make it easier to get such paradigms imported into your JavaScript code.

I said, “I dont want to think when I’m writing code”. It has been more than a day since I said it and I’ve been thinking about this remark all throughout. Why did I say it? What did I really mean? etc.

When I think as I write code, the whole process of writing some logic and making it work feels tedious. Almost like drudgery. Things go wrong in oh-so-many ways and it’s more like fighting against a machine with an almost unconquerable will than writing logical instructions to a machine that is ready to do your bidding.

The opposite of this is when I know what needs to be written and I just write it. Sure, it breaks in a few ways but these are tiny annoyances that are remedied almost immediately - or with a slight pause - and then the almost-smooth-sailing resumes.

So the trick (to happier code-writing experiences) seems to be to know in advance what’s going to be written. This completely avoids the “thinking while writing code” problem and - perhaps, as a result of that - gives a great code-writing experience.

But of course, I’m no genius so I can’t really know what I’m going to write. There’s always a trial and error even when I’m fairly confident of the kind of logic I’m going to implement for a specific feature/problem. But fighting through that trial and error is easier than doing that thinking while also writing code.

I didn’t know it at the time and only realized it now while thinking about this that I had the same problem with writing (in general). If I had spent my days marinating in thoughts about something and, more importantly, forming the structure of the thing I’m thinking about, my writing on that would almost flow. If instead I fired up the editor with just the crux of a topic, I could go weeks with nothing to show except feeling battered. The coder’s block is the same as the writer’s block.

These lessons always sound blatantly obvious in hindsight. These are lessons we’ve read about, heard about, seen about in various forms. Visualizing the thing you are about to produce gives you a fair upper-hand in skirting the problem of a writer’s, coder’s and creator’s block.

I am pretty certain I’d forget this lesson four weeks down the line and stare at stray pieces of code I’m completely unhappy about unless I re-read this multiple times a month. But there is one interesting meta-application here: I spent a better part of the day thinking about this whole write-up as well and that has paid dividends.

I think somewhere this notion is prevalent in many people. A co-founder from another startup - let’s call him Abe - exhibited this in a different way. While Nate’s automation yardstick was applied to everything in the business world (which is to say it encompassed everything from marketing to sales to engineering), Abe’s was more pronounced in the engineering department. Perhaps this is because he was more of an engineer than an overall-product person in the scope/context I knew him.

In building the frontend, Abe came up with this idea that it should be easy to “compose” not just the components we write but also an entire app with specific features disabled. Not only was it helpful in the business sense (eg feature-flagged product) but also helpful in isolated tests of complete business modules. We were building an application (think super-app) with a bunch of sub-apps in it and his idea was for anyone with bare mininum tech chops to be able to build the modules together.

That idea morphed into a philosophy for the app we built (at least to a decent degree, I think). So now I was trying not only to write a build system that would allow someone to selectively build the modules that would render in the final app but also enable people to write components that plug into the database somewhat more easily than usual. As a quick example, I wrote an entire layer that abstracted the API interactions (think Vuex Actions) and store access to a level where a simple wrapping component was all you needed to get data (along with loading, error states plus HTTP POST/PUT/DELETE handlers) to all the APIs in our app.

At the time of writing such layers of abstraction that would automate a lot of things for the developer, I was not aware of such patterns pre-existing in other frameworks (React/Apollo for instance). Now, I see that pattern in a lot of places. The crowning glory however – not to sound boastful but still – was the fact that I was able to write something from scratch which ended up saving me a lot of time.

The seed for that endeavour, which I am sure I wouldn’t have undertaken had it not been put on my desk as a requirement from who could often sound like a madman, came from Abe’s incessant need to simplify writing code by using generators, decorators, abstractions and what other ideas have you to write lesser code. In that pursuit, you usually end up writing a hell lot of code in the first few weeks of your system getting into shape and then it pays rich dividends.

If some engineer were to say, “my goal is not only to build a great product for the organization I work for but also to make my life easier and write less code”, most people would probably balk at the idea and not hire them. Yet, that is precisely the kind of ideas Abe has/had in his mind and that is what led us to build a frontend that had such levels of abstraction. A culture of “how can we create a tool here that will help us make building things easier?” should be in the minds of every engineer. While not all of us can create rich frameworks like React or Vue, we certainly can create tools with existing libraries or prior art that would help us in our everyday lives.

For many months, I had been avoiding this npm and webpack route like the plague. Until I hit a point where I had to work with vue-cli for a project (subsequently couple more projects). I still have some qualms about this new web-dev workflow that we’ve got ourselves into but I had the luxury of some quiet evenings to ponder over my initial — but long — aversion to the current state of web-dev workflows and webpacks and whatnots.

Turns out, in my specific case, there were two issues.

One, I like to know “why” and “why not something else” when someone tells me to do something. Without a convincing “why” and “why not”, I cannot wrap my head around the rest of the instruction set. Since 2015 or thereabouts, if you take a look at tutorials on web dev, almost everything is exactly like how Frank Chimero describes it:

simply npm your webpack via grunt with vue babel or bower to react asdfjkl;lkdhgxdlciuhw

Two, I was on a hiatus and that meant I missed a big chunk of historic context on how we got here.

The first issue is a constant and is more of a good feature than an issue so that stays. (I still get pissed off at tutorials that aim to do the simplest of things but will require you to npm install half-a-dozen packages. If fucking packages are getting things done, why do you even bother to write a tutorial, ya nincompoop)

The second issue is something resolvable. So on one of the quiet evenings I traced the history of web dev workflows.

And that’s when everything cleared and my aversion for npm-style workflow melted away.

It all starts with our penchant for economy of effort.

• Things like package managers came to be because we started including a lot of js libraries in our projects. DRY took a stronghold (but note how the best creators are often the ones who flout the DRY rule and always build things their own way from scratch?). Handling these libraries became a chore when you had to upgrade them.
• Things like bundling came to be because the benefit of minification was for all to see.
• Things like transpilers and compilers came to be because we wanted to go with Python-like simplicity in CSS and OOP-like functionality in JS.
• Things like starter packs are fairly simple to trace: we had ‘alias'es in our .bashrc file to create a project file, touch index.html and mkdir some folders like 'js’ and 'css’ and so on.
• And finally, of course, we have things like hot reloading and live reloading and libraries that handle these - and these came to be out of this whole packaging, bundling, compiling consortium.

The real hard thing was a year or so ago when each existed independently. I know one project where the dev was using “bower” to manage packages, using “grunt” to serve and build the app, then there was node too to wrap all this. Imagine having to remember the commands for each (the lazy programmer would say “but there are only a handful of commands that you use constantly so it’s no big deal”).

What happend with this npm craze is that we managed to bundle all of these things - dependencies (a.k.a package managers), compilers/transpilers, local server setup, hot/live reloading into one nifty command-line tool.

And so, technically, everything hard has become somewhat easy again.

It still doesn’t justify the stupid tutorials that start with “install these 73 packages first and then we’ll start connecting with that API to fetch data”.

I wrote a library that generates unique IDs of any reasonable character length.

Yes, there are possibly thousands like these. But this is a good, basic learning experience and that’s the only reason I did this.

But turns out I could then expand this into something a bit more.

And so it turned out to be a lesson in the new Async/Await thing in JS.

The generateID(options) function is written as a promise.

And the Generate Id button/link on the demo page uses the async/await method to print the result on the page.

Exactly why should generateID() be a promise? Why not a simple, straightforward function?

In the real world, generateID() is useful for generating unique IDs. Sort of like primary keys for rows of data (or documents, if you come from MongoDB).

One use-case would be to ensure that the generated ID is truly ‘unique’. That means cross-checking the generated ID with the existing ones and confirming that there’s no duplicate.

As this process takes time, I converted the generateID(options) function into a promise.

There may be other use-cases. I’m not aware of them, I can’t think of any other at the moment of writing this. But the one above is quite important when people use libraries to generate unique IDs.

So, in essence, this library is instantly extensible. I put in a dummy/silly function in the library as an example. generateID(options) will check if the generated ID contains the letter 'o’ … if not found, it will throw an error. (You can tweak this function to do something valuable instead: like check for uniqueness of the generated ID).

Here’s where the stupidity of Async/Await shows up - a.k.a it’s still immature.

Typically, I’d use a simple generateID(options).then().catch() kind of a code on the front-end. You would too. But there’s this async/await fad going about. So let’s try that.

When you click “Generate ID”:

I do this:

But await cannot be used like that. It has to be inside an async function. Er… that seems stupid.

So we have to rewrite it.

Okay this worked. But hold up. What if there was an error in the generateID() function itself? Like, it threw a reject() instead of a resolve()?

There’s no way async/await can handle errors. You have to manually try and catch errors. Get it?

Compare this with how you’d typically handle a promise.

I still think the chaining is better than this half-cooked async/await thing we’re being sold.